From 90da79f4363c8cf461fb7e2ac5efb357003175cf Mon Sep 17 00:00:00 2001 From: ID Bot Date: Fri, 1 Mar 2024 16:41:17 +0000 Subject: [PATCH] Script updating gh-pages from 49e55ad. [ci skip] --- draft-ietf-core-oscore-key-update.html | 432 +++++++++++++++---------- draft-ietf-core-oscore-key-update.txt | 145 +++++++-- 2 files changed, 389 insertions(+), 188 deletions(-) diff --git a/draft-ietf-core-oscore-key-update.html b/draft-ietf-core-oscore-key-update.html index e333a65..d555d7d 100644 --- a/draft-ietf-core-oscore-key-update.html +++ b/draft-ietf-core-oscore-key-update.html @@ -1256,39 +1256,42 @@

4.3.1. Forward Message Flow

-

Figure 3 shows an example of KUDOS run in the forward message flow, with the client acting as KUDOS initiator. Even though in this example the first KUDOS message is a request and the second is a response, KUDOS is not constrained to this request/response model and a KUDOS execution can be performed with any combination of CoAP requests and responses. Appendix A shows an example where both KUDOS messages are CoAP requests.

+

Figure 3 shows an example of KUDOS run in the forward message flow, with the client acting as KUDOS initiator. Even though in this example the first KUDOS message is a request and the second is a response, KUDOS is not constrained to this request/response model and a KUDOS execution can be performed with any combination of CoAP requests and responses. Appendix A shows an example where both KUDOS messages are CoAP requests. Furthermore, Appendix B presents an example where KUDOS Response #2 is a response to a different request than KUDOS Request #1.

@@ -1799,7 +1802,7 @@

In case the server does not successfully verify the request, the same error handling specified in Section 8.2 of [RFC8613] applies. This does not result in deleting CTX_NEW. If the server successfully verifies the request using CTX_NEW, the server deletes CTX_OLD and can reply with an OSCORE response protected with CTX_NEW.

Note that the server achieves key confirmation only when receiving a message from the client as protected with CTX_NEW. If the server sends a non KUDOS request to the client protected with CTX_NEW before then, and the server receives a 4.01 (Unauthorized) error response as reply, the server SHOULD delete CTX_NEW and start a new KUDOS execution acting as CoAP client, i.e., as initiator in the forward message flow.

Also note that, if both peers reboot simultaneously, they will run the KUDOS forward message flow as defined in this section. That is, one of the two peers implementing a CoAP client will send KUDOS Request #1 in Figure 3.

-

When KUDOS Request #1 targets a normal resource (that is not a well-known KUDOS or analogous resource), then if the server requires freshness it can respond with a 4.01 (Unauthorized) error response protected with CTX_NEW as KUDOS Response #1. This signals to the client that the server is continuing the KUDOS procedure but wishes to verify the freshness of the application-level operations the client requested in KUDOS Request #1. In such case the client can resend its original request but now protected with CTX_NEW wishes as Request #2. This procedure is neccessary as the server cannot be sure that KUDOS Request #1 is fresh. An alternative is to use the CoAP Echo option as defined in [RFC9175] which the procedure defined in this paragraph is analogous in functionality to. An example of a KUDOS execution where KUDOS Request #1 targets a normal resource is shown in Appendix B.

+

When KUDOS Request #1 targets a normal resource (that is not a well-known KUDOS or analogous resource), then if the server requires freshness it can respond with a 4.01 (Unauthorized) error response protected with CTX_NEW as KUDOS Response #1. This signals to the client that the server is continuing the KUDOS procedure but wishes to verify the freshness of the application-level operations the client requested in KUDOS Request #1. In such case the client can resend its original request but now protected with CTX_NEW wishes as Request #2. This procedure is neccessary as the server cannot be sure that KUDOS Request #1 is fresh. An alternative is to use the CoAP Echo option as defined in [RFC9175] which the procedure defined in this paragraph is analogous in functionality to. An example of a KUDOS execution where KUDOS Request #1 targets a normal resource is shown in Appendix C.

@@ -2787,15 +2790,113 @@

-
+
-

-Appendix B. Forward Message Flow Targeting Arbitrary Resource at Server +

+Appendix B. Forward Message Flow with Response 1 unrelated to Request 1

