From 78a39490a8ec69cddde12371e0cefaf928bb4a95 Mon Sep 17 00:00:00 2001 From: ID Bot Date: Sun, 8 Oct 2023 21:49:03 +0000 Subject: [PATCH] Script updating gh-pages from 8197da1. [ci skip] --- .../draft-ietf-core-groupcomm-bis.html | 22 +++++--- .../draft-ietf-core-groupcomm-bis.txt | 53 ++++++++++++++----- 2 files changed, 53 insertions(+), 22 deletions(-) diff --git a/john-comments/draft-ietf-core-groupcomm-bis.html b/john-comments/draft-ietf-core-groupcomm-bis.html index bf0c39f..518bded 100644 --- a/john-comments/draft-ietf-core-groupcomm-bis.html +++ b/john-comments/draft-ietf-core-groupcomm-bis.html @@ -2547,7 +2547,7 @@

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.

Group OSCORE [I-D.ietf-core-oscore-groupcomm] 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.

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.

-

Group OSCORE ensures source authentication of all messages exchanged within the OSCORE group, by means of two possible methods.

+

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.

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.

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 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.

@@ -2663,7 +2663,8 @@

Both the group mode and the pairwise mode of Group OSCORE ensure source authentication of messages exchanged by CoAP endpoints through CoAP group communication.

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).

-

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.

+

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.

+

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.

@@ -2677,7 +2678,7 @@

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 Section 11.2 of [RFC7252]). 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 8 and 9 of [I-D.ietf-core-oscore-groupcomm]), and especially processes CoAP options according to the same classification in U/I/E classes.

  • -

    Group OSCORE limits the feasibility and impact of amplification attacks (see Section 6.3 of this document and Section 11.3 of [RFC7252]), 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.

    +

    Group OSCORE limits the feasibility and impact of amplification attacks (see Section 6.3 of this document and Section 11.3 of [RFC7252]), 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.

    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 Section 8.2 of [I-D.ietf-core-oscore-groupcomm]); 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 Section 9.4 of [I-D.ietf-core-oscore-groupcomm]).

    @@ -2687,12 +2688,14 @@

    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.

    -As a further mitigation against amplification attacks, a server can also rely on the Echo Option for CoAP defined in [RFC9175] 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.

    +As a further mitigation against amplification attacks, a server can also rely on the Echo Option for CoAP defined in [RFC9175] 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.

    +

    +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 Section 6.2.2). 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.

  • -

    Group OSCORE limits the impact of attacks based on IP spoofing over IP multicast (see Section 11.4 of [RFC7252]). In fact, requests and corresponding responses sent in the OSCORE group can be correctly generated only by legitimate members of the group.

    +

    Group OSCORE limits the impact of attacks based on IP spoofing over IP multicast (see Section 11.4 of [RFC7252]). 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.

    -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 8.1 and 8.3 of [I-D.ietf-core-oscore-groupcomm]), and in the pairwise mode by using additionally derived pairwise keys (see Sections 9.3 and 9.5 of [I-D.ietf-core-oscore-groupcomm]). Thus, recipient endpoints can verify a message to be originated by the alleged, identifiable sender in the OSCORE group.

    +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 8.1 and 8.3 of [I-D.ietf-core-oscore-groupcomm]), and in the pairwise mode by using additionally derived pairwise keys (see Sections 9.3 and 9.5 of [I-D.ietf-core-oscore-groupcomm]). Thus, recipient endpoints can verify a message to have been originated and sent by the alleged, identifiable CoAP endpoint in the OSCORE group.

    As noted above, the server may additionally rely on the Echo Option for CoAP defined in [RFC9175], in order to verify the aliveness and reachability of the client sending a request from a particular IP address.

    • @@ -2720,7 +2723,7 @@

    SHOULD limit the support for CoAP group requests only to the group resources of the application group(s) using that CoAP group;

  • -

    SHOULD NOT accept group requests that cannot be authenticated in some way;

    +

    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;

  • SHOULD NOT provide large amplification factors through its responses to a non-authenticated group request, possibly employing CoAP block-wise transfers [RFC7959] to reduce the amount of amplification.

    @@ -3868,7 +3871,10 @@

    Further stressed that group communication ought to be secured.

  • -

    Editorial fixes and improvements.

    +

    Clarification on source authentication, source addresses, and Echo Option.

    +
    • +
  • +

    Editorial fixes and improvements.

    • diff --git a/john-comments/draft-ietf-core-groupcomm-bis.txt b/john-comments/draft-ietf-core-groupcomm-bis.txt index f1b723d..9e63dff 100644 --- a/john-comments/draft-ietf-core-groupcomm-bis.txt +++ b/john-comments/draft-ietf-core-groupcomm-bis.txt @@ -2104,7 +2104,10 @@ Table of Contents in the OSCORE group, as well as the corresponding responses. Group OSCORE ensures source authentication of all messages exchanged - within the OSCORE group, by means of two possible methods. + 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. The first method, called group mode, relies on digital signatures. That is, sender devices sign their outgoing messages using their own @@ -2371,8 +2374,14 @@ Table of Contents keys of the message sender and recipient (pairwise mode). 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. + message has actually been originated and sent by a specific and + identified CoAP endpoint as a member of the OSCORE group. + + 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. 6.2.3. Countering Attacks @@ -2398,8 +2407,8 @@ Table of Contents [RFC7252]), 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. + is not a replay, and whether it has been originated and sent by + the alleged CoAP endpoint in the OSCORE group. In order to perform the latter check of source authentication, the server either: i) verifies the signature included in the request @@ -2438,16 +2447,27 @@ Table of Contents 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. + 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. + + 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 Section 6.2.2). 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. * Group OSCORE limits the impact of attacks based on IP spoofing over IP multicast (see Section 11.4 of [RFC7252]). In fact, requests and corresponding responses sent in the OSCORE group can - be correctly generated only by legitimate members of the group. + be correctly generated only by CoAP endpoints that are legitimate + members of the group. Within an OSCORE group, the shared symmetric-key security material strictly provides only group-level authentication. However, @@ -2456,8 +2476,8 @@ Table of Contents [I-D.ietf-core-oscore-groupcomm]), and in the pairwise mode by using additionally derived pairwise keys (see Sections 9.3 and 9.5 of [I-D.ietf-core-oscore-groupcomm]). Thus, recipient endpoints - can verify a message to be originated by the alleged, identifiable - sender in the OSCORE group. + can verify a message to have been originated and sent by the + alleged, identifiable CoAP endpoint in the OSCORE group. As noted above, the server may additionally rely on the Echo Option for CoAP defined in [RFC9175], in order to verify the @@ -2509,7 +2529,9 @@ Table of Contents resources of the application group(s) using that CoAP group; * SHOULD NOT accept group requests that cannot be authenticated in - some way; + 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; * SHOULD NOT provide large amplification factors through its responses to a non-authenticated group request, possibly employing @@ -3826,6 +3848,9 @@ E.1. Version -09 to -10 * Further stressed that group communication ought to be secured. + * Clarification on source authentication, source addresses, and Echo + Option. + * Editorial fixes and improvements. E.2. Version -08 to -09