-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-pala-tian-eap-creds-01.html
2248 lines (2017 loc) · 120 KB
/
draft-pala-tian-eap-creds-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>Credentials Provisioning and Management via EAP (EAP-CREDS)</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 Requirements notation">
<link href="#rfc.section.2" rel="Chapter" title="2 Introduction">
<link href="#rfc.section.2.1" rel="Chapter" title="2.1 Overview of existing solutions">
<link href="#rfc.section.2.2" rel="Chapter" title="2.2 Scope Statement">
<link href="#rfc.section.2.3" rel="Chapter" title="2.3 EAP-CREDS as tunneled mechanism only">
<link href="#rfc.section.2.4" rel="Chapter" title="2.4 Fragmentation Support">
<link href="#rfc.section.2.5" rel="Chapter" title="2.5 Encapsulating Provisioning Protocols in EAP-CREDS">
<link href="#rfc.section.2.6" rel="Chapter" title="2.6 Algorithm Requirements">
<link href="#rfc.section.2.7" rel="Chapter" title="2.7 Notation">
<link href="#rfc.section.3" rel="Chapter" title="3 EAP-CREDS Protocol">
<link href="#rfc.section.3.1" rel="Chapter" title="3.1 Message Flow">
<link href="#rfc.section.3.2" rel="Chapter" title="3.2 Phase Transitioning Rules">
<link href="#rfc.section.3.3" rel="Chapter" title="3.3 Phase One: Initialization">
<link href="#rfc.section.3.4" rel="Chapter" title="3.4 Phase Two: Provisioning">
<link href="#rfc.section.3.5" rel="Chapter" title="3.5 Phase Three: Validation">
<link href="#rfc.section.4" rel="Chapter" title="4 EAP-CREDS Message Format">
<link href="#rfc.section.4.1" rel="Chapter" title="4.1 Message Header">
<link href="#rfc.section.4.2" rel="Chapter" title="4.2 Message Payload">
<link href="#rfc.section.4.3" rel="Chapter" title="4.3 EAP-CREDS defined TLVs">
<link href="#rfc.section.4.3.1" rel="Chapter" title="4.3.1 The Action TLV">
<link href="#rfc.section.4.3.2" rel="Chapter" title="4.3.2 The Challenge-Data TLV">
<link href="#rfc.section.4.3.3" rel="Chapter" title="4.3.3 The Challenge-Response TLV">
<link href="#rfc.section.4.3.4" rel="Chapter" title="4.3.4 The Creds-Info TLV">
<link href="#rfc.section.4.3.5" rel="Chapter" title="4.3.5 The Error TLV">
<link href="#rfc.section.4.3.6" rel="Chapter" title="4.3.6 The Net-Usage TLV">
<link href="#rfc.section.4.3.7" rel="Chapter" title="4.3.7 The Profile TLV">
<link href="#rfc.section.4.3.8" rel="Chapter" title="4.3.8 The Protocol TLV">
<link href="#rfc.section.4.3.9" rel="Chapter" title="4.3.9 The ProtoData TLV">
<link href="#rfc.section.4.3.10" rel="Chapter" title="4.3.10 The ProtoHeaders TLV">
<link href="#rfc.section.4.3.11" rel="Chapter" title="4.3.11 The Params TLV">
<link href="#rfc.section.4.3.12" rel="Chapter" title="4.3.12 The Token TLV">
<link href="#rfc.section.4.3.13" rel="Chapter" title="4.3.13 The Version TLV">
<link href="#rfc.section.5" rel="Chapter" title="5 EAP-CREDS Messages">
<link href="#rfc.section.5.1" rel="Chapter" title="5.1 The EAP-CREDS-Init Message">
<link href="#rfc.section.5.1.1" rel="Chapter" title="5.1.1 EAP Server's Init Message">
<link href="#rfc.section.5.1.2" rel="Chapter" title="5.1.2 EAP Peer's Init Message">
<link href="#rfc.section.5.1.2.1" rel="Chapter" title="5.1.2.1 Bootstrapping Peer's Trustworthiness">
<link href="#rfc.section.5.1.3" rel="Chapter" title="5.1.3 The EAP-CREDS-Provisioning Message">
<link href="#rfc.section.5.1.4" rel="Chapter" title="5.1.4 The EAP-CREDS-Validate Message">
<link href="#rfc.section.6" rel="Chapter" title="6 Error Handling in EAP-CREDS">
<link href="#rfc.section.7" rel="Chapter" title="7 IANA Considerations">
<link href="#rfc.section.7.1" rel="Chapter" title="7.1 Provisioning Protocols">
<link href="#rfc.section.7.2" rel="Chapter" title="7.2 Token Types">
<link href="#rfc.section.7.3" rel="Chapter" title="7.3 Credentials Types">
<link href="#rfc.section.7.4" rel="Chapter" title="7.4 Credentials Algorithms">
<link href="#rfc.section.7.5" rel="Chapter" title="7.5 Challenge Types">
<link href="#rfc.section.7.6" rel="Chapter" title="7.6 Network Usage Datatypes">
<link href="#rfc.section.7.7" rel="Chapter" title="7.7 Credentials Encoding">
<link href="#rfc.section.7.8" rel="Chapter" title="7.8 Action Types">
<link href="#rfc.section.7.9" rel="Chapter" title="7.9 Usage Metadata Types">
<link href="#rfc.section.8" rel="Chapter" title="8 Security Considerations">
<link href="#rfc.section.9" rel="Chapter" title="9 Acknowledgments">
<link href="#rfc.references" rel="Chapter" title="10 Normative References">
<link href="#rfc.authors" rel="Chapter">
<meta name="generator" content="xml2rfc version 2.40.0 - https://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
<meta name="dct.creator" content="Pala, M. and Y. Tian" />
<meta name="dct.identifier" content="urn:ietf:id:draft-pala-tian-eap-creds-01" />
<meta name="dct.issued" scheme="ISO8601" content="2022-06-30" />
<meta name="dct.abstract" content="With the increase number of devices, protocols, and applications that rely on strong credentials (e.g., digital certificates, keys, or tokens) for network access, the need for a standardized credentials provisioning and management framework is paramount. The 802.1x architecture allows for entities (e.g., devices, applications, etc.) to authenticate to the network by providing a communication channel where different methods can be used to exchange different types of credentials. However, the need for managing these credentials (i.e., provisioning and renewal) is still a hard problem to solve. Usually, credentails used in an access network can be in different levels (e.g., network-level, user-level) and sometimes tend to live unmanaged for quite a long time due to the challenges of operation and implementation. EAP-CREDS (RFC XXXX), if implemented in Managed Networks (e.g., Cable Modems), could enable our operators to offer a registration and credentials management service integrated in the home WiFi thus enabling visibility about registered devices. During initialization, EAP-CREDS also allows for MUD files or URLs to be transferred between the EAP Peer and the EAP Server, thus giving detailed visibility about devices when they are provisioned with credentials for accessing the networks. The possibility provided by EAP-CREDS can help to secure home or business networks by leveraging the synergies of the security teams from the network operators thanks to the extended knowledge of what and how is registered/authenticated. This specifications define how to support the provisioning and management of authentication credentials that can be exploited in different environments (e.g., Wired, WiFi, cellular, etc.) to users and/or devices by using EAP together with standard provisioning protocols. " />
<meta name="description" content="With the increase number of devices, protocols, and applications that rely on strong credentials (e.g., digital certificates, keys, or tokens) for network access, the need for a standardized credentials provisioning and management framework is paramount. The 802.1x architecture allows for entities (e.g., devices, applications, etc.) to authenticate to the network by providing a communication channel where different methods can be used to exchange different types of credentials. However, the need for managing these credentials (i.e., provisioning and renewal) is still a hard problem to solve. Usually, credentails used in an access network can be in different levels (e.g., network-level, user-level) and sometimes tend to live unmanaged for quite a long time due to the challenges of operation and implementation. EAP-CREDS (RFC XXXX), if implemented in Managed Networks (e.g., Cable Modems), could enable our operators to offer a registration and credentials management service integrated in the home WiFi thus enabling visibility about registered devices. During initialization, EAP-CREDS also allows for MUD files or URLs to be transferred between the EAP Peer and the EAP Server, thus giving detailed visibility about devices when they are provisioned with credentials for accessing the networks. The possibility provided by EAP-CREDS can help to secure home or business networks by leveraging the synergies of the security teams from the network operators thanks to the extended knowledge of what and how is registered/authenticated. This specifications define how to support the provisioning and management of authentication credentials that can be exploited in different environments (e.g., Wired, WiFi, cellular, etc.) to users and/or devices by using EAP together with standard provisioning protocols. " />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left">Network Working Group</td>
<td class="right">M. Pala</td>
</tr>
<tr>
<td class="left">Internet-Draft</td>
<td class="right">Y. Tian</td>
</tr>
<tr>
<td class="left">Intended status: Standards Track</td>
<td class="right">CableLabs</td>
</tr>
<tr>
<td class="left">Expires: January 1, 2023</td>
<td class="right">June 30, 2022</td>
</tr>
</tbody>
</table>
<p class="title">Credentials Provisioning and Management via EAP (EAP-CREDS)<br />
<span class="filename">draft-pala-tian-eap-creds-01</span></p>
<h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
<p>With the increase number of devices, protocols, and applications that rely on strong credentials (e.g., digital certificates, keys, or tokens) for network access, the need for a standardized credentials provisioning and management framework is paramount. The 802.1x architecture allows for entities (e.g., devices, applications, etc.) to authenticate to the network by providing a communication channel where different methods can be used to exchange different types of credentials. However, the need for managing these credentials (i.e., provisioning and renewal) is still a hard problem to solve. Usually, credentails used in an access network can be in different levels (e.g., network-level, user-level) and sometimes tend to live unmanaged for quite a long time due to the challenges of operation and implementation. EAP-CREDS (RFC XXXX), if implemented in Managed Networks (e.g., Cable Modems), could enable our operators to offer a registration and credentials management service integrated in the home WiFi thus enabling visibility about registered devices. During initialization, EAP-CREDS also allows for MUD files or URLs to be transferred between the EAP Peer and the EAP Server, thus giving detailed visibility about devices when they are provisioned with credentials for accessing the networks. The possibility provided by EAP-CREDS can help to secure home or business networks by leveraging the synergies of the security teams from the network operators thanks to the extended knowledge of what and how is registered/authenticated. This specifications define how to support the provisioning and management of authentication credentials that can be exploited in different environments (e.g., Wired, WiFi, cellular, etc.) to users and/or devices by using EAP together with standard provisioning protocols. </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 https://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 January 1, 2023.</p>
<h1 id="rfc.copyrightnotice"><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
<p>Copyright (c) 2022 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 (https://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">Requirements notation</a>
</li>
<li>2. <a href="#rfc.section.2">Introduction</a>
</li>
<ul><li>2.1. <a href="#rfc.section.2.1">Overview of existing solutions</a>
</li>
<li>2.2. <a href="#rfc.section.2.2">Scope Statement</a>
</li>
<li>2.3. <a href="#rfc.section.2.3">EAP-CREDS as tunneled mechanism only</a>
</li>
<li>2.4. <a href="#rfc.section.2.4">Fragmentation Support</a>
</li>
<li>2.5. <a href="#rfc.section.2.5">Encapsulating Provisioning Protocols in EAP-CREDS</a>
</li>
<li>2.6. <a href="#rfc.section.2.6">Algorithm Requirements</a>
</li>
<li>2.7. <a href="#rfc.section.2.7">Notation</a>
</li>
</ul><li>3. <a href="#rfc.section.3">EAP-CREDS Protocol</a>
</li>
<ul><li>3.1. <a href="#rfc.section.3.1">Message Flow</a>
</li>
<li>3.2. <a href="#rfc.section.3.2">Phase Transitioning Rules</a>
</li>
<li>3.3. <a href="#rfc.section.3.3">Phase One: Initialization</a>
</li>
<li>3.4. <a href="#rfc.section.3.4">Phase Two: Provisioning</a>
</li>
<li>3.5. <a href="#rfc.section.3.5">Phase Three: Validation</a>
</li>
</ul><li>4. <a href="#rfc.section.4">EAP-CREDS Message Format</a>
</li>
<ul><li>4.1. <a href="#rfc.section.4.1">Message Header</a>
</li>
<li>4.2. <a href="#rfc.section.4.2">Message Payload</a>
</li>
<li>4.3. <a href="#rfc.section.4.3">EAP-CREDS defined TLVs</a>
</li>
<ul><li>4.3.1. <a href="#rfc.section.4.3.1">The Action TLV</a>
</li>
<li>4.3.2. <a href="#rfc.section.4.3.2">The Challenge-Data TLV</a>
</li>
<li>4.3.3. <a href="#rfc.section.4.3.3">The Challenge-Response TLV</a>
</li>
<li>4.3.4. <a href="#rfc.section.4.3.4">The Creds-Info TLV</a>
</li>
<li>4.3.5. <a href="#rfc.section.4.3.5">The Error TLV</a>
</li>
<li>4.3.6. <a href="#rfc.section.4.3.6">The Net-Usage TLV</a>
</li>
<li>4.3.7. <a href="#rfc.section.4.3.7">The Profile TLV</a>
</li>
<li>4.3.8. <a href="#rfc.section.4.3.8">The Protocol TLV</a>
</li>
<li>4.3.9. <a href="#rfc.section.4.3.9">The ProtoData TLV</a>
</li>
<li>4.3.10. <a href="#rfc.section.4.3.10">The ProtoHeaders TLV</a>
</li>
<li>4.3.11. <a href="#rfc.section.4.3.11">The Params TLV</a>
</li>
<li>4.3.12. <a href="#rfc.section.4.3.12">The Token TLV</a>
</li>
<li>4.3.13. <a href="#rfc.section.4.3.13">The Version TLV</a>
</li>
</ul></ul><li>5. <a href="#rfc.section.5">EAP-CREDS Messages</a>
</li>
<ul><li>5.1. <a href="#rfc.section.5.1">The EAP-CREDS-Init Message</a>
</li>
<ul><li>5.1.1. <a href="#rfc.section.5.1.1">EAP Server's Init Message</a>
</li>
<li>5.1.2. <a href="#rfc.section.5.1.2">EAP Peer's Init Message</a>
</li>
<ul><li>5.1.2.1. <a href="#rfc.section.5.1.2.1">Bootstrapping Peer's Trustworthiness</a>
</li>
</ul><li>5.1.3. <a href="#rfc.section.5.1.3">The EAP-CREDS-Provisioning Message</a>
</li>
<li>5.1.4. <a href="#rfc.section.5.1.4">The EAP-CREDS-Validate Message</a>
</li>
</ul></ul><li>6. <a href="#rfc.section.6">Error Handling in EAP-CREDS</a>
</li>
<li>7. <a href="#rfc.section.7">IANA Considerations</a>
</li>
<ul><li>7.1. <a href="#rfc.section.7.1">Provisioning Protocols</a>
</li>
<li>7.2. <a href="#rfc.section.7.2">Token Types</a>
</li>
<li>7.3. <a href="#rfc.section.7.3">Credentials Types</a>
</li>
<li>7.4. <a href="#rfc.section.7.4">Credentials Algorithms</a>
</li>
<li>7.5. <a href="#rfc.section.7.5">Challenge Types</a>
</li>
<li>7.6. <a href="#rfc.section.7.6">Network Usage Datatypes</a>
</li>
<li>7.7. <a href="#rfc.section.7.7">Credentials Encoding</a>
</li>
<li>7.8. <a href="#rfc.section.7.8">Action Types</a>
</li>
<li>7.9. <a href="#rfc.section.7.9">Usage Metadata Types</a>
</li>
</ul><li>8. <a href="#rfc.section.8">Security Considerations</a>
</li>
<li>9. <a href="#rfc.section.9">Acknowledgments</a>
</li>
<li>10. <a href="#rfc.references">Normative References</a>
</li>
<li><a href="#rfc.authors">Authors' Addresses</a>
</li>
</ul>
<h1 id="rfc.section.1">
<a href="#rfc.section.1">1.</a> Requirements notation</h1>
<p id="rfc.section.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <a href="#RFC2119" class="xref">[RFC2119]</a>. </p>
<h1 id="rfc.section.2">
<a href="#rfc.section.2">2.</a> <a href="#intro" id="intro">Introduction</a>
</h1>
<p id="rfc.section.2.p.1">Many environments are, today, moving towards requiring strong authentication when it comes to gain access to networks. The 802.1x architecture provides network administrators with the possibility to check credentials presented by a device even before providing any connectivity or IP services to it. However, the provisioning and management of these credentials is a hard problem to solve and many vendors opt for long-lived credentials that can not be easily revoked, replaced, or simply renewed. This specification addresses the problem of providing a simple-to-use and simple-to-deploy conduit for credentials management by extending the EAP protocol to support credentials provisioning and management functionality. In particular, the EAP-CREDS method defined here provides a generic framework that can carry the messages for provisioning different types of credentials. EAP-CREDS cannot be used as a stand-alone method, it is required that EAP-CREDS is used as an inner method of EAP-TLS, EAP-TEAP, or any other tunneling method that can provide the required secrecy and (at minimum) server-side authentication to make sure that the communication is protected and with the right server. </p>
<h1 id="rfc.section.2.1">
<a href="#rfc.section.2.1">2.1.</a> <a href="#existing_solutions" id="existing_solutions">Overview of existing solutions</a>
</h1>
<p id="rfc.section.2.1.p.1">Currently there are many protocols that address credentials lifecycle management. In particular, when it comes to digital certificates, some of the most deployed management protocols are: Certificate Management Protocol (CMP) <a href="#RFC4210" class="xref">[RFC4210]</a>, Certificate Management over CMS (CMC) <a href="#RFC5272" class="xref">[RFC5272]</a><a href="#RFC6402" class="xref">[RFC6402]</a>, Enrollment over Secure Transport (EST) <a href="#RFC7030" class="xref">[RFC7030]</a>, and Automated Certificate Management Environment (ACME) <a href="#RFC8555" class="xref">[RFC8555]</a>. However, none of these protocols provide native support for client that do not have IP connectivity yet (e.g., because they do not have network-access credentials, yet). EAP-CREDS provides the possibility to use such protocols (i.e., message-based) by defining a series of messages that can be used to encapsulate the provisioning messages for the selected provisioning protocol. </p>
<h1 id="rfc.section.2.2">
<a href="#rfc.section.2.2">2.2.</a> <a href="#scope" id="scope">Scope Statement</a>
</h1>
<p id="rfc.section.2.2.p.1">This document focuses on the definition of the EAP-CREDS method to convey credentials provisioning and managing messages between the client and the AAA server. Moreover, the document defines how to encode messages for the main IETF provisioning protocols. This document, however, does not provide specifications for how and where the credentials are generated. In particular, the credentials could be generated directly within the AAA server or at a different location (i.e., the Certificate Service Provider or CSP) site. Different authentication mechanisms (e.g., TLS, etc.) can be used to secure the communication between the server's endpoint and the CSP. Examples and details of how to use EAP-CREDS encapsulation mechanism with specific protocol are out of scope of this document. For more details of using EAP-CREDS method with Simple Provisioning Protocol (SPP), please refer to EAP-CREDS with Simple Provisioning Protocol (SPP) . For more details of using EAP-CREDS method with Certificate Management Protocol (CMP), please refer to EAP-CREDS withwith Certificate Management Protocol (CMP) . These two documents can be used as the template for other protocols' encapulation with EAP-CREDS. </p>
<h1 id="rfc.section.2.3">
<a href="#rfc.section.2.3">2.3.</a> <a href="#tunnel" id="tunnel">EAP-CREDS as tunneled mechanism only</a>
</h1>
<p id="rfc.section.2.3.p.1">EAP-CREDS requires that an outer mechanism is in place between the Peer and the Server in order to provide authentication and confidentiality of the messages exchanged via EAP-CREDS. In other words, EAP-CREDS assumes that an appropriately encrypted and authenticated channel has been established to prevent the possibility to leak information or to allow man-in-the-middle attacks. </p>
<p id="rfc.section.2.3.p.2">This choice was taken to simplify the message flow between Peer and Server, and to abstract EAP-CREDS from the secure-channel establishment mechanism. EAP-TLS, or EAP-TEAP are examples of such mechanisms. </p>
<h1 id="rfc.section.2.4">
<a href="#rfc.section.2.4">2.4.</a> <a href="#frag" id="frag">Fragmentation Support</a>
</h1>
<p id="rfc.section.2.4.p.1">EAP does not directly support handling fragmented packets and it requires the outer method to provide fragmentation support. </p>
<p id="rfc.section.2.4.p.2">Because of the outer method requirements in particular, removing any support for fragmented messages in EAP-CREDS removes the duplication of packets (e.g., Acknowledgment Packets) sent across the Peer and the Server, thus resulting in a smaller number of exchanged messages. </p>
<h1 id="rfc.section.2.5">
<a href="#rfc.section.2.5">2.5.</a> <a href="#teap_creds" id="teap_creds">Encapsulating Provisioning Protocols in EAP-CREDS</a>
</h1>
<p id="rfc.section.2.5.p.1">In order to use EAP-CREDS together with your favorite provisioning protocol, the messages from the provisioning protocol need to be sent to the other party. In EAP-CREDS, this is done by encoding the provisioning protocol messages inside the ('ProtoData') TLV. In case the provisioning protocol uses additional data for its operations (e.g., uses HTTP Headers), this data can be encoded in a separate ('ProtoHeaders') TLV. </p>
<p id="rfc.section.2.5.p.2">Since the implementation of the provisioning endpoint could happen in a (logically or physically) different component, a method is needed to identify when a provisioning protocol has actually ended. In EAP-CREDS, the 'D' (Done) bit in the message headers is used for this purpose. </p>
<p id="rfc.section.2.5.p.3">In the first message of Phase Two, the Server provides the client with all the selected parameters for one specific credential that needs attention (or for a new credential) to be managed by the network. In particular, the server provides, at minimum, the ('Protocol') TLV, the ('Action') TLV, and the ('Params') or the ('Creds-Info') TLV. </p>
<p id="rfc.section.2.5.p.4">After checking the parameters sent by the Server, if the Peer does not support any of the proposed ones, it MUST send a message with one single ('Error') TLV with the appropriate error code(s). The server, can then decide if to manage a different set of credentials (if more where reported by the Peer in its Phase One message) or if to terminate the EAP session with an error. </p>
<p id="rfc.section.2.5.p.5">The Peer and the Server exchange Provisioning messages until an error is detected (and the appropriate error message is sent to the other party) or until Phase Two is successfully completed. </p>
<h1 id="rfc.section.2.6">
<a href="#rfc.section.2.6">2.6.</a> <a href="#eap_creds_hashing" id="eap_creds_hashing">Algorithm Requirements</a>
</h1>
<p id="rfc.section.2.6.p.1">EAP-CREDS uses the SHA-256 hashing algorithm to verify credentials in phase three of the protocol. Peers and Servers MUST support SHA-256 for this purpose. </p>
<h1 id="rfc.section.2.7">
<a href="#rfc.section.2.7">2.7.</a> <a href="#notation" id="notation">Notation</a>
</h1>
<p id="rfc.section.2.7.p.1">In this document we use the following notation in the diagrams to provide information about the cardinality of the data structures (TLVs) within EAP-CREDS messages: </p>
<div id="rfc.table.1"></div>
<div id="eap_creds_notation"></div>
<table cellpadding="3" cellspacing="0" class="tt full center">
<caption>EAP-CREDS Notation</caption>
<thead><tr>
<th class="center">Symbol</th>
<th class="center">Example</th>
<th class="left">Usage</th>
</tr></thead>
<tbody>
<tr>
<td class="center">{ }</td>
<td class="center">{TLV1}</td>
<td class="left">Curly Brackets are used to indicate a set</td>
</tr>
<tr>
<td class="center">[ ]</td>
<td class="center">{[TLV2]}</td>
<td class="left">Square Brackets are used to indicate that a field is optional</td>
</tr>
<tr>
<td class="center">( )</td>
<td class="center">{TLV1(=V)}</td>
<td class="left">Round Squares are used to specify a value</td>
</tr>
<tr>
<td class="center">+ </td>
<td class="center">{TLV_2+}</td>
<td class="left">The Plus character indicates that one or more instances are allowed</td>
</tr>
</tbody>
</table>
<h1 id="rfc.section.3">
<a href="#rfc.section.3">3.</a> EAP-CREDS Protocol</h1>
<p id="rfc.section.3.p.1">In a nutshell, EAP-CREDS provides the abstraction layer on top of which credentials provisioning/managing protocols can be deployed thus enabling their use even before provisioning IP services. </p>
<p id="rfc.section.3.p.2">This section outlines the operation of the protocol and message flows. The format of the CREDS messages is given in <a href="#creds_msg" class="xref">Section 4</a>. </p>
<h1 id="rfc.section.3.1">
<a href="#rfc.section.3.1">3.1.</a> Message Flow</h1>
<p id="rfc.section.3.1.p.1">EAP-CREDS message flow is logically subdivided into three different phases: Initialization, Provisioning, and Validation. EAP-CREDS enforces the order of phases, i.e. it is not possible to move to an earlier phase. </p>
<p id="rfc.section.3.1.p.2">Phase transitioning is controlled by the Server. In particular, the server, after the last message of a phase, it can decide to either (a) start the next phase by sending the first message of the next phase, or (b) continue the same phase by sending another "first" message of the phase (e.g., managing a second set of credentials) - this is allowed only in Phase Two and Phase Three but NOT in Phase One, or (c) terminate the EAP session. </p>
<p></p>
<dl>
<dt>Phase One (Required).</dt>
<dd style="margin-left: 8">Initialization. During this phase the Peer and the Server exchange the information needed to select the appropriate credentials management protocol. Phase One flow is composed by only messages. In particular, the Sever sends its initial message of type ('EAP-CREDS-Init'). The Peer replies with the details about which provisioning protocols are supported, and additional information such as the list of installed credentials and, optionally, authorization data (for new credentials registration). </dd>
<dt>Phase Two (Optional).</dt>
<dd style="margin-left: 8">Provisioning Protocol Flow. In this phase, the Peer and the Server exchange the provisioning protocol's messages encapsulated in a EAP-CREDS message of type Provisioning. The messages use two main TLVs. The first one is the ('ProtoHeaders') TLV which is optional and carries information that might be normally conveyed via the transport protocol (e.g., HTTP headers). The second one is the ('ProtoData'), which is required and carries the provisioning protocol's messages. The server can decide to repeat phase two again to register new credentials or to renew a separate set of credentials by issuing a new ('Provisioning') message for the new target. When no more credentials have to be managed, the Server can start phase three or simply terminate the EAP session. </dd>
<dt>Phase Three (Optional).</dt>
<dd style="margin-left: 8">Credentials Validation. This optional phase can be initiated by the server and it is used to validate that the Peer has properly installed the credentials and can use them to authenticate itself. Depending on the credentials' type, the messages can carry a challenge/nonce, the value of the secret/token, or other information. The format of the credentials is supposed to be known by the provider and the device. </dd>
</dl>
<p> </p>
<h1 id="rfc.section.3.2">
<a href="#rfc.section.3.2">3.2.</a> <a href="#phase_transitioning" id="phase_transitioning">Phase Transitioning Rules</a>
</h1>
<p id="rfc.section.3.2.p.1">In order to keep track of starting and ending a phase, EAP-CREDS defines several bits and fields in the EAP-CREDS message headers. In particular, as described in <a href="#creds_header" class="xref">Section 4.1</a>, the 'S' (Start) bit is used to indicate the beginning (or Start) of a phase, while the 'Phase' field (4 bits) is used to indicate the phase for this message. </p>
<p id="rfc.section.3.2.p.2">In EAP-CREDS, phase transitioning is under the sole control of the Server, therefore the value of the 'S' (Start) bit is meaningful only in messages sent by the Server. The value of the 'S' (Start) bit in Peer's messages SHALL be set to '0x0' and SHALL be ignored by the server. </p>
<p id="rfc.section.3.2.p.3">When starting a new phase, the Server MUST set the 'S' (Start) bit to '1' and the 'Phase' field to the current phase number (e.g., 0x01 for phase one, 0x02 for phase two, or 0x03 for phase three). </p>
<p id="rfc.section.3.2.p.4">In case the first message of a phase is to be repeated (e.g., because of processing multiple credentials), the 'S' (Start) bit SHALL be set to '0' (i.e., it should be set to '1' only on the first occurrence and set to '0' in subsequent messages). </p>
<h1 id="rfc.section.3.3">
<a href="#rfc.section.3.3">3.3.</a> <a href="#creds_phase_one" id="creds_phase_one">Phase One: Initialization</a>
</h1>
<p id="rfc.section.3.3.p.1">The following figure provides the message flow for Phase One: </p>
<pre>
,--------. ,----------.
|EAP Peer| |EAP Server|
`---+----' `----+-----'
| Outer Tunnel Established |
| <--------------------------------------->
| |
| [1] EAP-Request/EAP-CREDS(Type=Init) | ,---------!.
| { [ Version+ ], [ Challenge-Data ] }| |Phase One|_\
| <---------------------------------------- |Begins |
| | `-----------'
| [2] EAP-Response/EAP-CREDS(Type=Init) |
| { [ Version+ ], [ Protocols+ ], |
| [ Creds-Info+ ], [ Encoding+ ], | ,---------!.
| [ Format+ ], [ Token ], | |Phase One|_\
| [ Profile+ ], [ Challenge-Rsp ], | |Ends |
| [ Storage-Info ],[ Net-Usage] } | `-----------'
| ---------------------------------------->
| |
| |
</pre>
<p class="figure">EAP-CREDS Phase One Message Flow</p>
<p id="rfc.section.3.3.p.2">[1] Server sends EAP-Request/EAP-CREDS(Type=Init): </p>
<ul class="empty">
<li>After the establishment of the outer mechanism (e.g., EAP-TLS, EAP-TEAP, EAP-TTLS, etc.), the server MAY decide to start a credentials management session. In order to do that, the Server sends an EAP-Request/EAP-CREDS(Type=Init) message to the Peer with the 'S' (Start) bit set to '1' and the Phase field value set to '0x01' (thus indicating the beginning of Phase One) as described in <a href="#creds_header" class="xref">Section 4.1</a>. Also, the Server MAY use one or more ('Version') TLVs to indicate the supported versions. </li>
<li>The Server MAY also specify which versions of EAP-CREDS are supported by adding zero, one or more ('Version') TLVs. If no ('Version') TLV is added to the message, the Peer SHOULD assume the supported version is 1 ('0x01'). </li>
<li>Optionally, the Server MAY also send a ('Challenge-Data') TLV which includes chanllenge data value (usually some random value) and a specified challenge type. The Peer MUST use the specified type and use chanllenge data value for calculating the ('Challenge-Response') TLV. </li>
</ul>
<p> </p>
<p id="rfc.section.3.3.p.3">[2] The Peer sends EAP-Response/EAP-CREDS(Type=Init) </p>
<ul class="empty">
<li>The Peer, sends back a message that carries one ('Version') TLV to indicate the selected version of EAP-CREDS (i.e. from the list provided by the server) (optional). If the client does not include the ('Version') TLV, the Server MUST use the most recent supported version of EAP-CREDS. Moreover, the Server includes one or more ('Protocol') TLVs to indicate the list of supported provisioning protocols, followed by one ('Creds-Info') TLVs for each installed credentials to provide their status to the server (i.e., if multiple credentials are configured on the Peer for this Network, then the Peer MUST include one ('Creds-Info') TLV for each of them). </li>
<li>The Peer MAY also provide the list of supported Encodings and Formats by adding one or more ('Encoding') and ('Formats') TLVs. The Peer MAY also provide the Server with information about the Peer's credentials storage by using the ('Storage-Info') TLV. </li>
<li>When there are no available credentials, the Peer MAY include an authorization token that can be consumed by the Server for registering new credentials. In particular, the Peer can include the ('Token') TLV to convey the value of the token. The ('Challenge-Data') and ('Challenge-Response') TLVs, instead, can be used to convey a challenge and its response based on the authorization information. For example, suppose a public key hash is present in the Token, the peer can generate some random data - or use the one from the Server - and generate a signature on that value: the signature SHALL be encoded in the ('Challenge-Response') TLV and it should be calculated over the concatenation of values inside the ('Challenge-Data') TLV and the ('Token') TLV. </li>
<li>Also, the Peer MAY add one or more ('Profile') TLVs to indicate to the Server which profiles are requested/supported (e.g., a pre-configuration MAY exist on the Peer with these ecosystem-specific identifiers). </li>
<li>Ultimately, the Peer MAY include additional metadata regarding the status of the Peer. To this end, the Peer can use a ('Storage-Info') TLV to provide the server with additional data about the Peer's capabilities and resources. Also, the ('Net-Usage') TLV can be used to provide the Server with the indication of which network resources are needed by the Peer and what is its intended utilization pattern(s). </li>
<li>The server checks that the Peer's selected protocol, version, and parameters are supported and, if not (or if the server detects an error), it can (a) send a non-recoverable error message to the peer, notify the outer (tunneling) layer, and terminate the EAP-CREDS session, or (b) start phase one again by sending a new ('EAP-CREDS-Init') message that will also carry an ('ERROR') TLV that provides the Peer with the reason the initial response was not acceptable. In this case, the ('Phase') field MUST be omitted since it is not the first message of phase one. The server and the peer can repeat phase one until they reach an agreement or the session is terminated by the Server. </li>
</ul>
<p> </p>
<p></p>
<ul class="empty"><li>NOTE WELL: The determination of the need to start phase two or not is based on the contents of the ('Creds-Info') TLV sent by the Peer (e.g., a credential is about to expire or a credential is simply missing). </li></ul>
<p> </p>
<h1 id="rfc.section.3.4">
<a href="#rfc.section.3.4">3.4.</a> <a href="#creds_phase_two" id="creds_phase_two">Phase Two: Provisioning</a>
</h1>
<p id="rfc.section.3.4.p.1">The following figure provides the message flow for Phase 2: </p>
<pre>
,--------. ,----------.
|EAP Peer| |EAP Server|
`---+----' `----+-----'
| [1] EAP-Request/EAP-CREDS(Type=Provisioning) |
| { Protocol, Action, | ,---------!.
| [ Creds-Info ], [ Params ], | |Phase Two|_\
| [ ProtoData ], [ ProtoHeaders ] } | |Begins |
| <---------------------------------------------- `-----------'
| |
| [2] EAP-Response/EAP-CREDS(Type=Provisioning) |
| { ProtoData, [ ProtoHeaders ] } |
| ---------------------------------------------->
| |
. .
. .
. .
. .
| [N] EAP-Response/EAP-CREDS(Type=Provisioning) |
| { [ Creds-Info ], [ ProtoData ], |
| [ ProtoHeaders ] } |
| <----------------------------------------------
| |
| [N+1] EAP-Request/EAP-CREDS(Type=Provisioning)| ,---------!.
| { [ ProtoData ], [ ProtoHeaders ] } | |Phase Two|_\
| ----------------------------------------------> |Ends |
| | `-----------'
| |
</pre>
<p class="figure">EAP-CREDS Phase Two Message Flow</p>
<p id="rfc.section.3.4.p.2">[1] The Server sends EAP-Request/EAP-CREDS(Type=Provisioning) </p>
<ul class="empty"><li>The first message of Phase Two indicates that the Server is ready to initiate the selected provisioning protocol.This message contains the parameters of the selected provisioning protocol in the ('Params') (e.g., algorithm for generating credentials), the description of installed credentials in the ('Creds-Info'), the selected provisioning protocol's message data and some extra fields (e.g., transport-protocol headers) in the ('ProtoData') and its content in ('ProtoHeaders') TLVs respectively. </li></ul>
<p> </p>
<p id="rfc.section.3.4.p.3">[2] The Peer sends EAP-Response/EAP-CREDS(Type=Provisioning) </p>
<ul class="empty"><li>After that, the Peer sends its first message to the Server by sending the EAP-Response/EAP-CREDS(Type=Provisioning) message. This message contains the selected provisioning protocol's message data and some extra fields (e.g., transport-protocol headers) in the ('ProtoData') and its content in ('ProtoHeaders') TLVs respectively. </li></ul>
<p> </p>
<p id="rfc.section.3.4.p.4">[N=3] The Server sends EAP-Request/EAP-CREDS(Type=Provisioning) </p>
<ul class="empty"><li>The Server replies to the Peer's message with EAP-Request/EAP-CREDS(Type=Provisioning) messages until the provisioning protocol reaches an end or an error condition arise (non-recoverable). </li></ul>
<p> </p>
<p id="rfc.section.3.4.p.5">[N] The Server sends EAP-Request/EAP-CREDS(Type=Provisioning) </p>
<ul class="empty"><li>When the provisioning protocol has been executed for the specific set of credentials, the server sends a last message that MUST include the description of the provisioned credentials in a ('Creds-Info') TLV and MUST set the 'D' (Done) bit in the EAP-CREDS message header to '1' to indicates that the server does not have any more ('Type=Provisioning') messages for this credenital. The final message does not need to be an empty one, i.e. other TLVs are still allowed in the same message (e.g., the 'ProtoData' and the 'ProtoHeaders' ones). </li></ul>
<p> </p>
<p id="rfc.section.3.4.p.6">[N+1] The Peer sends EAP-Request/EAP-CREDS(Type=Provisioning) </p>
<ul class="empty"><li>The Peer MUST reply to the server with a ('Type=Provisioning') message that MUST have the 'D' (Done) bit in the EAP-CREDS message header set to '1', thus indicating that the credentials have been installed correctly. In case of errors, the Peer MUST include the appropriate ('Error') TLV. Also in this case, the final message does not need to be an empty one, i.e. other TLVs are still allowed in the same message (e.g., tthe 'ProtoData' and the 'ProtoHeaders' ones). </li></ul>
<p> </p>
<p id="rfc.section.3.4.p.7">At this point, the Server can decide to provision (or manage) another set of credentials by issuing a new ('Type=Provisioning') message, or it can decide to start Phase Three by sending its first ('Type=Validate') message, or it can terminate the EAP session. </p>
<h1 id="rfc.section.3.5">
<a href="#rfc.section.3.5">3.5.</a> <a href="#creds_phase_three" id="creds_phase_three">Phase Three: Validation</a>
</h1>
<p id="rfc.section.3.5.p.1">The following figure provides the message flow for Phase 3: </p>
<pre>
,--------. ,----------.
|EAP Peer| |EAP Server|
`---+----' `----+-----'
| [1] EAP-Request/EAP-CREDS(Type=Validate) | ,-----------!.
| { Creds-Info, Challenge-Data } | |Phase Three|_\
| <----------------------------------------- |Begins |
| | `-------------'
| [2] EAP-Response/EAP-CREDS(Type=Validate)| ,-----------!.
| { Challenge-Response } | |Phase Three|_\
| -----------------------------------------> |Ends |
| | `-------------'
| |
</pre>
<p class="figure">EAP-CREDS Phase Three Message Flow</p>
<p id="rfc.section.3.5.p.2">Phase three is optional and it is used by the server to request the client to validate (with proof) that the new credentials have been installed correctly before issuing the final EAP-CREDS Success message. </p>
<p></p>
<ul class="empty"><li>NOTE WELL: Phase Three introduces a dependency on the selected hashing algorithm to provide common and easy way to check the integrity and functionality of a newly installed set of credentials. </li></ul>
<p> </p>
<p id="rfc.section.3.5.p.4">[1] The Server sends EAP-Request/EAP-CREDS(Type=Validate) </p>
<ul class="empty">
<li>In order to start Phase Three, the Server sends an EAP-Request/EAP-CREDS(Type=Validate) message to the Peer. The Server MUST include the ('Creds-Info') TLV to provide the indication about which set of credentials the Server intends to validate. The Server MUST also include a randomly generated challenge in the message to the client. The type of challenge determines in ('Challenge-Data') for the peer to calculate ('Challenge-Response'). EAP-CREDS defines the asymmetric and symmetric challenges in <a href="#eap_creds_challenge_types" class="xref">Section 7.5</a> and others can be defined according to the specified rules. </li>
<li>As usual, the Server MUST set, in the headers, the 'S' (Start) bit to '1' in its first message of Phase Three and the 'Phase' value shall be set to '3' (beginning of Phase Three). </li>
</ul>
<p> </p>
<p id="rfc.section.3.5.p.5">[2] The Peer sends EAP-Response/EAP-CREDS(Type=Validate) </p>
<ul class="empty">
<li>When the client receives the Validate message from the server, it calculates the response to the challenge and sends the response back to the server in a EAP-Response/EAP-CREDS(Type=Validate) message. When the 'EAP-CREDS-ASYMMETRIC-CHALLENGE' and 'EAP-CREDS-SYMMETRIC-CHALLENGE' values are used in the 'Challenge types', the Peer MUST calculate the response as follows: <ul class="empty">
<li>Public-Key <ul class="empty"><li>For any public-key based credentials (e.g., certificates or raw key pairs), the response to the challenge is calculated by generating a signature over the hashed value of the challenge. The hashing algorithm to be used for this purpose is specified in <a href="#eap_creds_hashing" class="xref">Section 2.6</a>. The format of the signature in the ('Challenge-Response') TLV is the concatenation of: <ul>
<li>The signatureAlgorithm (DER encoded) which contains the identifier for the cryptographic algorithm used by the Peer to generate the signature using <a href="#RFC3279" class="xref">[RFC3279]</a>, <a href="#RFC4055" class="xref">[RFC4055]</a>, and <a href="#RFC4491" class="xref">[RFC4491]</a> list supported signature algorithms. Other signature algorithms MAY also be supported. The definition of the signatureAlgorithm is provided in Section 4.1.1.2 of <a href="#RFC5280" class="xref">[RFC5280]</a>. </li>
<li>The signatureValue (DER encoded) which contains the digital signature itself. The signature value is encoded as a BIT STRING and the details of how to generate the signatures' structures can be found in Section 4.1.1.3 of <a href="#RFC5280" class="xref">[RFC5280]</a> and referenced material. </li>
</ul>
<p> </p>
</li></ul>
<p> </p>
</li>
<li>Symmetric Secret <ul class="empty"><li>For any symmetric based credentials (e.g., password or Key), the response to the challenge is calculated by using the selected hash function (see <a href="#eap_creds_hashing" class="xref">Section 2.6</a>) on the concatenation of (a) the value carried in the server-provided ('Challenge-Data') TLV, and (b) the secret value itself (salted hash). </li></ul>
<p> </p>
</li>
</ul>
<p> </p>
</li>
<li>The initial values for the type of challenges are described in the <a href="#eap_creds_challenge_types" class="xref">Section 7.5</a>. Other types of challenges MAY be defined according to the specified procedures. </li>
<li>In case of issues with the validation of newly deployed credentials, both the Server and the Peer should consider those credentials invalid (or unusable) and should issue the required failure message(s). </li>
</ul>
<p> </p>
<h1 id="rfc.section.4">
<a href="#rfc.section.4">4.</a> <a href="#creds_msg" id="creds_msg">EAP-CREDS Message Format</a>
</h1>
<p id="rfc.section.4.p.1">The EAP-CREDS defines the following message types: </p>
<ol>
<li>EAP-CREDS-Init</li>
<li>EAP-CREDS-Provisioning</li>
<li>EAP-CREDS-Validate</li>
</ol>
<p> </p>
<p id="rfc.section.4.p.2">Each of these message types have the basic structure as identified in <a href="#creds_header" class="xref">Section 4.1</a>. EAP-CREDS messages contain zero, one, or more TLVs. The internal structure of the different types of TLVs is described in <a href="#creds_msg_payload" class="xref">Section 4.2</a>, while a detailed description of the EAP-CREDS message types is provided in <a href="#creds_msg_types" class="xref">Section 5</a>. </p>
<h1 id="rfc.section.4.1">
<a href="#rfc.section.4.1">4.1.</a> <a href="#creds_header" id="creds_header">Message Header</a>
</h1>
<p id="rfc.section.4.1.p.1">The EAP-CREDS messages consist of the standard EAP header (see Section 4 of <a href="#RFC3748" class="xref">[RFC3748]</a>), followed by the message payload of the EAP-CREDS. The header has the following structure: </p>
<pre>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |J|S|F|D| Phase | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.
</pre>
<p id="rfc.section.4.1.p.2">Where the Code, Identifier, Length, and Type fields are all part of the EAP header as defined in <a href="#RFC3748" class="xref">[RFC3748]</a>. Since EAP-CREDS can only be used as a tunneled mechanism, the presence of these fields is only for backward compatibility with existing parsers. In particular, the 'Length' field is used for fragmentation instead of the message length: the message length is carried in the 'Message Length' field if Jumbo Message is indicated in the header. </p>
<p id="rfc.section.4.1.p.3">The Type field in the EAP header is <TBD> for EAP-CREDS. </p>
<p id="rfc.section.4.1.p.4">The Flags bitfield is used to convey status information (e.g., extra long message, phase number, phase transitioning state). The transition-control bit (i.e., the 'S' (Start) bit) are set in Server's messages and are ignored in Peer's messages (the Server is the entity that unilaterally controls the phase transition process). The meanings of the bits in the 'Flags' field are as follows: </p>
<ul class="empty">
<li>Bit 'J' (Jumbo Message) - If set, it indicates the presence of the 'Message Length' field. This bit SHALL be used only when the size of the message exceeds the maximum value allowed in the 'Length' field. In this case, the 'Message Length' field is added to the message and set to the whole message size and the 'Length' field is used for the current fragment length. If not set, the 'Message Length' field is not present in the Message and the 'Length' field is used for the message size (and the 'F' (Fragment) bit MUST be set to '0'). </li>
<li>Bit 'S' (Start) - If set, this message is the first one of a new EAP-CREDS phase. The value of the new phase is encoded in the 'Phase' field. </li>
<li>Bit 'F' (Fragment) - If set, this message is a fragment of a message. In this case, the 'Data' field is to be concatenated with all messages with the 'F' (Fragment) bit set to '1' until the message with the 'F' (Fragment) bit set to '0' that indicates the end of the message. If the message is not fragmented, the 'F' (Fragment) bit MUST be set to '0'. The use of this bit is required when the tunneling method does not provide support for messages up to 2^32 bits in size. </li>
<li>Bit 'D' (Done) - This bit is used in Phase Two and Phase Three to indicate that the specific operation for the identified credential is over. For example, when multiple credentials exist on the Peer and the Server needs to manage and validate one of them. In its last message, when the provisioning protocol is done, the server sets the 'D' (Done) bit to indicate that it is done. The Peer, in its reply, sets the bit to indicate the end of provisioning for this credentials is also over. After that, the Server can continue Phase Two, transition to Phase Three, or terminate the EAP session. </li>
</ul>
<p> </p>
<p id="rfc.section.4.1.p.5">The Phase field is a 4-bits value and identifies the EAP-CREDS phase for the current message. The version of EAP-CREDS described in this document supports three values for this field: </p>
<ul class="empty">
<li>0x01 - Phase One</li>
<li>0x02 - Phase Two</li>
<li>0x03 - Phase Three</li>
</ul>
<p> </p>
<p id="rfc.section.4.1.p.6">A detailed explanation of the 'Phase' and 'Flags' fields of the message headers is provided in <a href="#phase_transitioning" class="xref">Section 3.2</a>. </p>
<p id="rfc.section.4.1.p.7">The Data field is the message payload. The full description of this field is provided in the next section. </p>
<h1 id="rfc.section.4.2">
<a href="#rfc.section.4.2">4.2.</a> <a href="#creds_msg_payload" id="creds_msg_payload">Message Payload</a>
</h1>
<p id="rfc.section.4.2.p.1">The Data part of the message is organized as zero, one, or more TLV objects whose structure is defined in this section. </p>
<p id="rfc.section.4.2.p.2">Each TLV object has the same basic structure that is defined as follows: </p>
<pre>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
<p id="rfc.section.4.2.p.3">Where:</p>
<p id="rfc.section.4.2.p.4">TLV-Type (uint8) </p>
<ul class="empty"><li>This field is used to indicate the type of data that the TLV carries. The type of TLV determines its internal structure. The supported values for this fields are provided in the following table: </li></ul>
<p> </p>
<p id="rfc.section.4.2.p.5">Length (uint24) </p>
<ul class="empty"><li>This field carries the size of the value of the TLV. In particular, the overall size of a TLV (i.e., the header plus the value) can be calculated by adding the size of the header (6 octets) to the value of the Length field (i.e., the size of the TLV's value). </li></ul>
<p> </p>
<div id="rfc.table.2"></div>
<div id="eap_creds_tlvs_table"></div>
<table cellpadding="3" cellspacing="0" class="tt full center">
<caption>EAP-CREDS Supported TLVs Types</caption>
<thead><tr>
<th class="center">TLV Name</th>
<th class="left">TLV Type</th>
<th class="center">Scope/Usage</th>
</tr></thead>
<tbody>
<tr>
<td class="center"><TBD></td>
<td class="left">Action TLV</td>
<td class="center">Phase Two</td>
</tr>
<tr>
<td class="center"><TBD></td>
<td class="left">Certificate-Data TLV</td>
<td class="center">Phase Two</td>
</tr>
<tr>
<td class="center"><TBD></td>
<td class="left">Challenge-Data TLV</td>
<td class="center">Phase Two, Phase Three</td>
</tr>
<tr>
<td class="center"><TBD></td>
<td class="left">Challenge-Response TLV</td>
<td class="center">Phase Two, Phase Three</td>
</tr>
<tr>
<td class="center"><TBD></td>
<td class="left">Credentials-Data TLV</td>
<td class="center">Phase Two</td>
</tr>
<tr>
<td class="center"><TBD></td>
<td class="left">Creds-Info TLV</td>
<td class="center">Phase Two, Phase Three</td>
</tr>
<tr>
<td class="center"><TBD></td>
<td class="left">Error TLV</td>
<td class="center">All Phases</td>
</tr>
<tr>
<td class="center"><TBD></td>