-

This section presents an example of KUDOS run in the forward message flow, with the client acting as KUDOS initiator, and targeting a normal resource with KUDOS Request #1. Note the presence of an application payload in KUDOS Request #1 and the fact that KUDOS Response #1 is a 4.01 (Unauthorized) message (inside the encrypted payload as the response code is protected by OSCORE).

-
+

This section presents an example of KUDOS run in the forward message flow, with the client acting as KUDOS initiator, where KUDOS Response #2 is not a response to KUDOS Request #1 but rather an unrelated Observer notification.

+
+
+                     Client                  Server
+                   (initiator)            (responder)
+                        |                      |
+                        |       Request        |
+                        |   (Registration)     |
+Protect with CTX_OLD    |--------------------->| /obs
+                        | Token: 0x4a          |
+                        | Observe: 0           |
+                        | OSCORE {             |
+                        |  ...                 |
+                        |  Partial IV: 4324    |
+                        |  ...                 |
+                        | }                    |
+                        | Encrypted Payload {  | Verify with CTX_OLD
+                        |  Observe: 0          |
+                        |  ...                 |
+                        | }                    |
+                        |                      |
+Generate N1             |                      |
+                        |                      |
+CTX_1 = updateCtx(      |                      |
+        X1,             |                      |
+        N1,             |                      |
+        CTX_OLD)        |                      |
+                        |                      |
+                        |      Request #1      |
+Protect with CTX_1      |--------------------->| /.well-known/kudos
+                        | Token: 0x7c          |
+                        | OSCORE {             |
+                        |  ...                 |
+                        |  Partial IV: 0       |
+                        |  ...                 |
+                        |  d flag: 1           | CTX_1 = updateCtx(
+                        |  x: X1               |         X1,
+                        |  nonce: N1           |         N1,
+                        |  ...                 |         CTX_OLD)
+                        | }                    |
+                        | Encrypted Payload {  | Verify with CTX_1
+                        |  ...                 |
+                        | }                    | Generate N2
+                        |                      |
+                        |                      | CTX_NEW = updateCtx(
+                        |                      |           Comb(X1,X2),
+                        |                      |           Comb(N1,N2),
+                        |                      |           CTX_OLD)
+                        |                      |
+                        |      Response #1     |
+                        |    (Notification)    |
+                        |<---------------------| Protect with CTX_NEW
+                        | Token: 0x4a          |
+                        | Observe: 1           |
+                        | OSCORE {             |
+                        |  ...                 |
+CTX_NEW = updateCtx(    |  Partial IV: 0       |
+          Comb(X1,X2),  |  ...                 |
+          Comb(N1,N2),  |  d flag: 1           |
+          CTX_OLD)      |  x: X2               |
+                        |  nonce: N2           |
+Verify with CTX_NEW     |  ...                 |
+                        | }                    |
+Discard CTX_OLD         | Encrypted Payload {  |
+                        | Observe: 1           |
+                        |  ...                 |
+                        | }                    |
+                        |                      |
+
+// The actual key update process ends here.
+// The two peers can use the new Security Context CTX_NEW.
+
+                        |      Response #2     |
+                        |<---------------------| Protect with CTX_NEW
+                        | Token: 0x7c          |
+                        | OSCORE {             |
+                        |  ...                 |
+Verify with CTX_NEW     | }                    |
+                        | Encrypted Payload {  |
+                        |  ...                 |
+                        |  Application Payload |
+                        | }                    |
+                        |                      |
+
+
+
Figure 8: +Example of the KUDOS forward message flow where KUDOS Response #2 is not a response to KUDOS Request #1. +
+
+
+
+
+
+

+Appendix C. Forward Message Flow Targeting Arbitrary Resource at Server +

+

This section presents an example of KUDOS run in the forward message flow, with the client acting as KUDOS initiator, and targeting a normal resource with KUDOS Request #1. Note the presence of an application payload in KUDOS Request #1 and the fact that KUDOS Response #1 is a 4.01 (Unauthorized) message (inside the encrypted payload as the response code is protected by OSCORE).

+
-
+

-Appendix C. Document Updates +Appendix D. Document Updates

-

RFC EDITOR: PLEASE REMOVE THIS SECTION.

+

