-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathdraft-wood-icnrg-ccnxkeyexchange-01.html
1458 lines (1388 loc) · 80.2 KB
/
draft-wood-icnrg-ccnxkeyexchange-01.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<title>CCNx Key Exchange Protocol Version 1.0</title>
<style type="text/css" title="Xml2Rfc (sans serif)">
/*<![CDATA[*/
a {
text-decoration: none;
}
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a.smpl {
color: black;
}
a:hover {
text-decoration: underline;
}
a:active {
text-decoration: underline;
}
address {
margin-top: 1em;
margin-left: 2em;
font-style: normal;
}
body {
color: black;
font-family: verdana, helvetica, arial, sans-serif;
font-size: 10pt;
max-width: 55em;
}
cite {
font-style: normal;
}
dd {
margin-right: 2em;
}
dl {
margin-left: 2em;
}
ul.empty {
list-style-type: none;
}
ul.empty li {
margin-top: .5em;
}
dl p {
margin-left: 0em;
}
dt {
margin-top: .5em;
}
h1 {
font-size: 14pt;
line-height: 21pt;
page-break-after: avoid;
}
h1.np {
page-break-before: always;
}
h1 a {
color: #333333;
}
h2 {
font-size: 12pt;
line-height: 15pt;
page-break-after: avoid;
}
h3, h4, h5, h6 {
font-size: 10pt;
page-break-after: avoid;
}
h2 a, h3 a, h4 a, h5 a, h6 a {
color: black;
}
img {
margin-left: 3em;
}
li {
margin-left: 2em;
margin-right: 2em;
}
ol {
margin-left: 2em;
margin-right: 2em;
}
ol p {
margin-left: 0em;
}
p {
margin-left: 2em;
margin-right: 2em;
}
pre {
margin-left: 3em;
background-color: lightyellow;
padding: .25em;
}
pre.text2 {
border-style: dotted;
border-width: 1px;
background-color: #f0f0f0;
width: 69em;
}
pre.inline {
background-color: white;
padding: 0em;
}
pre.text {
border-style: dotted;
border-width: 1px;
background-color: #f8f8f8;
width: 69em;
}
pre.drawing {
border-style: solid;
border-width: 1px;
background-color: #f8f8f8;
padding: 2em;
}
table {
margin-left: 2em;
}
table.tt {
vertical-align: top;
}
table.full {
border-style: outset;
border-width: 1px;
}
table.headers {
border-style: outset;
border-width: 1px;
}
table.tt td {
vertical-align: top;
}
table.full td {
border-style: inset;
border-width: 1px;
}
table.tt th {
vertical-align: top;
}
table.full th {
border-style: inset;
border-width: 1px;
}
table.headers th {
border-style: none none inset none;
border-width: 1px;
}
table.left {
margin-right: auto;
}
table.right {
margin-left: auto;
}
table.center {
margin-left: auto;
margin-right: auto;
}
caption {
caption-side: bottom;
font-weight: bold;
font-size: 9pt;
margin-top: .5em;
}
table.header {
border-spacing: 1px;
width: 95%;
font-size: 10pt;
color: white;
}
td.top {
vertical-align: top;
}
td.topnowrap {
vertical-align: top;
white-space: nowrap;
}
table.header td {
background-color: gray;
width: 50%;
}
table.header a {
color: white;
}
td.reference {
vertical-align: top;
white-space: nowrap;
padding-right: 1em;
}
thead {
display:table-header-group;
}
ul.toc, ul.toc ul {
list-style: none;
margin-left: 1.5em;
margin-right: 0em;
padding-left: 0em;
}
ul.toc li {
line-height: 150%;
font-weight: bold;
font-size: 10pt;
margin-left: 0em;
margin-right: 0em;
}
ul.toc li li {
line-height: normal;
font-weight: normal;
font-size: 9pt;
margin-left: 0em;
margin-right: 0em;
}
li.excluded {
font-size: 0pt;
}
ul p {
margin-left: 0em;
}
.comment {
background-color: yellow;
}
.center {
text-align: center;
}
.error {
color: red;
font-style: italic;
font-weight: bold;
}
.figure {
font-weight: bold;
text-align: center;
font-size: 9pt;
}
.filename {
color: #333333;
font-weight: bold;
font-size: 12pt;
line-height: 21pt;
text-align: center;
}
.fn {
font-weight: bold;
}
.hidden {
display: none;
}
.left {
text-align: left;
}
.right {
text-align: right;
}
.title {
color: #990000;
font-size: 18pt;
line-height: 18pt;
font-weight: bold;
text-align: center;
margin-top: 36pt;
}
.vcardline {
display: block;
}
.warning {
font-size: 14pt;
background-color: yellow;
}
@media print {
.noprint {
display: none;
}
a {
color: black;
text-decoration: none;
}
table.header {
width: 90%;
}
td.header {
width: 50%;
color: black;
background-color: white;
vertical-align: top;
font-size: 12pt;
}
ul.toc a::after {
content: leader('.') target-counter(attr(href), page);
}
ul.ind li li a {
content: target-counter(attr(href), page);
}
.print2col {
column-count: 2;
-moz-column-count: 2;
column-fill: auto;
}
}
@page {
@top-left {
content: "Internet-Draft";
}
@top-right {
content: "December 2010";
}
@top-center {
content: "Abbreviated Title";
}
@bottom-left {
content: "Doe";
}
@bottom-center {
content: "Expires June 2011";
}
@bottom-right {
content: "[Page " counter(page) "]";
}
}
@page:first {
@top-left {
content: normal;
}
@top-right {
content: normal;
}
@top-center {
content: normal;
}
}
/*]]>*/
</style>
<link href="#rfc.toc" rel="Contents"/>
<link href="#rfc.section.1" rel="Chapter" title="1 Introduction"/>
<link href="#rfc.section.1.1" rel="Chapter" title="1.1 Conventions and Terminology"/>
<link href="#rfc.section.2" rel="Chapter" title="2 Goals"/>
<link href="#rfc.section.3" rel="Chapter" title="3 Scope"/>
<link href="#rfc.section.4" rel="Chapter" title="4 Presentation Language"/>
<link href="#rfc.section.5" rel="Chapter" title="5 CCNxKE Overview"/>
<link href="#rfc.section.5.1" rel="Chapter" title="5.1 Connection Establishment Latency"/>
<link href="#rfc.section.5.2" rel="Chapter" title="5.2 Connection Migration and Resumption"/>
<link href="#rfc.section.5.3" rel="Chapter" title="5.3 Re-Transmissions, Timeouts, and Replay Prevention"/>
<link href="#rfc.section.5.4" rel="Chapter" title="5.4 Loss Sensitivity"/>
<link href="#rfc.section.6" rel="Chapter" title="6 The CCNxKE Protocol"/>
<link href="#rfc.section.6.1" rel="Chapter" title="6.1 Round Overview"/>
<link href="#rfc.section.6.2" rel="Chapter" title="6.2 Round 1"/>
<link href="#rfc.section.6.3" rel="Chapter" title="6.3 Round 2"/>
<link href="#rfc.section.6.4" rel="Chapter" title="6.4 Round 3"/>
<link href="#rfc.section.7" rel="Chapter" title="7 Alternative Exchanges"/>
<link href="#rfc.section.7.1" rel="Chapter" title="7.1 One-RTT Exchange"/>
<link href="#rfc.section.8" rel="Chapter" title="8 Resumption and PSK Mode"/>
<link href="#rfc.section.9" rel="Chapter" title="9 Secret Derivation"/>
<link href="#rfc.section.9.1" rel="Chapter" title="9.1 SourceCookie Derivation"/>
<link href="#rfc.section.9.2" rel="Chapter" title="9.2 Move Derivation"/>
<link href="#rfc.section.9.3" rel="Chapter" title="9.3 SessionID and ResumptionCookie Properties, Derivation, and Usage"/>
<link href="#rfc.section.9.4" rel="Chapter" title="9.4 Key Derivation"/>
<link href="#rfc.section.9.5" rel="Chapter" title="9.5 Secret Generation and Lifecycle"/>
<link href="#rfc.section.10" rel="Chapter" title="10 Re-Key Message"/>
<link href="#rfc.section.11" rel="Chapter" title="11 Application Data Protocol"/>
<link href="#rfc.section.12" rel="Chapter" title="12 Security Considerations"/>
<link href="#rfc.references" rel="Chapter" title="13 References"/>
<link href="#rfc.references.1" rel="Chapter" title="13.1 Normative References"/>
<link href="#rfc.references.2" rel="Chapter" title="13.2 Informative References"/>
<link href="#rfc.authors" rel="Chapter"/>
<meta name="generator" content="xml2rfc version 2.5.1 - http://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
<meta name="dct.creator" content="Mosko, M., Uzun, E., and C. Wood" />
<meta name="dct.identifier" content="urn:ietf:id:draft-wood-ccnxkeyexchange-01" />
<meta name="dct.issued" scheme="ISO8601" content="2016-4-06" />
<meta name="dct.abstract" content="This document specifies Version 1.0 of the CCNx Key Exchange (CCNxKE) protocol. The CCNxKE protocol allows two peers to establish a shared, forward-secure key for secure and confidential communication. The protocol is designed to prevent eavesdropping, tampering, and message forgery between two peers. It is also designed to minimize the number of rounds required to establish a shared key. In the worst case, it requires two RTTs between a consumer and producer to establish a shared key. In the best case, one RTT is required before sending any application data. This document outlines how to derive the keys used to encrypt traffic. An annex provides an example peer-to-peer transport protocol for exchanging encrypted CCNx communications." />
<meta name="description" content="This document specifies Version 1.0 of the CCNx Key Exchange (CCNxKE) protocol. The CCNxKE protocol allows two peers to establish a shared, forward-secure key for secure and confidential communication. The protocol is designed to prevent eavesdropping, tampering, and message forgery between two peers. It is also designed to minimize the number of rounds required to establish a shared key. In the worst case, it requires two RTTs between a consumer and producer to establish a shared key. In the best case, one RTT is required before sending any application data. This document outlines how to derive the keys used to encrypt traffic. An annex provides an example peer-to-peer transport protocol for exchanging encrypted CCNx communications." />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left">icnrg</td>
<td class="right">M. Mosko</td>
</tr>
<tr>
<td class="left">Internet-Draft</td>
<td class="right">E. Uzun</td>
</tr>
<tr>
<td class="left">Intended status: Standards Track</td>
<td class="right">C. Wood</td>
</tr>
<tr>
<td class="left">Expires: October 8, 2016</td>
<td class="right">PARC</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">April 06, 2016</td>
</tr>
</tbody>
</table>
<p class="title">CCNx Key Exchange Protocol Version 1.0<br />
<span class="filename">draft-wood-ccnxkeyexchange-01</span></p>
<h1 id="rfc.abstract">
<a href="#rfc.abstract">Abstract</a>
</h1>
<p>This document specifies Version 1.0 of the CCNx Key Exchange (CCNxKE) protocol. The CCNxKE protocol allows two peers to establish a shared, forward-secure key for secure and confidential communication. The protocol is designed to prevent eavesdropping, tampering, and message forgery between two peers. It is also designed to minimize the number of rounds required to establish a shared key. In the worst case, it requires two RTTs between a consumer and producer to establish a shared key. In the best case, one RTT is required before sending any application data. This document outlines how to derive the keys used to encrypt traffic. An annex provides an example peer-to-peer transport protocol for exchanging encrypted CCNx communications.</p>
<h1 id="rfc.status">
<a href="#rfc.status">Status of This Memo</a>
</h1>
<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
<p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.</p>
<p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."</p>
<p>This Internet-Draft will expire on October 8, 2016.</p>
<h1 id="rfc.copyrightnotice">
<a href="#rfc.copyrightnotice">Copyright Notice</a>
</h1>
<p>Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
<p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p>
<hr class="noprint" />
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
<li>1. <a href="#rfc.section.1">Introduction</a></li>
<ul><li>1.1. <a href="#rfc.section.1.1">Conventions and Terminology</a></li>
</ul><li>2. <a href="#rfc.section.2">Goals</a></li>
<li>3. <a href="#rfc.section.3">Scope</a></li>
<li>4. <a href="#rfc.section.4">Presentation Language</a></li>
<li>5. <a href="#rfc.section.5">CCNxKE Overview</a></li>
<ul><li>5.1. <a href="#rfc.section.5.1">Connection Establishment Latency</a></li>
<li>5.2. <a href="#rfc.section.5.2">Connection Migration and Resumption</a></li>
<li>5.3. <a href="#rfc.section.5.3">Re-Transmissions, Timeouts, and Replay Prevention</a></li>
<li>5.4. <a href="#rfc.section.5.4">Loss Sensitivity</a></li>
</ul><li>6. <a href="#rfc.section.6">The CCNxKE Protocol</a></li>
<ul><li>6.1. <a href="#rfc.section.6.1">Round Overview</a></li>
<li>6.2. <a href="#rfc.section.6.2">Round 1</a></li>
<li>6.3. <a href="#rfc.section.6.3">Round 2</a></li>
<li>6.4. <a href="#rfc.section.6.4">Round 3</a></li>
</ul><li>7. <a href="#rfc.section.7">Alternative Exchanges</a></li>
<ul><li>7.1. <a href="#rfc.section.7.1">One-RTT Exchange</a></li>
</ul><li>8. <a href="#rfc.section.8">Resumption and PSK Mode</a></li>
<li>9. <a href="#rfc.section.9">Secret Derivation</a></li>
<ul><li>9.1. <a href="#rfc.section.9.1">SourceCookie Derivation</a></li>
<li>9.2. <a href="#rfc.section.9.2">Move Derivation</a></li>
<li>9.3. <a href="#rfc.section.9.3">SessionID and ResumptionCookie Properties, Derivation, and Usage</a></li>
<li>9.4. <a href="#rfc.section.9.4">Key Derivation</a></li>
<li>9.5. <a href="#rfc.section.9.5">Secret Generation and Lifecycle</a></li>
</ul><li>10. <a href="#rfc.section.10">Re-Key Message</a></li>
<li>11. <a href="#rfc.section.11">Application Data Protocol</a></li>
<li>12. <a href="#rfc.section.12">Security Considerations</a></li>
<li>13. <a href="#rfc.references">References</a></li>
<ul><li>13.1. <a href="#rfc.references.1">Normative References</a></li>
<li>13.2. <a href="#rfc.references.2">Informative References</a></li>
</ul><li><a href="#rfc.authors">Authors' Addresses</a></li>
</ul>
<h1 id="rfc.section.1"><a href="#rfc.section.1">1.</a> <a href="#introduction" id="introduction">Introduction</a></h1>
<p id="rfc.section.1.p.1">DISCLAIMER: This is a WIP draft of CCNxKE and has not yet seen rigorous security analysis.</p>
<p id="rfc.section.1.p.2">CCNx Key Exchange (CCNxKE) establishes ephemeral forward secure keys between two peers, called the consumer (client) and producer (server). The underlying cryptography of CCNxKE is similar to TLS 1.3, though there are some protocol changes due to the ICN nature of CCNxKE. CCNxKE also supports the concept of a MoveToken, which allows the authenticating producer to shift a session to one (or more) co-operating replicas.</p>
<p id="rfc.section.1.p.3">CCNxKE does not specify how the keys are used. It only specifies how to derive the traffic secret that could be used to encrypt/decrypt data. The draft [draft-wood-icnrg-tlvencap] specifies one way to use the traffic secret to carry out communications in a session.<br/> Annex A also sketches out an example CCNx protocol for exchanging encrypted messages, though it is not part of this standard. Other protocols may use CCNxKE.<br/> For example, a producer and replica may use CCNxKE to establish a shared key to use in Move Tokens. Two routers may use CCNxKE to establish MACSEC keys. A consumer and publisher could establish a symmetric key while on-line then publish content later for an off-line consumer. In short, the use of CCNxKE is not limited to a TLS-like transport protocol.</p>
<p id="rfc.section.1.p.4">CCNxKE allows upper-layer data to be returned in Round 3, like TLS 1.3. In this sense, one can achieve 3 RTT (worst case) or 1 RTT (best case) communcations. The data put in this response is up to the protocol using CCNxKE and may or may not be used.</p>
<p id="rfc.section.1.p.5">CCNxKE is not a substitue for data authenticity, such as Content Object provenance via signatures, group encryption of cached objects, or DRM protections. CCNxKE only creates a private, ephemeral tunnel between a consumer and a producer. CCNxKE expects that the encrypted communications protocol still carries normal CCNx packets with normal CCNx attributes such as signatures.</p>
<p id="rfc.section.1.p.6">Some types of ICN communications require emphemeral, forward secure encryption. Typical examples are on-line banking, real-time voice, or on-line shopping. Other applications may need different types of encryption and thus not use CCNxKE. There is currently no standard way for CCNx peers to exchange emphemeral, forward secure keys, thus this RFC specifies the standard mechanism that should be used by all CCNx peers for such keys. CCNxKE is built on the CCNx 1.0 protocol and only relies upon standard Interest and Content Objects as a vehicle for communication.</p>
<p id="rfc.section.1.p.7">In this document, the term ‘CCNxKE session’ refers to the key exchange session. It does not refer to a transport protocol session (like TLS) that uses the derived keys.</p>
<p id="rfc.section.1.p.8">This protocol has the following four main properties:</p>
<p/>
<ul>
<li>Each peer’s identity can be authenticated using asymmetric, or public key, cryptography (e.g., RSA <a href="#RSA">[RSA]</a>, ECDSA <a href="#ECDSA">[ECDSA]</a>, etc.). Server authentication is mandatory whereas mutual authentication is optional.</li>
<li>The negotiation of a forward-secure shared secret is protected from eavesdroppers and man-in-the-middle (MITM) attacks.</li>
<li>The negotiation is reliable: no attacker can modify the negotiation communication without being detected by the parties to the communication.</li>
<li>The state of a CCNxKE session can be securely migrated between an endpoint performing authentication and that which provides content using a “move token.” This allows authentication and authorization to be separated from encryption for a session, enabling different systems to complete these steps.</li>
</ul>
<p id="rfc.section.1.p.10">Usage of CCNxKE is entirely independent of upper-layer application protocols. CCNxKE may be used for any purpose that requires producer authentication and shared emphemeral forward-secure keys.</p>
<p id="rfc.section.1.p.11">CCNxKE also introduces a new type of cookie based on reverse hash chains <a href="#HASHCHAIN">[HASHCHAIN]</a> to help limit the amount of significant server work done in response to a client or consumer Interest. TCP-based protocols, such as TLS <a href="#TLS13">[TLS13]</a>, use the TCP 3-way handshake for such proof. UDP-based protocols, such as QUIC <a href="#QUIC">[QUIC]</a> and DTLS 1.2 <a href="#DTLS12">[DTLS12]</a>, use an optional session address token or cookie that must be presented by the client (consumer) to prove ownership of an address during a key exchange procedure. Without source addresses, our cookie technique ensures that the same entity which requested server information, e.g., the public configuration data, is the same entity that wishes to complete a key exchange.</p>
<p id="rfc.section.1.p.12">The main contribution of this work is adapting key exchange principles to the pull-based CCNx communication model. CCNxKE only assumes that a consumer knows a first name prefix to initiate the key exchange. The first Interest does not need to be a CCNxKE packet — the producer can signal back to the consumer that it requires a transport protocol using CCNxKE in the response.</p>
<p id="rfc.section.1.p.13">This specification does not subsume other ICN-compliant key exchange protocols. Nor does its existence imply that all encryption in an ICN must be based on sessions. It was designed specifically to solve the problem of session-based encryption in ICN.</p>
<h1 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1.</a> <a href="#conventions-and-terminology" id="conventions-and-terminology">Conventions and Terminology</a></h1>
<p id="rfc.section.1.1.p.1">The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 <a href="#RFC2119">[RFC2119]</a>.</p>
<p id="rfc.section.1.1.p.2">The following terms are used:</p>
<p id="rfc.section.1.1.p.3">Consumer/Client: The CCN consumer initiating the CCNxKE key exchange via a first Interest.</p>
<p id="rfc.section.1.1.p.4">Producer/Server: The CCN producer receiving or accepting the CCNxKE key exchange request request Interest.</p>
<p id="rfc.section.1.1.p.5">Sender: An endpoint that originates a message.</p>
<p id="rfc.section.1.1.p.6">Receiver: An endpoint that is receiving messages.</p>
<p id="rfc.section.1.1.p.7">Peer: An endpoint. When discussing a particular endpoint, “peer” refers to the endpoint that is remote to the primary subject of discussion.</p>
<p id="rfc.section.1.1.p.8">Connection: A network path of n >= 1 hops between the consumer and producer.</p>
<p id="rfc.section.1.1.p.9">Endpoint: Either the consumer or producer of the connection.</p>
<p id="rfc.section.1.1.p.10">Handshake: A series of message exchanges between two peers that is used to perform a task (e.g., perform key exchange and derivation).</p>
<p id="rfc.section.1.1.p.11">Session: An association between a consumer and a producer resulting from a CCNxKE handshake.</p>
<p id="rfc.section.1.1.p.12">DH: A Diffie Hellman key exchange procedure <a href="#RFC2631">[RFC2631]</a> <a href="#DH">[DH]</a>.</p>
<p id="rfc.section.1.1.p.13">Key Share: One half of the shared-secret provided by one peer performing a DH key exchange.</p>
<p id="rfc.section.1.1.p.14">Forward-secure: The property that compromising any long-term secrets (e.g., cryptographic keys) does not compromise any session keys derived from those long-term secrets.</p>
<p id="rfc.section.1.1.p.15">CONFIG information: A data structure created by a producer which contains long-term cryptographic material and associated information needed by a client to initiate a key-exchange with the producer.</p>
<p id="rfc.section.1.1.p.16">HELLO exchange: An exchange between a consumer and producer wherein the consumer retrieves the CONFIG information from the producer.</p>
<p id="rfc.section.1.1.p.17">Payload: The payload section of a CCNxMessage as defined in <a href="#CCNxMessages">[CCNxMessages]</a>.</p>
<p id="rfc.section.1.1.p.18">KEPayload: A payload for information used in the CCNxKE protocol which is a generic key-value store. The KEPayload is <em>not</em> the CCNxMessage payload.</p>
<p id="rfc.section.1.1.p.19">CCNxName: A CCNxName as defined in <a href="#CCNxMessages">[CCNxMessages]</a>.</p>
<p id="rfc.section.1.1.p.20">Semi-static: Short-term.</p>
<p id="rfc.section.1.1.p.21">Short-term Secret (SS): A secret which is derived from the server’s semi-static DH share and the client’s fresh DH share.</p>
<p id="rfc.section.1.1.p.22">Forward-secure Secret (FSK): A secret which is derived from fresh (i.e., generated on demand at random) DH shares from both the consumer and producer for the given connection.</p>
<p id="rfc.section.1.1.p.23">HKDF: Hash-based key-derivation function <a href="#RFC5869">[RFC5869]</a>.</p>
<h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a href="#goals" id="goals">Goals</a></h1>
<p id="rfc.section.2.p.1">The goals of the CCNxKE protocol, in order of priority, are as follows:</p>
<p/>
<ol>
<li>Cryptographic security: CCNxKE should be used to securely establish a session and all related shared secrets between two peers. Cryptographic properties of interest include: (a) forward-secure session key derivation and (b) (state and computational) denial-of-service prevention at the producer (see <a href="#RFC4987">[RFC4987]</a>) that is no worse than DTLS 1.2 <a href="#DTLS12">[DTLS12]</a>}. For property (a), different keys (and relevant algorithm parameters such as IVs) are established for each communication direction, i.e., from consumer to producer and producer to consumer. For property (b), we use a new type of stateless cookie inspired by that of DTLS 1.2.</li>
<li>Interoperability: Independent programmers should be able to develop applications utilizing CCNxKE that can successfully exchange cryptographic parameters without knowledge of one another’s code.</li>
<li>Extensibility: CCNxKE seeks to provide a framework into which new public key and symmetric key methods and algorithms can be incorporated without breaking backwards compatibility or requiring all clients to implement new functionality. Moreover, the protocol should be able to support a variety of peer authentication protocols, e.g., EAP-TLS, EAP-PWD, or a simple challenge-response protocol.</li>
<li>Relative efficiency: CCNxKE tries to create sessions with minimal computation, bandwidth, and message complexity. In particular, it seeks to create sessions with as few end-to-end round trips as possible, and also provide support for accelerated session establishment and resumption when appropriate. At most 2 round-trip-times (RTTs) should be used to establish a session key, with the possibility of 1-RTT accelerated starts and resumption.</li>
</ol>
<h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a href="#scope" id="scope">Scope</a></h1>
<p id="rfc.section.3.p.1">This document and the CCNxKE protocol are influenced by the TLS 1.3 <a href="#TLS13">[TLS13]</a>, QUIC <a href="#QUIC">[QUIC]</a>, and DTLS 1.2 <a href="#DTLS12">[DTLS12]</a> protocols. The reader, however, does not need a detailed understanding of those protocols to understand this document. Moreover, where appropriate, references to related protocols are made for brevity and technical clarity. This document is intended primarily for readers who will be implementing the protocol and for those doing cryptographic analysis of it. The specification has been written with this in mind and it is intended to reflect the needs of those two groups.</p>
<p id="rfc.section.3.p.2">Unlike TLS, this document does not specify the transport protocol. It specifies the establishment of a session ID and shared keys. Other documents specify the use of CCKxKE within a transport protocol.</p>
<p id="rfc.section.3.p.3">This document is not intended to supply any details of service definition or of interface definition, although it does cover select areas of policy as they are required for the maintenance of solid security.</p>
<h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a href="#presentation-language" id="presentation-language">Presentation Language</a></h1>
<p id="rfc.section.4.p.1">This document uses a presentation language of remote calls (i.e. packet messages) similar to the format used by TLS <a href="#TLS13">[TLS13]</a>.</p>
<h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a href="#ccnxke-overview" id="ccnxke-overview">CCNxKE Overview</a></h1>
<h1 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1.</a> <a href="#connection-establishment-latency" id="connection-establishment-latency">Connection Establishment Latency</a></h1>
<p id="rfc.section.5.1.p.1">CCNxKE operates in three rounds, where each round requires a single RTT to complete. The full execution of the protocol therefore requires 2 RTTs before a session is fully established. The full version is used when consumers have no a priori information about the producer. An accelerated one round version is used when the consumer has valid configuration information and a source cookie from the producer; this variant requires 1 RTT before a session is established.</p>
<h1 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2.</a> <a href="#connection-migration-and-resumption" id="connection-migration-and-resumption">Connection Migration and Resumption</a></h1>
<p id="rfc.section.5.2.p.1">CCN end hosts lack the notion of addresses. Thus, the producer endpoint for a given execution of the CCNxKE protocol is one which can authoritatively serve as the owner of a particular namespace. For example, a consumer may wish to establish a session with a producer who owns the /company/foo namespace. The specific end host which partakes in the protocol instance is not specified, by virtue of the fact that all CCNxKE messages are based on well-defined names. This enables the producer end-host which partakes in the protocol to change based on the name of the CCNxKE messages. Consequently, to maintain correctness, it is important that a single execution of the protocol operates within the same trusted context; this does not mean that the same producer end-host is required to participate in all three steps of the protocol. Rather, it means that the end-host responding to a CCNxKE message must be trusted by the consumer to complete the exchange. CCNxKE is designed to enable this sort of producer migration.</p>
<p id="rfc.section.5.2.p.2">For example, a consumer may use an initial name like ‘/parc/index.html’ that works like an IP any cast address and could got to one of several systems. CCNxKE allows the responding endpoint to include a localized name to ensure that subsequent messages from the consumer come back to the same producer. CCNxKE also allows the key exchange peer to securely hand-off the session to a content producer peer via another name and session token once the client is authenticated and keying material is exchanged.</p>
<h1 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3.</a> <a href="#re-transmissions-timeouts-and-replay-prevention" id="re-transmissions-timeouts-and-replay-prevention">Re-Transmissions, Timeouts, and Replay Prevention</a></h1>
<p id="rfc.section.5.3.p.1">CCNxKE timeouts and retransmissions are handled using the approach in <a href="#RFC6347">[RFC6347]</a>. One primary difference is that timer values may need to be adjusted (elongated) due to prefix shifts and the need for a producer to transfer security information between different machines.</p>
<p id="rfc.section.5.3.p.2">Replay attack prevention is also an optional feature, and if used, MAY be done using one of the following two approaches at the receiver (producer):</p>
<p/>
<ul>
<li>IPSec AH <a href="#RFC4302">[RFC4302]</a> and ESP <a href="#RFC4303">[RFC4303]</a> style replay detection based on sliding windows and monotonically increasing sequence numbers for windows. Note that the sliding window inherently limits the performance of the protocol to the window size, since only a finite number of messages may be received within a given window (based on the window size).</li>
<li>The optimized anti-replay algorithm of <a href="#RFC6479">[RFC6479]</a>.</li>
</ul>
<h1 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4.</a> <a href="#loss-sensitivity" id="loss-sensitivity">Loss Sensitivity</a></h1>
<p id="rfc.section.5.4.p.1">CCNxKE messages are transferred using standard CCN Interest and Content Objects and are therefore subject to loss as any datagram. This means that traffic encrypted with keys derived from CCNxKE must be stateless. They cannot depend on in-order arrival. This problem is solved by two mechanisms: (1) by prohibiting stream ciphers of any kind and (2) adding sequence numbers to each message that allow the receiver to identify and use the correct cryptographic state to decrypt the message. Moreover, sequence numbers permit anti-replay mechanisms similar to those used in DTLS <a href="#DTLS12">[DTLS12]</a> as mentioned above.</p>
<h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a href="#the-ccnxke-protocol" id="the-ccnxke-protocol">The CCNxKE Protocol</a></h1>
<p id="rfc.section.6.p.1">This section describes the CCNxKE protocol in detail at the message level. The specific encoding of those messages is given later. CCNxKE could be adapted to different wire format encodings, such as those used by the NDN protocol.</p>
<p id="rfc.section.6.p.2">The following assumptions are made about peers participating in the CCNxKE protocol:</p>
<p/>
<ul>
<li>Consumers know the namespace prefix of the producer for which they wish to execute the CCNxKE protocol.</li>
<li>CCNxKE protocol information is carried in a distinguished field outside of the payload of CCN messages. This is done to distinguish key exchange material with application data in a message. This is necessary for 1 RTT packets that carry both keying material and application payload.</li>
<li>CCNxKE does not require any special behavior of intermediate systems to forward packets.</li>
<li>CCNxKE packets generally should not be cached for significant periods of time, as use normal protocol methods to limit caching. Part of this is achieved through the use of consumer-specific nonces in names.</li>
</ul>
<h1 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1.</a> <a href="#round-overview" id="round-overview">Round Overview</a></h1>
<p id="rfc.section.6.1.p.1">CCNxKE is composed of three rounds. The purpose of each round is described below.</p>
<p/>
<ul>
<li>Round 1: Perform a bare HELLO exchange to obtain the extensions (parameters) for the key exchange provided by the producer and a source cookie to prove ownership of the “source” of the request.</li>
<li>Round 2: Perform the initial FULL-HELLO exchange to establish a forward-secure key used for future communication, i.e., Interest and Content Object exchanges in the context of the newly established session.</li>
<li>Round 3: Send the first bit of application data and (optionally) transfer resumption cookie(s) from the producer to the consumer.</li>
</ul>
<p id="rfc.section.6.1.p.3">Conceptually, there are two secrets established during a single execution of CCNxKE:</p>
<p/>
<ul>
<li>Static Secret (SS): A secret which is derived in one of two ways: (a) from the client and server ephemeral key shares and (b) from the server’s semi-static share and the client’s ephemeral key share. Keying material derived from SS in option (a) is not forward secure.</li>
<li>Ephemeral Secret (ES): A secret which is derived from both the client and server ephemeral key shares.</li>
</ul>
<p id="rfc.section.6.1.p.5">Depending on the mode in which CCNxKE is used, these secrets can be established in a variety of ways. Key derivation details are outlined in Section <a href="#derive">Section 9</a>.</p>
<p id="rfc.section.6.1.p.6">All secrets are derived with the appropriate amount of randomness <a href="#RFC4086">[RFC4086]</a>. An overview of the messages sent in each of the three rounds to establish and use these secrets is shown in Figure <a href="#ccnxke-high">Figure 1</a> below. This diagram omits some parts of each message for brevity.</p>
<div id="rfc.figure.1"/>
<div id="ccnxke-high"/>
<pre>
Consumer Producer
HELLO:
+ SourceChallenge
I[/prefix/random-1]
-------->
HELLO-REJECT:
+ Timestamp
+ SourceCookie
+ pinned-prefix*
+ ServerChallenge*
+ ServerConfiguration*
CO[/prefix/random-1]
<---------
FULL-HELLO:
+ ClientKeyShare
+ SourceCookie
+ SourceProof
+ Timestamp
I[/pinned-prefix/random-2]
-------->
HELLO-ACCEPT:
+ ServerKeyShare
+ SessionID
+ [CertificateRequest*]
+ [CertificateVerify*]
+ [MovePrefix*, MoveToken)*]
+ [Finished]
CO[/pinned-prefix/random-2]
<--------
**key exchange complete**
Payload:
+ MoveToken*
+ MoveProof*
+ [ConsumerData]
I[/prefix/SessionID/[...]]
-------->
+ NewSessionID*
+ NewSessionIDTag*
Payload:
[ProducerData]
CO[/prefix/SessionID/[...]]
<--------
Repeat with data <--------> Repeat with data
* Indicates optional or situation-dependent
messages that are not always sent.
{} Indicates messages protected using keys
derived from the short-term secret (SS).
() Indicates messages protected using keys
derived from the ephemeral secret (ES).
[] Indicates messages protected using keys
derived from the traffic secret (TS).
</pre>
<p class="figure">Figure 1: High-level message flow for full CCNxKE protocol with a maximum 2-RTT delay.</p>
<p id="rfc.section.6.1.p.7">In the following sections, we will describe the format of each round in this protocol in more detail.</p>
<p id="rfc.section.6.1.p.8">We do not specify the encoding of CCNxKE data sent in Interest and Content Object payloads. Any viable encoding will suffice, so long as both parties agree upon the type. For example, the payload could be structured and encoded as a JSON object, e.g.,</p>
<p id="rfc.section.6.1.p.9">{ “ClientKeyShare” : 0xaa, “SourceCookie” : 0xbb, “SourceProof” : 0xbb, … }</p>
<p id="rfc.section.6.1.p.10">For now, we assume some valid encoding mechanism is used to give structure to message payloads. Moreover, we assume that these payloads are carried in a distinguished CCNxKE payload field contained in the Interest and Content Objects.</p>
<h1 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2.</a> <a href="#round-1" id="round-1">Round 1</a></h1>
<p id="rfc.section.6.2.p.1">The purpose of Round 1 is to acquire a cookie to binding the exchange to the initial consumer and the public configuration information contained in the ServerConfiguration structure. This information is used in the second round when performing the actual key exchange. To that end, the format of the Round 1 message is trivial. First, the client issues an Interest with the following name</p>
<pre>
/prefix/random-1
</pre>
<p id="rfc.section.6.2.p.2">where random-1 is a randomly generated 64-bit nonce. This interest carries a KEPayload with the following information:</p>
<table cellpadding="3" cellspacing="0" class="tt full center">
<thead>
<tr>
<th class="left">HELLO Field</th>
<th class="left">Description</th>
<th class="left">Optional?</th>
</tr>
</thead>
<tbody>
<tr>
<td class="left">SourceChallenge</td>
<td class="left">A random value generated to prove ownership of the consumer’s “source”</td>
<td class="left">No</td>
</tr>
</tbody>
</table>
<p id="rfc.section.6.2.p.3">Upon receipt of this interest, the producer responds with a HELLO-REJECT Content Object whose KEPayload has the following fields:</p>
<table cellpadding="3" cellspacing="0" class="tt full center">
<thead>
<tr>
<th class="left">HELLO-REJECT Field</th>
<th class="left">Description</th>
<th class="left">Optional?</th>
</tr>
</thead>
<tbody>
<tr>
<td class="left">Timestamp</td>
<td class="left">Current server timestamp</td>
<td class="left">No</td>
</tr>
<tr>
<td class="left">SourceCookie</td>
<td class="left">A cookie that binds the consumer’s challenge to the current timestamp</td>
<td class="left">No</td>
</tr>
<tr>
<td class="left">PinnedPrefix</td>
<td class="left">A new prefix that pins the key exchange to a particular server</td>
<td class="left">Yes</td>
</tr>
<tr>
<td class="left">ServerConfiguration</td>
<td class="left">The public server configuration information</td>
<td class="left">Yes</td>
</tr>
<tr>
<td class="left">ServerChallenge</td>
<td class="left">A random value for the consumer to include in its CertificateVerify if the server requires client authentication</td>
<td class="left">Yes</td>
</tr>
</tbody>
</table>
<p id="rfc.section.6.2.p.4">The Timestamp and SourceCookie are used in Round 2. Their derivation is described later. If the server provides a PinnedPrefix then the consumer must use this prefix in Round 2 in lieu of the Round 1 name prefix. (This is because the PinnedPrefix identifies a particular endpoint that is capable of completing the key exchange.)</p>
<p id="rfc.section.6.2.p.5">The ServerConfiguration information is a semi-static catalog of information that consumers may use to complete future key exchanges with the producer. The fields of the ServerConfiguration information are shown below.</p>
<table cellpadding="3" cellspacing="0" class="tt full center">
<thead>
<tr>
<th class="left">ServerConfiguration Field</th>
<th class="left">Description</th>
<th class="left">Optional?</th>
</tr>
</thead>
<tbody>
<tr>
<td class="left">KEXS</td>
<td class="left">Supported elliptic-curve key-exchange algorithms</td>
<td class="left">No</td>
</tr>
<tr>
<td class="left">AEAD</td>
<td class="left">Supported AEAD algorithms</td>
<td class="left">No</td>
</tr>
<tr>
<td class="left">PUBS</td>
<td class="left">List of public values (for key exchange algorithm) encoded appropriately for the given group</td>
<td class="left">No</td>
</tr>
<tr>
<td class="left">EXPRY</td>
<td class="left">Expiration timestamp (i.e., longevity of the ServerConfiguration structure)</td>
<td class="left">No</td>
</tr>
<tr>
<td class="left">VER</td>
<td class="left">Version of the CONFIG structure</td>
<td class="left">Yes</td>
</tr>
<tr>
<td class="left">CERT</td>
<td class="left">Server certificate</td>
<td class="left">No</td>
</tr>
<tr>
<td class="left">SIG</td>
<td class="left">Signature produced by the server over the entire ServerConfiguration message</td>
<td class="left">No</td>
</tr>
</tbody>
</table>
<p id="rfc.section.6.2.p.6">The KEXS is a data structure that enumerates the elliptic curve key-exchange algorithms that are supported by the producer (see <a href="#QUIC">[QUIC]</a> for more details). Currently, only the following curves are supported:</p>
<p/>
<ul>
<li>Curve25519</li>
<li>P-256</li>
</ul>
<p id="rfc.section.6.2.p.8">Selection criteria for these curves is given at http://safecurves.cr.yp.to/.</p>
<p id="rfc.section.6.2.p.9">The AEAD structure enumerates the supported AEAD algorithms used for symmetric-key authenticated encryption after the session has been established. Currently, the only supported algorithms are:</p>
<p/>
<ul>
<li>AES-GCM-(128,192,256) <a href="#GCM">[GCM]</a>: a 12-byte tag is used, where the first four bytes are taken from the FSK key-derivation step and the last eight are taken from the initial consumer nonce.</li>
<li>Salsa20 <a href="#SALSA20">[SALSA20]</a> (stream cipher) with Poly1305 (MAC).</li>
</ul>
<p id="rfc.section.6.2.p.11">The key sizes and related parameters are provided with the AEAD tag in the CONFIG structure.</p>
<p id="rfc.section.6.2.p.12">The PUBS structure contains the public values for the initial key exchange. Both Curve25519 and P-256 provide their own set of accepted parameters. Thus, the only values provided here are the random curve elements used in the DH operation.</p>
<p id="rfc.section.6.2.p.13">The EXPRY value is an absolute timestamp that indicates the longevity of the ServerConfiguration.</p>
<p id="rfc.section.6.2.p.14">The CERT and SIG values contain the server’s certificate and a signature generated over the entire ServerConfiguration field. This signature is generated with the corresponding private key.</p>
<h1 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3.</a> <a href="#round-2" id="round-2">Round 2</a></h1>
<p id="rfc.section.6.3.p.1">The purpose of Round 2 is to perform the initial FULL-HELLO exchange to establish a forward-secure key used for future communication. It is assumed that the consumer already has the ServerConfiguration information that is provided from the producer in Round 1. It is also assumed that the consumer has a</p>
<p id="rfc.section.6.3.p.2">Moreover, assume that nonce2 is a ephemeral nonce provided by the producer in Round 1. Then, the consumer issues an Interest with the following name:</p>
<pre>
/prefix/random-2
</pre>
<p id="rfc.section.6.3.p.3">and a KEPayload with the following information:</p>
<table cellpadding="3" cellspacing="0" class="tt full center">
<thead>
<tr>
<th class="left">FULL-HELLO Field</th>
<th class="left">Description</th>
<th class="left">Optional?</th>
</tr>
</thead>
<tbody>
<tr>
<td class="left">ClientKeyShare</td>
<td class="left">The client’s key share for the key exchange</td>
<td class="left">No</td>
</tr>
<tr>
<td class="left">SourceCookie</td>
<td class="left">SourceCookie provided by the server in Round 1</td>
<td class="left">No</td>
</tr>
<tr>
<td class="left">SourceProof</td>
<td class="left">The SourceCookie construction proof provided by the client</td>
<td class="left">No</td>
</tr>
<tr>
<td class="left">Timestamp</td>
<td class="left">The timestamp provided by the server in Round 1</td>
<td class="left">No</td>
</tr>
<tr>
<td class="left">ConsumerPrefix</td>
<td class="left">The consumer’s prefix that can be used for the producer to send interests to the consumer</td>
<td class="left">Yes</td>
</tr>
<tr>
<td class="left">PreSharedKey</td>
<td class="left">A pre-shared key that can be configured between a consumer and producer</td>
<td class="left">Yes</td>
</tr>
<tr>
<td class="left">ResumptionCookie</td>
<td class="left">The ResumptionCookie derived from a past session</td>
<td class="left">Yes</td>
</tr>
<tr>
<td class="left">{MoveChallenge}</td>
<td class="left">A move challenge generated identically to the SourceChallenge</td>
<td class="left">Yes</td>
</tr>
<tr>
<td class="left">{AlgChoice}</td>
<td class="left">Algorithm (KEXS and AEAD) options choice (a list of tags echoed from the ServerConfiguration)</td>
<td class="left">No</td>
</tr>
<tr>
<td class="left">{Proof}</td>
<td class="left">Proof of demand (i.e., a sorted list of types of proof the consumer will expect)</td>
<td class="left">No</td>
</tr>
<tr>
<td class="left">{CCS}</td>
<td class="left">Compressed certificate set that the consumer possesses</td>
<td class="left">No</td>
</tr>
<tr>
<td class="left">{ConsumerData}</td>
<td class="left">Application data encrypted under a key derived from SS (in a 1-RTT exchange)</td>
<td class="left">Yes</td>
</tr>
<tr>
<td class="left">ServerNameIndication</td>
<td class="left">A server name indication (as a CCNxName) defined in Section 3 of <a href="#RFC6066">[RFC6066]</a></td>
<td class="left">Yes</td>
</tr>
<tr>
<td class="left">Certificate</td>
<td class="left">The client’s certificate</td>
<td class="left">Yes</td>
</tr>
<tr>
<td class="left">CertificateVerify</td>
<td class="left">A signature generated over the entire FULL-HELLO message</td>
<td class="left">Yes</td>
</tr>
</tbody>
</table>
<p id="rfc.section.6.3.p.4">((TODO: provide more details about each of these fields))</p>
<p id="rfc.section.6.3.p.5">Upon receipt of this interest, the producer performs the DH computation to compute ES and SS, decrypts all protected fields in the consumer’s KEPayload, and validates the algorithm choice selection (AlgChoice). If any of these steps fail, the producer replies with with a HELLO-REJECT Content Object whose KEPayload contains a REJ flag and the reason of the error. The REJ flag and value are encrypted by the SS (if possible).</p>
<p id="rfc.section.6.3.p.6">If the above steps complete without failure or error, then the producer responds with a Content Object whose KEPayload has the following fields:</p>
<table cellpadding="3" cellspacing="0" class="tt full center">
<thead>
<tr>
<th class="left">HELLO-ACCEPT Field</th>
<th class="left">Description</th>
<th class="left">Optional?</th>
</tr>
</thead>
<tbody>
<tr>
<td class="left">SessionID</td>
<td class="left">Cleartext session identifier</td>
<td class="left">No</td>
</tr>
<tr>
<td class="left">ServerKeyShare</td>
<td class="left">Server’s key share for the ES derivation</td>
<td class="left">No</td>
</tr>
<tr>
<td class="left">{ServerExtensions}</td>
<td class="left">Additional extensions provided by the server, encrypted under ES</td>
<td class="left">Yes</td>
</tr>
<tr>
<td class="left">[ResumptionCookie]</td>
<td class="left">Resumption cookie encrypted under a TS-derived key</td>
<td class="left">Yes</td>
</tr>
<tr>
<td class="left">{(MovePrefix,MoveToken)}</td>
<td class="left">Third CCNxName prefix and token to use when moving to session establishment</td>
<td class="left">Yes</td>
</tr>
<tr>
<td class="left">CertificateRequest*</td>
<td class="left">Server certificate that matches the type of proof provided by the client</td>
<td class="left">Yes</td>
</tr>
<tr>
<td class="left">CertificateVerify*</td>
<td class="left">Signature generated over the entire HELLO-ACCEPT message</td>
<td class="left">Yes</td>
</tr>
</tbody>
</table>
<p id="rfc.section.6.3.p.7">If a MovePrefix and MoveToken tuple is provided then in the HELLO-ACCEPT message then a CertificateVerify (signature) MUST also be provided in the response.</p>
<h1 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4.</a> <a href="#round-3" id="round-3">Round 3</a></h1>
<p id="rfc.section.6.4.p.1">In Round 3, the consumer sends interests whose name and optional Payload are encrypted using one of the forward-secure keys derived after Round 2. In normal operation, the producer will respond with Content Objects whose Payloads are encrypted using a different forward-secure key. That is, interests and Content Objects are encrypted and authenticated using two separate keys. The producer may also optionally provide a new resumption cookie (RC) with a Content Object response. This is used to keep the consumer’s resumption cookie fresh and to also support 0 RTT resumption. In this case, the producer’s Content Object response has the following fields:</p>
<p/>
<ul>
<li>Payload: the actual Content Object payload data encrypted with the producer’s forward-secure key.</li>
<li>ResumptionCookie: A new resumption cookie to be used for resuming this session in the future.</li>
</ul>
<p id="rfc.section.6.4.p.3">The producer is free to choose the frequency at which new resumption cookies are issued to the consumer.</p>
<p id="rfc.section.6.4.p.4">The producer may also reply with a new SessionID. This is done if the client presented a MoveToken and MoveProof. A NewSessionID must be accompanied with a NewSessionIDTag, which is equal to the HMAC of NewSessionID computed with the traffic-secret key. A client MUST then use NewSessionID instead of SessionID after verifying the NewSessionIDTag.</p>
<h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a href="#alternative-exchanges" id="alternative-exchanges">Alternative Exchanges</a></h1>
<p id="rfc.section.7.p.1">CCNxKE also supports one-round key exchange and session resumption. These variants are outlined below. The key material differences are described later. In these variants, we use message ExchangeSourceCookie to denote the following exchange:</p>
<div id="rfc.figure.2"/>
<div id="cookieexchange"/>
<pre>
Consumer Producer
HELLO:
+ SourceChallenge
I[/prefix/random-1]
-------->
HELLO-REJECT:
+ Timestamp
+ SourceCookie
ServerChallenge*
ServerConfiguration*
CO[/prefix/random-1]
<---------
</pre>
<p class="figure">Figure 2: SourceCookie exchange -- ExchangeSourceCookie.</p>
<h1 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1.</a> <a href="#one-rtt-exchange" id="one-rtt-exchange">One-RTT Exchange</a></h1>
<div id="rfc.figure.3"/>
<div id="onertt-exchange"/>
<pre>
Consumer Producer
-------->
ExchangeSourceCookie
<---------
FULL-HELLO:
+ ClientKeyShare
+ SourceCookie
+ SourceProof
+ Timestamp
+ Certificate*
+ CertificateVerify*