diff --git a/john-comments/draft-ietf-core-groupcomm-bis.html b/john-comments/draft-ietf-core-groupcomm-bis.html index d445c42..d7dac3e 100644 --- a/john-comments/draft-ietf-core-groupcomm-bis.html +++ b/john-comments/draft-ietf-core-groupcomm-bis.html @@ -2638,11 +2638,22 @@
A key management scheme for secure revocation and renewal of group security material, namely group rekeying, is required to be adopted in OSCORE groups. The key management scheme has to preserve forward security in the OSCORE group, as well as backward security if this is required by the application (see Section 5.2). In particular, the key management scheme MUST comply with the functional steps defined in Section 3.2 of [I-D.ietf-core-oscore-groupcomm].¶
-Group policies should also take into account the time that the key management scheme requires to rekey the group, on one hand, and the expected frequency of group membership changes, i.e., nodes joining and leaving, on the other hand.¶
-That is, it may be desirable to not rekey the group upon every single membership change, in case members frequently joining and leaving, and at the same time a single group rekeying instance taking a non-negligible time to complete.¶
-In such a case, the Group Manager may cautiously consider to rekey the group, e.g., after a minimum number of nodes has joined or left the group within a pre-defined time interval, or according to communication patterns with predictable time intervals of network inactivity. This would prevent from paralyzing communications in the group, when a slow rekeying scheme is used and frequently invoked.¶
-At the same time, the security implications of delaying the rekeying process have to be carefully considered and understood before employing such group policies.¶
-In fact, this comes at the cost of not continuously preserving backward and forward security, since group rekeying might not occur upon every single group membership change. That is, most recently joined nodes would have access to the security material used prior to their joining, and thus be able to access past group communications protected with that security material. Similarly, until the group is rekeyed, most recently left nodes would retain access to group communications protected with the existing security material.¶
+Even though group policies vary depending on the specific applications and their security requirements, they SHOULD also take into account:¶
+The expected amount of time that the key management scheme requires to rekey the group.¶
+The expected frequency of group membership changes (i.e., nodes joining and leaving).¶
+The identity of the specific CoAP endpoints as they join and leave the OSCORE group.¶
+In particular, it can be desirable to not rekey the group upon every single membership change, in case group members frequently join and leave, and at the same time a single group rekeying instance takes a non-negligible time to complete.¶
+In such a case, the Group Manager can cautiously consider to rekey the group, e.g., after a minimum number of nodes has joined or left the group within a pre-defined time interval, or according to communication patterns with predictable time intervals of network inactivity. This would prevent from paralyzing communications in the group, when a slow rekeying scheme is used and frequently invoked.¶
+At the same time, the security implications of delaying the rekeying process have to be carefully considered and understood before employing such group policies.¶
+In fact, this comes at the cost of not continuously preserving backward and forward security, since group rekeying might not occur upon every single group membership change. That is, most recently joined nodes would have access to the security material used prior to their joining, and thus be able to access past group communications protected with that security material. Similarly, until the group is rekeyed, most recently left nodes would retain access to group communications protected with the existing security material.¶
Changed "has to" to "should" for enforcing access control based on membership to security groups.¶
Further stressed that group communication ought to be secured.¶
+Used normative language for policies about group rekeying.¶
Editorial fixes and improvements.¶
+Further stressed that group communication ought to be secured.¶
+Editorial fixes and improvements.¶