RFC EDITOR: PLEASE REMOVE THIS SECTION.

-
+

-C.1. Version -06 to -07 +D.1. Version -06 to -07

    -
  • -

    Removed material about the ID update procedure, which has been split out into a separate draft.

    +
  • +

    Removed material about the ID update procedure, which has been split out into a separate draft.

    +
    • +
  • +

    Allow non-random nonces for CAPABLE devices.

    • -
  • -

    Allow non-random nonces for CAPABLE devices.

    +
  • +

    Editorial improvements.

    • -
  • -

    Add example showing flexible message flow with two KUDOS messages as CoAP requests.

    +
  • +

    Permit flexible message flow with KUDOS messages as any request/response.

    • -
  • -

    Enable sending KUDOS messages as regular application messages

    +
  • +

    Enable sending KUDOS messages as regular application messages.

-
+

-C.2. Version -05 to -06 +D.2. Version -05 to -06

    -
  • -

    Mandate support for both the forward and reverse message flow.

    +
  • +

    Mandate support for both the forward and reverse message flow.

    • -
  • -

    Mention the EDHOC and OSCORE profile of ACE as method for rekeying.

    +
  • +

    Mention the EDHOC and OSCORE profile of ACE as method for rekeying.

    • -
  • -

    Clarify definition of KUDOS (request/response) message.

    +
  • +

    Clarify definition of KUDOS (request/response) message.

    • -
  • -

    Further extend the OSCORE option to transport N1 in the second KUDOS message as a request.

    +
  • +

    Further extend the OSCORE option to transport N1 in the second KUDOS message as a request.

    • -
  • -

    Mandate support for the no-FS mode on CAPABLE devices.

    +
  • +

    Mandate support for the no-FS mode on CAPABLE devices.

    • -
  • -

    Explain when KUDOS fails during selection of mode.

    +
  • +

    Explain when KUDOS fails during selection of mode.

    • -
  • -

    Explicitly forbid using old keying material after reboot.

    +
  • +

    Explicitly forbid using old keying material after reboot.

    • -
  • -

    Editorial improvements.

    +
  • +

    Editorial improvements.

-
+

-C.3. Version -04 to -05 +D.3. Version -04 to -05

    -
  • -

    Note on client retransmissions if KUDOS execution fails in reverse message flow.

    +
  • +

    Note on client retransmissions if KUDOS execution fails in reverse message flow.

    • -
  • -

    Specify what information needs to be written to non-volatile memory to handle reboots.

    +
  • +

    Specify what information needs to be written to non-volatile memory to handle reboots.

    • -
  • -

    Extended recommendations and considerations on minimum size of nonces N1 & N2.

    +
  • +

    Extended recommendations and considerations on minimum size of nonces N1 & N2.

    • -
  • -

    Arbitrary maximum size of the Recipient-ID Option.

    +
  • +

    Arbitrary maximum size of the Recipient-ID Option.

    • -
  • -

    Detailed lifecycle of the OSCORE IDs update procedure.

    +
  • +

    Detailed lifecycle of the OSCORE IDs update procedure.

    • -
  • -

    Described examples of OSCORE IDs update procedure.

    +
  • +

    Described examples of OSCORE IDs update procedure.

    • -
  • -

    Examples of OSCORE IDs update procedure integrated in KUDOS.

    +
  • +

    Examples of OSCORE IDs update procedure integrated in KUDOS.

    • -
  • -

    Considerations about using SCHC for CoAP with OSCORE.

    +
  • +

    Considerations about using SCHC for CoAP with OSCORE.

    • -
  • -

    Clarifications and editorial improvements.

    +
  • +

    Clarifications and editorial improvements.

-
+

