From 57c300f0f12b128970f1e8f3b93fdfe3b0ef9f7e Mon Sep 17 00:00:00 2001 From: ID Bot Date: Fri, 27 Sep 2024 09:39:48 +0000 Subject: [PATCH] Script updating gh-pages from 968d421. [ci skip] --- .../draft-ietf-core-oscore-key-update.html | 54 +++++++++++-------- .../draft-ietf-core-oscore-key-update.txt | 54 ++++++++++++------- 2 files changed, 67 insertions(+), 41 deletions(-) diff --git a/christian-review-v08/draft-ietf-core-oscore-key-update.html b/christian-review-v08/draft-ietf-core-oscore-key-update.html index 2925ac1..a7c6a53 100644 --- a/christian-review-v08/draft-ietf-core-oscore-key-update.html +++ b/christian-review-v08/draft-ietf-core-oscore-key-update.html @@ -1428,8 +1428,9 @@

The protection of CoAP responses with OSCORE is updated, by adding the following text at the end of step 3 of Section 8.3 of [RFC8613].

-

This prevents the server from using the same AEAD (key, nonce) pair for two responses, protected with different OSCORE Security Contexts.

-

An exception is the procedure in Appendix B.2 of [RFC8613], which is secure although not complying with the above. The reason is that, in that procedure, the server uses the new OSCORE Security Context only and solely to protect the outgoing response (response #1), and no other message is protected with that OSCORE Security Context. Other procedures where that holds would also remain secure.

+

If the server is using a different Security Context for the response compared to what was used to verify the request (e.g., due to an occurred key update), then the server MUST take the second alternative. That is, the server MUST include its Sender Sequence Number as Partial IV in the response and use it to build the AEAD nonce to protect the response.

+

This prevents the server from using the same AEAD (key, nonce) pair for two responses, protected with different OSCORE Security Contexts.

+

An exception is the procedure in Appendix B.2 of [RFC8613], which is secure although not complying with the above. The reason is that, in that procedure, the server uses the new OSCORE Security Context only and solely to protect the outgoing response (response #1), and no other message is protected with that OSCORE Security Context. Other procedures where that holds would also remain secure.

@@ -1585,50 +1586,59 @@

Finally, the updateCtx() function returns the newly derived Security Context CTX_OUT.

Since the updateCtx() function also takes X as input, the derivation of CTX_OUT also considers as input the information from the 'x' field transported in the OSCORE Option value of the exchanged KUDOS messages. In turn, this ensures that, if successfully completed, a KUDOS execution occurs as intended by the two peers.

-
+
-updateCtx(X, N, CTX_IN) {
+function updateCtx(X, N, CTX_IN):
 
+  // Output values
   CTX_OUT       // The new Security Context
   MSECRET_NEW   // The new Master Secret
   MSALT_NEW     // The new Master Salt
 
-  X_cbor = bstr .cbor X // CBOR bstr wrapping of X
-  N_cbor = bstr .cbor N // CBOR bstr wrapping of N
+  // Create CBOR byte strings from X and N
+  X_cbor = create_cbor_bstr(X)
+  N_cbor = create_cbor_bstr(N)
 
+  // Concatenate the CBOR-encoded X and N
   X_N = X_cbor | N_cbor
 
-  oscore_key_length = < Size of CTX_IN.MasterSecret in bytes >
+  // Determine the length in bytes of the current Master Secret
+  oscore_key_length = length(CTX_IN.MasterSecret)
 
+  // Define the label for the key update
   Label = "key update"
 
-  MSECRET_NEW = KUDOS-Expand-Label(CTX_IN.MasterSecret, Label,
+  // Create the new Master Secret using KUDOS-Expand-Label
+  MSECRET_NEW = KUDOS_Expand_Label(CTX_IN.MasterSecret, Label,
                                    X_N, oscore_key_length)
-               = KUDOS-Expand(CTX_IN.MasterSecret, ExpandLabel,
-                              oscore_key_length)
 
-  MSALT_NEW = N;
+  // Set the new Master Salt to N
+  MSALT_NEW = N
 
-  < Derive CTX_OUT using MSECRET_NEW and MSALT_NEW,
-    together with other parameters from CTX_IN >
+  // Derive the new Security Context CTX_OUT, using
+  // the new Master Secret, the new Master Salt,
+  // and other parameters from CTX_IN
+  CTX_OUT = derive_security_context(MSECRET_NEW, MSALT_NEW, CTX_IN)
 
-  Return CTX_OUT;
+  // Return the new Security Context
+  return CTX_OUT
 
-}
 
-Where ExpandLabel is defined as
+function KUDOS_Expand_Label(master_secret, Label, X_N, key_length):
+
+  struct {
+      uint16 length = key_length;
+      opaque label<7..255> = "oscore " + Label;
+      opaque context<0..255> = X_N;
+  } ExpandLabel;
 
-struct {
-    uint16 length = oscore_key_length;
-    opaque label<7..255> = "oscore " + Label;
-    opaque context<0..255> = X_N;
-} ExpandLabel;
+  return KUDOS_Expand(master_secret, ExpandLabel, key_length)
Figure 2: -Function for deriving a new OSCORE Security Context +Functions for deriving a new OSCORE Security Context
diff --git a/christian-review-v08/draft-ietf-core-oscore-key-update.txt b/christian-review-v08/draft-ietf-core-oscore-key-update.txt index e4b1e96..1a42b85 100644 --- a/christian-review-v08/draft-ietf-core-oscore-key-update.txt +++ b/christian-review-v08/draft-ietf-core-oscore-key-update.txt @@ -320,6 +320,13 @@ Table of Contents The protection of CoAP responses with OSCORE is updated, by adding the following text at the end of step 3 of Section 8.3 of [RFC8613]. + | If the server is using a different Security Context for the + | response compared to what was used to verify the request (e.g., + | due to an occurred key update), then the server MUST take the + | second alternative. That is, the server MUST include its Sender + | Sequence Number as Partial IV in the response and use it to build + | the AEAD nonce to protect the response. + | | This prevents the server from using the same AEAD (key, nonce) | pair for two responses, protected with different OSCORE Security | Contexts. @@ -570,44 +577,53 @@ Table of Contents messages. In turn, this ensures that, if successfully completed, a KUDOS execution occurs as intended by the two peers. - updateCtx(X, N, CTX_IN) { + function updateCtx(X, N, CTX_IN): + // Output values CTX_OUT // The new Security Context MSECRET_NEW // The new Master Secret MSALT_NEW // The new Master Salt - X_cbor = bstr .cbor X // CBOR bstr wrapping of X - N_cbor = bstr .cbor N // CBOR bstr wrapping of N + // Create CBOR byte strings from X and N + X_cbor = create_cbor_bstr(X) + N_cbor = create_cbor_bstr(N) + // Concatenate the CBOR-encoded X and N X_N = X_cbor | N_cbor - oscore_key_length = < Size of CTX_IN.MasterSecret in bytes > + // Determine the length in bytes of the current Master Secret + oscore_key_length = length(CTX_IN.MasterSecret) + // Define the label for the key update Label = "key update" - MSECRET_NEW = KUDOS-Expand-Label(CTX_IN.MasterSecret, Label, + // Create the new Master Secret using KUDOS-Expand-Label + MSECRET_NEW = KUDOS_Expand_Label(CTX_IN.MasterSecret, Label, X_N, oscore_key_length) - = KUDOS-Expand(CTX_IN.MasterSecret, ExpandLabel, - oscore_key_length) - MSALT_NEW = N; + // Set the new Master Salt to N + MSALT_NEW = N + + // Derive the new Security Context CTX_OUT, using + // the new Master Secret, the new Master Salt, + // and other parameters from CTX_IN + CTX_OUT = derive_security_context(MSECRET_NEW, MSALT_NEW, CTX_IN) - < Derive CTX_OUT using MSECRET_NEW and MSALT_NEW, - together with other parameters from CTX_IN > + // Return the new Security Context + return CTX_OUT - Return CTX_OUT; - } + function KUDOS_Expand_Label(master_secret, Label, X_N, key_length): - Where ExpandLabel is defined as + struct { + uint16 length = key_length; + opaque label<7..255> = "oscore " + Label; + opaque context<0..255> = X_N; + } ExpandLabel; - struct { - uint16 length = oscore_key_length; - opaque label<7..255> = "oscore " + Label; - opaque context<0..255> = X_N; - } ExpandLabel; + return KUDOS_Expand(master_secret, ExpandLabel, key_length) - Figure 2: Function for deriving a new OSCORE Security Context + Figure 2: Functions for deriving a new OSCORE Security Context 4.3. Key Update with Forward Secrecy