Skip to content

Commit f443777

Browse files
rikard-sicsrikard-sics
committed
Message flow examples and editorial fixes - closes #5 
1 parent 8dcc6ab commit f443777

File tree

1 file changed

+253
-3
lines changed

1 file changed

+253
-3
lines changed

‎draft-ietf-core-oscore-id-update.md‎

Lines changed: 253 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -95,8 +95,6 @@ Furthermore, this procedure can be executed stand-alone, or instead seamlessly i
9595

9696
As defined in {{id-update-additional-actions}}, the two peers must take additional actions to ensure a safe execution of the OSCORE ID update procedure.
9797

98-
A peer can safely discard the old OSCORE Security Context including the old OSCORE Sender/Recipient IDs after the following two events have occurred, in this order: first, the peer has sent to the other peer a message protected with the new OSCORE Security Context including the new OSCORE Sender/Recipient IDs; then, the peer has received from the other peer and successfully verified a message protected with that new OSCORE Security Context.
99-
10098
The new OSCORE Sender/Recipient IDs MUST NOT be used with the OSCORE Security Context CTX\_OLD, and MUST NOT be used with the temporary OSCORE Security Context CTX\_TEMP used to protect the first KUDOS message of a KUDOS execution.
10199

102100
A peer MUST NOT initiate an OSCORE ID update procedure with another peer, if it has another such procedure ongoing with that other peer.
@@ -204,7 +202,7 @@ The Recipient-ID-Ack Option is of class E in terms of OSCORE processing (see {{S
204202

205203
### OSCORE ID Update Procedure Initiated with a Request Message {#example-client-initiated-id-update}
206204

207-
{{fig-id-update-client-init}} shows an example of the OSCORE ID update procedure, run stand-alone and initiated by the client sending a request message. On each peer, SID and RID denote the OSCORE Sender ID and Recipient ID of that peer, respectively.
205+
{{fig-id-update-client-init}} shows an example of the OSCORE ID update procedure, run stand-alone and initiated by the client sending a request message. On each peer, SID and RID denote the OSCORE Sender ID and Recipient ID of that peer, respectively. An example where the server initiates the procedure is shown in {{example-server-initiated-id-update}}.
208206

209207
~~~~~~~~~~~ aasvg
210208
Client Server
@@ -419,9 +417,261 @@ Note to RFC Editor: Following the registration of the CoAP Option Number 32, ple
419417

420418
--- back
421419

420+
# Examples
421+
422+
This appendix provides examples where the OSCORE ID update procedure is used. In particular:
423+
424+
* {{example-server-initiated-id-update}} shows an example of the OSCORE ID update procedure initiated by the server sending a response message.
425+
* {{example-client-initiated-id-update-failure}} shows an example of the OSCORE ID update procedure initiated by the client sending a request message where the procedure fails to complete.
426+
427+
## OSCORE ID Update Procedure Initiated with a Response Message {#example-server-initiated-id-update}
428+
429+
{{fig-id-update-server-init}} shows an example of the OSCORE ID update procedure, run stand-alone and initiated by the server sending a response message. On each peer, SID and RID denote the OSCORE Sender ID and Recipient ID of that peer, respectively. The prerequisites and the actions taken by the peers involved are aligned with what is described in {{example-client-initiated-id-update}}, except that it is the server that takes the initiative to perform the OSCORE ID update procedure.
430+
431+
~~~~~~~~~~~ aasvg
432+
Client Server
433+
| |
434+
CTX_A { | | CTX_A {
435+
SID = 0x01 | | SID = 0x00
436+
RID = 0x00 | | RID = 0x01
437+
} | | }
438+
| |
439+
| Request #1 |
440+
|---------------------------------->| /temp
441+
| OSCORE { |
442+
| ... |
443+
| kid: 0x01 |
444+
| } |
445+
| Encrypted Payload { |
446+
| ... |
447+
| Application Payload |
448+
| } |
449+
| |
450+
| Response #1 |
451+
|<----------------------------------| Protect
452+
| OSCORE { | with CTX_A
453+
| ... |
454+
Verify | } |
455+
with CTX_A | Encrypted Payload { |
456+
| ... |
457+
| Recipient-ID: 0x42 |
458+
| ... |
459+
| Application Payload |
460+
| } |
461+
| |
462+
| |
463+
| |
464+
| Request #2 |
465+
Protect |---------------------------------->| /temp
466+
with CTX_A | OSCORE { |
467+
| ... |
468+
| kid: 0x01 | Verify
469+
| } | with CTX_A
470+
| Encrypted Payload { |
471+
| ... |
472+
| Recipient-ID: 0x78 |
473+
| Recipient-ID-Ack: 0x42 |
474+
| ... |
475+
| Application Payload |
476+
| } |
477+
| |
478+
| Response #2 |
479+
|<----------------------------------| Protect
480+
| OSCORE { | with CTX_A
481+
| ... |
482+
Verify | } |
483+
with CTX_A | Encrypted Payload { |
484+
| ... |
485+
| Recipient-ID-Ack: 0x78 |
486+
| ... |
487+
| Application Payload |
488+
| } |
489+
| |
490+
| |
491+
| Request #3 |
492+
Protect |---------------------------------->| /temp
493+
with CTX_A | OSCORE { |
494+
| ... |
495+
| kid: 0x01 | Verify
496+
| } | with CTX_A
497+
| Encrypted Payload { |
498+
| ... |
499+
| Recipient-ID-Ack: 0x42 |
500+
| Application Payload |
501+
| } |
502+
| |
503+
| Response #3 |
504+
|<----------------------------------| Protect
505+
| OSCORE { | with CTX_A
506+
| ... |
507+
Verify | } |
508+
with CTX_A | Encrypted Payload { |
509+
| ... |
510+
| Recipient-ID-Ack: 0x78 |
511+
| ... |
512+
| Application Payload |
513+
| } |
514+
| |
515+
| |
516+
| |
517+
| |
518+
| |
519+
| Request #4 |
520+
Protect |---------------------------------->| /temp
521+
with CTX_A | OSCORE { |
522+
| ... |
523+
| kid: 0x01 | Verify
524+
| } | with CTX_A
525+
| Encrypted Payload { |
526+
| ... |
527+
| Recipient-ID-Ack: 0x42 |
528+
| Application Payload |
529+
| } |
530+
| |
531+
| | Safe to
532+
| | discard
533+
| | CTX_A
534+
| |
535+
| Response #4 |
536+
|<----------------------------------| Protect
537+
| OSCORE { | with CTX_A
538+
| ... |
539+
Verify | } |
540+
with CTX_A | Encrypted Payload { |
541+
| ... |
542+
Safe to | Recipient-ID-Ack: 0x78 |
543+
discard | ... |
544+
CTX_A | Application Payload |
545+
| } |
546+
| |
547+
~~~~~~~~~~~
548+
{: #fig-id-update-server-init title="Example of the OSCORE ID update procedure initiated with a response message" artwork-align="center"}
549+
550+
## Failure of the OSCORE ID Update Procedure Initiated with a Request Message {#example-client-initiated-id-update-failure}
551+
552+
{{fig-id-update-client-init-failure}} shows an example of the OSCORE ID update procedure, run stand-alone and initiated by the client sending a request message where the procedure fails to complete due to the server not including the Recipient-ID-Ack option or the Recipient-ID in its response messages. On each peer, SID and RID denote the OSCORE Sender ID and Recipient ID of that peer, respectively. This example assumes that the value of the REPEAT\_TIMER on the client is such that it expires between each request the client sends.
553+
554+
The client repeatedly tries sending requests to the client including the Recipient-ID option, but does not receive acknowledgments in the form of responses containing the Response-ID-Ack option from the server. Thus the client eventually reaches the expiration of its ENDING\_TIMER, aborts the OSCORE ID update procedure, and proceeds to continue communication with normal OSCORE messages.
555+
556+
~~~~~~~~~~~ aasvg
557+
Client Server
558+
| |
559+
CTX_A { | | CTX_A {
560+
SID = 0x01 | | SID = 0x00
561+
RID = 0x00 | | RID = 0x01
562+
} | | }
563+
| |
564+
| Request #1 |
565+
Protect |---------------------------------->| /temp
566+
with CTX_A | OSCORE { |
567+
| ... |
568+
| kid: 0x01 | Verify
569+
| } | with CTX_A
570+
| Encrypted Payload { |
571+
| ... |
572+
| Recipient-ID: 0x42 |
573+
| ... |
574+
| Application Payload |
575+
| } |
576+
| |
577+
| Response #1 |
578+
|<----------------------------------| Protect
579+
| OSCORE { | with CTX_A
580+
| ... |
581+
Verify | } |
582+
with CTX_A | Encrypted Payload { |
583+
| ... |
584+
| Application Payload |
585+
| } |
586+
| |
587+
| |
588+
| |
589+
| Request #2 |
590+
Protect |---------------------------------->| /temp
591+
with CTX_A | OSCORE { |
592+
| ... |
593+
| kid: 0x01 | Verify
594+
| } | with CTX_A
595+
| Encrypted Payload { |
596+
| ... |
597+
| Recipient-ID: 0x42 |
598+
| ... |
599+
| Application Payload |
600+
| } |
601+
| |
602+
| Response #2 |
603+
|<----------------------------------| Protect
604+
| OSCORE { | with CTX_A
605+
| ... |
606+
Verify | } |
607+
with CTX_A | Encrypted Payload { |
608+
| ... |
609+
| Application Payload |
610+
| } |
611+
| |
612+
| |
613+
| Request #3 |
614+
Protect |---------------------------------->| /temp
615+
with CTX_A | OSCORE { |
616+
| ... |
617+
| kid: 0x01 | Verify
618+
| } | with CTX_A
619+
| Encrypted Payload { |
620+
| ... |
621+
| Recipient-ID: 0x42 |
622+
| ... |
623+
| Application Payload |
624+
| } |
625+
| |
626+
| Response #3 |
627+
|<----------------------------------| Protect
628+
| OSCORE { | with CTX_A
629+
| ... |
630+
Verify | } |
631+
with CTX_A | Encrypted Payload { |
632+
| ... |
633+
| Application Payload |
634+
| } |
635+
| |
636+
ENDING_ | |
637+
TIMER | |
638+
expired | |
639+
| |
640+
| Request #4 |
641+
Protect |---------------------------------->| /temp
642+
with CTX_A | OSCORE { |
643+
| ... |
644+
| kid: 0x01 | Verify
645+
| } | with CTX_A
646+
| Encrypted Payload { |
647+
| ... |
648+
| Application Payload |
649+
| } |
650+
| |
651+
| |
652+
| |
653+
| Response #4 |
654+
|<----------------------------------| Protect
655+
| OSCORE { | with CTX_A
656+
| ... |
657+
Verify | } |
658+
with CTX_A | Encrypted Payload { |
659+
| ... |
660+
| Application Payload |
661+
| } |
662+
| |
663+
~~~~~~~~~~~
664+
{: #fig-id-update-client-init-failure title="Example of the OSCORE ID update procedure failing when initiated with a request message" artwork-align="center"}
665+
422666
# Document Updates # {#sec-document-updates}
423667
{:removeinrfc}
424668

669+
## Version -04 to -05 ## {#sec-04-05}
670+
671+
* Editorial updates.
672+
673+
* Add additional message flow examples, including a failure case.
674+
425675
## Version -03 to -04 ## {#sec-03-04}
426676

427677
* Fixes in presenting the new approach.

0 commit comments

Comments
 (0)