-C.4. Version -03 to -04 +D.4. Version -03 to -04

    -
  • -

    Removed content about key usage limits.

    +
  • +

    Removed content about key usage limits.

    • -
  • -

    Use of "forward message flow" and "reverse message flow".

    +
  • +

    Use of "forward message flow" and "reverse message flow".

    • -
  • -

    Update to RFC 8613 extended to include protection of responses.

    +
  • +

    Update to RFC 8613 extended to include protection of responses.

    • -
  • -

    Include EDHOC_KeyUpdate() in the methods for rekeying.

    +
  • +

    Include EDHOC_KeyUpdate() in the methods for rekeying.

    • -
  • -

    Describe reasons for using the OSCORE ID update procedure.

    +
  • +

    Describe reasons for using the OSCORE ID update procedure.

    • -
  • -

    Clarifications on deletion of CTX_OLD and CTX_NEW.

    +
  • +

    Clarifications on deletion of CTX_OLD and CTX_NEW.

    • -
  • -

    Added new section on preventing deadlocks.

    +
  • +

    Added new section on preventing deadlocks.

    • -
  • -

    Clarified that peers can decide to run KUDOS at any point.

    +
  • +

    Clarified that peers can decide to run KUDOS at any point.

    • -
  • -

    Defined preservation of observations beyond OSCORE ID updates.

    +
  • +

    Defined preservation of observations beyond OSCORE ID updates.

    • -
  • -

    Revised discussion section, including also communication overhead.

    +
  • +

    Revised discussion section, including also communication overhead.

    • -
  • -

    Defined a well-known KUDOS resource and a KUDOS resource type.

    +
  • +

    Defined a well-known KUDOS resource and a KUDOS resource type.

    • -
  • -

    Editorial improvements.

    +
  • +

    Editorial improvements.

-
+

-C.5. Version -02 to -03 +D.5. Version -02 to -03

    -
  • -

    Use of the OSCORE flag bit 0 to signal more flag bits.

    +
  • +

    Use of the OSCORE flag bit 0 to signal more flag bits.

    • -
  • -

    In UpdateCtx(), open for future key derivation different than HKDF.

    +
  • +

    In UpdateCtx(), open for future key derivation different than HKDF.

    • -
  • -

    Simplified updateCtx() to use only Expand(); used to be METHOD 2.

    +
  • +

    Simplified updateCtx() to use only Expand(); used to be METHOD 2.

    • -
  • -

    Included the Partial IV if the second KUDOS message is a response.

    +
  • +

    Included the Partial IV if the second KUDOS message is a response.

    • -
  • -

    Added signaling of support for KUDOS in EDHOC.

    +
  • +

    Added signaling of support for KUDOS in EDHOC.

    • -
  • -

    Clarifications on terminology and reasons for rekeying.

    +
  • +

    Clarifications on terminology and reasons for rekeying.

    • -
  • -

    Updated IANA considerations.

    +
  • +

    Updated IANA considerations.

    • -
  • -

    Editorial improvements.

    +
  • +

    Editorial improvements.

-
+

-C.6. Version -01 to -02 +D.6. Version -01 to -02

    -
  • -

    Extended terminology.

    +
  • +

    Extended terminology.

    • -
  • -

    Moved procedure for preserving observations across key updates to main body.

    +
  • +

    Moved procedure for preserving observations across key updates to main body.

    • -
  • -

    Moved procedure to update OSCORE Sender/Recipient IDs to main body.

    +
  • +

    Moved procedure to update OSCORE Sender/Recipient IDs to main body.

    • -
  • -

    Moved key update without forward secrecy section to main body.

    +
  • +

    Moved key update without forward secrecy section to main body.

    • -
  • -

    Define signaling bits present in the 'x' byte.

    +
  • +

    Define signaling bits present in the 'x' byte.

    • -
  • -

    Modifications and alignment of updateCtx() with EDHOC.

    +
  • +

    Modifications and alignment of updateCtx() with EDHOC.

    • -
  • -

    Rules for deletion of old EDHOC keys PRK_out and PRK_exporter.

    +
  • +

    Rules for deletion of old EDHOC keys PRK_out and PRK_exporter.

    • -
  • -

    Describe CBOR wrapping of involved nonces with examples.

    +
  • +

    Describe CBOR wrapping of involved nonces with examples.

    • -
  • -

    Renamed 'id detail' to 'nonce'.

    +
  • +

    Renamed 'id detail' to 'nonce'.

    • -
  • -

    Editorial improvements.

    +
  • +

    Editorial improvements.

-
+

-C.7. Version -00 to -01 +D.7. Version -00 to -01

    -
  • -

    Recommendation on limits for CCM_8. Details in Appendix.

    +
  • +

    Recommendation on limits for CCM_8. Details in Appendix.

    • -
  • -

    Improved message processing, also covering corner cases.

    +
  • +

    Improved message processing, also covering corner cases.

    • -
  • -

    Example of method to estimate and not store 'count_q'.

    +
  • +

    Example of method to estimate and not store 'count_q'.

    • -
  • -

    Added procedure to update OSCORE Sender/Recipient IDs.

    +
  • +

    Added procedure to update OSCORE Sender/Recipient IDs.

    • -
  • -

    Added method for preserving observations across key updates.

    +
  • +

    Added method for preserving observations across key updates.

    • -
  • -

    Added key update without forward secrecy.

    +
  • +

    Added key update without forward secrecy.

@@ -3121,16 +3225,16 @@

-
+

Acknowledgments

-

The authors sincerely thank Christian Amsüss, Carsten Bormann, Rafa Marin-Lopez, John Preuß Mattsson, and Göran Selander for their feedback and comments.

-

The work on this document has been partly supported by VINNOVA and the Celtic-Next project CRITISEC; and by the H2020 projects SIFIS-Home (Grant agreement 952652) and ARCADIAN-IoT (Grant agreement 101020259).

+

The authors sincerely thank Christian Amsüss, Carsten Bormann, Rafa Marin-Lopez, John Preuß Mattsson, and Göran Selander for their feedback and comments.

+

The work on this document has been partly supported by VINNOVA and the Celtic-Next project CRITISEC; and by the H2020 projects SIFIS-Home (Grant agreement 952652) and ARCADIAN-IoT (Grant agreement 101020259).

-
+

Authors' Addresses

diff --git a/draft-ietf-core-oscore-key-update.txt b/draft-ietf-core-oscore-key-update.txt index 6031244..21c7432 100644 --- a/draft-ietf-core-oscore-key-update.txt +++ b/draft-ietf-core-oscore-key-update.txt @@ -104,16 +104,18 @@ Table of Contents 7.1. Normative References 7.2. Informative References Appendix A. Forward Message Flow using two CoAP Requests - Appendix B. Forward Message Flow Targeting Arbitrary Resource at + Appendix B. Forward Message Flow with Response 1 unrelated to + Request 1 + Appendix C. Forward Message Flow Targeting Arbitrary Resource at Server - Appendix C. Document Updates - C.1. Version -06 to -07 - C.2. Version -05 to -06 - C.3. Version -04 to -05 - C.4. Version -03 to -04 - C.5. Version -02 to -03 - C.6. Version -01 to -02 - C.7. Version -00 to -01 + Appendix D. Document Updates + D.1. Version -06 to -07 + D.2. Version -05 to -06 + D.3. Version -04 to -05 + D.4. Version -03 to -04 + D.5. Version -02 to -03 + D.6. Version -01 to -02 + D.7. Version -00 to -01 Acknowledgments Authors' Addresses @@ -741,7 +743,9 @@ Table of Contents response, KUDOS is not constrained to this request/response model and a KUDOS execution can be performed with any combination of CoAP requests and responses. Appendix A shows an example where both KUDOS - messages are CoAP requests. + messages are CoAP requests. Furthermore, Appendix B presents an + example where KUDOS Response #2 is a response to a different request + than KUDOS Request #1. Client Server (initiator) (responder) @@ -948,7 +952,7 @@ Table of Contents CoAP Echo option as defined in [RFC9175] which the procedure defined in this paragraph is analogous in functionality to. An example of a KUDOS execution where KUDOS Request #1 targets a normal resource is - shown in Appendix B. + shown in Appendix C. 4.3.1.1. Avoiding In-Transit Requests During a Key Update @@ -2339,7 +2343,98 @@ Appendix A. Forward Message Flow using two CoAP Requests Figure 7: Example of the KUDOS forward message flow where both KUDOS messages are requests. -Appendix B. Forward Message Flow Targeting Arbitrary Resource at Server +Appendix B. Forward Message Flow with Response 1 unrelated to Request 1 + + This section presents an example of KUDOS run in the forward message + flow, with the client acting as KUDOS initiator, where KUDOS Response + #2 is not a response to KUDOS Request #1 but rather an unrelated + Observer notification. + + Client Server + (initiator) (responder) + | | + | Request | + | (Registration) | + Protect with CTX_OLD |--------------------->| /obs + | Token: 0x4a | + | Observe: 0 | + | OSCORE { | + | ... | + | Partial IV: 4324 | + | ... | + | } | + | Encrypted Payload { | Verify with CTX_OLD + | Observe: 0 | + | ... | + | } | + | | + Generate N1 | | + | | + CTX_1 = updateCtx( | | + X1, | | + N1, | | + CTX_OLD) | | + | | + | Request #1 | + Protect with CTX_1 |--------------------->| /.well-known/kudos + | Token: 0x7c | + | OSCORE { | + | ... | + | Partial IV: 0 | + | ... | + | d flag: 1 | CTX_1 = updateCtx( + | x: X1 | X1, + | nonce: N1 | N1, + | ... | CTX_OLD) + | } | + | Encrypted Payload { | Verify with CTX_1 + | ... | + | } | Generate N2 + | | + | | CTX_NEW = updateCtx( + | | Comb(X1,X2), + | | Comb(N1,N2), + | | CTX_OLD) + | | + | Response #1 | + | (Notification) | + |<---------------------| Protect with CTX_NEW + | Token: 0x4a | + | Observe: 1 | + | OSCORE { | + | ... | + CTX_NEW = updateCtx( | Partial IV: 0 | + Comb(X1,X2), | ... | + Comb(N1,N2), | d flag: 1 | + CTX_OLD) | x: X2 | + | nonce: N2 | + Verify with CTX_NEW | ... | + | } | + Discard CTX_OLD | Encrypted Payload { | + | Observe: 1 | + | ... | + | } | + | | + + // The actual key update process ends here. + // The two peers can use the new Security Context CTX_NEW. + + | Response #2 | + |<---------------------| Protect with CTX_NEW + | Token: 0x7c | + | OSCORE { | + | ... | + Verify with CTX_NEW | } | + | Encrypted Payload { | + | ... | + | Application Payload | + | } | + | | + + Figure 8: Example of the KUDOS forward message flow where KUDOS + Response #2 is not a response to KUDOS Request #1. + +Appendix C. Forward Message Flow Targeting Arbitrary Resource at Server This section presents an example of KUDOS run in the forward message flow, with the client acting as KUDOS initiator, and targeting a @@ -2422,26 +2517,28 @@ Appendix B. Forward Message Flow Targeting Arbitrary Resource at Server | } | | | - Figure 8: Example of the KUDOS forward message flow where KUDOS + Figure 9: Example of the KUDOS forward message flow where KUDOS Request #1 targets a normal resource. -Appendix C. Document Updates +Appendix D. Document Updates RFC EDITOR: PLEASE REMOVE THIS SECTION. -C.1. Version -06 to -07 +D.1. Version -06 to -07 * Removed material about the ID update procedure, which has been split out into a separate draft. * Allow non-random nonces for CAPABLE devices. - * Add example showing flexible message flow with two KUDOS messages - as CoAP requests. + * Editorial improvements. + + * Permit flexible message flow with KUDOS messages as any request/ + response. - * Enable sending KUDOS messages as regular application messages + * Enable sending KUDOS messages as regular application messages. -C.2. Version -05 to -06 +D.2. Version -05 to -06 * Mandate support for both the forward and reverse message flow. @@ -2461,7 +2558,7 @@ C.2. Version -05 to -06 * Editorial improvements. -C.3. Version -04 to -05 +D.3. Version -04 to -05 * Note on client retransmissions if KUDOS execution fails in reverse message flow. @@ -2484,7 +2581,7 @@ C.3. Version -04 to -05 * Clarifications and editorial improvements. -C.4. Version -03 to -04 +D.4. Version -03 to -04 * Removed content about key usage limits. @@ -2510,7 +2607,7 @@ C.4. Version -03 to -04 * Editorial improvements. -C.5. Version -02 to -03 +D.5. Version -02 to -03 * Use of the OSCORE flag bit 0 to signal more flag bits. @@ -2529,7 +2626,7 @@ C.5. Version -02 to -03 * Editorial improvements. -C.6. Version -01 to -02 +D.6. Version -01 to -02 * Extended terminology. @@ -2553,7 +2650,7 @@ C.6. Version -01 to -02 * Editorial improvements. -C.7. Version -00 to -01 +D.7. Version -00 to -01 * Recommendation on limits for CCM_8. Details in Appendix.