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
|
<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-emu-eap-session-id-07.txt" indexInclude="true" ipr="trust200902" number="8940" prepTime="2020-10-23T15:07:15" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" updates="5247" xml:lang="en">
<link href="https://datatracker.ietf.org/doc/draft-ietf-emu-eap-session-id-07.txt" rel="prev"/>
<link href="https://dx.doi.org/10.17487/rfc8940" rel="alternate"/>
<link href="urn:issn:2070-1721" rel="alternate"/>
<front>
<title abbrev="EAP Session-Id Derivation">Extensible Authentication Protocol (EAP) Session-Id Derivation for EAP Subscriber Identity Module (EAP-SIM), EAP Authentication and Key Agreement (EAP-AKA), and Protected EAP (PEAP)</title>
<seriesInfo name="RFC" value="8940" stream="IETF"/>
<author initials="A." surname="DeKok" fullname="Alan DeKok">
<organization abbrev="FreeRADIUS" showOnFrontPage="true">The FreeRADIUS Server Project</organization>
<address>
<email>aland@freeradius.org</email>
</address>
</author>
<date month="10" year="2020"/>
<keyword>EAP</keyword>
<keyword>PEAP</keyword>
<keyword>EAP-AKA</keyword>
<keyword>EAP-SIM</keyword>
<keyword>ERP</keyword>
<keyword>FILS</keyword>
<keyword>Session-ID</keyword>
<keyword>fast reconnect</keyword>
<keyword>TLS</keyword>
<abstract pn="section-abstract">
<t indent="0" pn="section-abstract-1">
RFC 5247 is updated to define and clarify EAP Session-Id derivation
for multiple Extensible Authentication
Protocol (EAP) methods. The derivation of Session-Id was not given
for EAP Subscriber Identity Module (EAP-SIM) or EAP Authentication and Key Agreement (EAP-AKA) when using the fast reconnect exchange instead
of full authentication. The derivation of Session-Id for full
authentication is clarified for both EAP-SIM and EAP-AKA. The
derivation of Session-Id for Protected EAP (PEAP) is also given. The definition for
PEAP follows the definition for other TLS-based EAP methods.</t>
</abstract>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
<t indent="0" pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
</t>
<t indent="0" pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc8940" brackets="none"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-updates-to-rfc-5247-appendi">Updates to RFC 5247, Appendix A</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
<li pn="section-toc.1-1.2.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-eap-aka">EAP-AKA</xref></t>
</li>
<li pn="section-toc.1-1.2.2.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-eap-sim">EAP-SIM</xref></t>
</li>
<li pn="section-toc.1-1.2.2.3">
<t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-rationale-for-eap-aka-and-e">Rationale for EAP-AKA and EAP-SIM Updates</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-session-id-for-peap">Session-Id for PEAP</xref></t>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
</li>
</ul>
</section>
</toc>
</front>
<middle>
<section anchor="sect-1" numbered="true" toc="include" removeInRFC="false" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t indent="0" pn="section-1-1">
EAP <xref target="RFC3748" format="default" sectionFormat="of" derivedContent="RFC3748"/> Session-Id derivation has not
been defined for EAP-SIM and EAP-AKA when using the fast reconnect exchange
instead of full authentication. <xref target="RFC5247" format="default" sectionFormat="of" derivedContent="RFC5247"/>
defines the Session-Id for these EAP methods, but that derivation is only
applicable for the full authentication case. The Session-Id derivation was
not defined for EAP-AKA', but <xref target="I-D.ietf-emu-rfc5448bis" format="default" sectionFormat="of" derivedContent="AKAP"/> now defines it, along with other updates. As such, the
definition for EAP-AKA' is not included here.</t>
<t indent="0" pn="section-1-2">
Further, the derivation of Session-Id for full authentication is
clarified, as the text in <xref target="RFC5247" format="default" sectionFormat="of" derivedContent="RFC5247"/> is
ambiguous.</t>
<t indent="0" pn="section-1-3">
The IEEE has defined Fast Initial Link Setup (FILS) authentication <xref target="FILS" format="default" sectionFormat="of" derivedContent="FILS"/>, which needs the EAP Session-Id in order
for the EAP Re-authentication Protocol (ERP) <xref target="RFC6696" format="default" sectionFormat="of" derivedContent="RFC6696"/> to work. It is therefore important to address the
existing deficiencies in the definition of EAP Session-Id.</t>
<t indent="0" pn="section-1-4">
Finally, <xref target="RFC5247" format="default" sectionFormat="of" derivedContent="RFC5247"/> did not define
Session-Id for PEAP <xref target="MS-PEAP" format="default" sectionFormat="of" derivedContent="MS-PEAP"/> <xref target="I-D.josefsson-pppext-eap-tls-eap" format="default" sectionFormat="of" derivedContent="PEAP"/>. We correct
these deficiencies here by updating <xref target="RFC5247" format="default" sectionFormat="of" derivedContent="RFC5247"/> with the Session-Id derivation during fast-reconnect
exchange for EAP-SIM and EAP-AKA; clarifying the Session-Id derivation
during full authentication for EAP-SIM and EAP-AKA; and defining the
Session-Id derivation for PEAP, which is the same for both full
authentication and fast reconnect.</t>
</section>
<section anchor="sect-2" numbered="true" toc="include" removeInRFC="false" pn="section-2">
<name slugifiedName="name-updates-to-rfc-5247-appendi">Updates to RFC 5247, Appendix A</name>
<t indent="0" pn="section-2-1">
This section updates <xref target="RFC5247" sectionFormat="comma" section="A" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5247#appendix-A" derivedContent="RFC5247"/> to define Session-Id for fast reconnect exchange for EAP-AKA and
EAP-SIM.</t>
<section anchor="sect-2.1" numbered="true" toc="include" removeInRFC="false" pn="section-2.1">
<name slugifiedName="name-eap-aka">EAP-AKA</name>
<t indent="0" pn="section-2.1-1">
For EAP-AKA, <xref target="RFC5247" sectionFormat="comma" section="A" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5247#appendix-A" derivedContent="RFC5247"/> says:</t>
<blockquote pn="section-2.1-2">
<dl newline="true" indent="3" spacing="normal" pn="section-2.1-2.1">
<dt pn="section-2.1-2.1.1">EAP-AKA</dt>
<dd pn="section-2.1-2.1.2">
<t indent="0" pn="section-2.1-2.1.2.1">EAP-AKA is defined in <xref target="RFC4187" format="default" sectionFormat="of" derivedContent="RFC4187"/>. The EAP-AKA Session-Id is the concatenation of
the EAP Type Code (0x17) with the contents of the RAND field from
the AT_RAND attribute, followed by the contents of the AUTN field in
the AT_AUTN attribute:
</t>
<artwork align="left" pn="section-2.1-2.1.2.2">
Session-Id = 0x17 || RAND || AUTN
</artwork>
</dd>
</dl>
</blockquote>
<t indent="0" pn="section-2.1-3">It should say:</t>
<blockquote pn="section-2.1-4">
<dl newline="true" indent="3" spacing="normal" pn="section-2.1-4.1">
<dt pn="section-2.1-4.1.1">EAP-AKA</dt>
<dd pn="section-2.1-4.1.2">
<t indent="0" pn="section-2.1-4.1.2.1">EAP-AKA is defined in <xref target="RFC4187" format="default" sectionFormat="of" derivedContent="RFC4187"/>. When using full
authentication, the EAP-AKA Session-Id is the concatenation of the EAP
Type Code (0x17) with the contents of the RAND field from the AT_RAND
attribute, followed by the contents of the AUTN field in the AT_AUTN
attribute:</t>
<artwork name="" type="" align="left" alt="" pn="section-2.1-4.1.2.2">
Session-Id = 0x17 || RAND || AUTN
</artwork>
<t indent="0" pn="section-2.1-4.1.2.3">When using fast reconnect, the EAP-AKA Session-Id is the
concatenation of the EAP Type Code (0x17) with the contents of the
NONCE_S field from the AT_NONCE_S attribute, followed by the contents
of the MAC field from the AT_MAC attribute from
EAP-Request/AKA-Reauthentication:</t>
<artwork name="" type="" align="left" alt="" pn="section-2.1-4.1.2.4">
Session-Id = 0x17 || NONCE_S || MAC
</artwork>
</dd>
</dl>
</blockquote>
</section>
<section anchor="sect-2.2" numbered="true" toc="include" removeInRFC="false" pn="section-2.2">
<name slugifiedName="name-eap-sim">EAP-SIM</name>
<t indent="0" pn="section-2.2-1">
Similarly for EAP-SIM, <xref target="RFC5247" sectionFormat="comma" section="A" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5247#appendix-A" derivedContent="RFC5247"/> says:</t>
<blockquote pn="section-2.2-2">
<dl newline="true" indent="3" spacing="normal" pn="section-2.2-2.1">
<dt pn="section-2.2-2.1.1">EAP-SIM </dt>
<dd pn="section-2.2-2.1.2">
<t indent="0" pn="section-2.2-2.1.2.1">EAP-SIM is defined in <xref target="RFC4186" format="default" sectionFormat="of" derivedContent="RFC4186"/>. The EAP-SIM
Session-Id is the concatenation of the EAP Type Code (0x12) with the
contents of the RAND field from the AT_RAND attribute, followed by the
contents of the NONCE_MT field in the AT_NONCE_MT attribute:</t>
<artwork name="" type="" align="left" alt="" pn="section-2.2-2.1.2.2">
Session-Id = 0x12 || RAND || NONCE_MT
</artwork>
</dd>
</dl>
</blockquote>
<t indent="0" pn="section-2.2-3">It should say:</t>
<blockquote pn="section-2.2-4">
<dl newline="true" indent="3" spacing="normal" pn="section-2.2-4.1">
<dt pn="section-2.2-4.1.1">EAP-SIM
</dt>
<dd pn="section-2.2-4.1.2">
<t indent="0" pn="section-2.2-4.1.2.1">EAP-SIM is defined in <xref target="RFC4186" format="default" sectionFormat="of" derivedContent="RFC4186"/>.
When using full authentication, the EAP-SIM Session-Id is the
concatenation of the EAP Type Code (0x12) with the contents of the
RAND field from the AT_RAND attribute, followed by the contents of
the NONCE_MT field in the AT_NONCE_MT attribute.
RFC 4186 says that the EAP server should obtain "n" GSM
triplets where "n=2" or "n=3".</t>
<t indent="0" pn="section-2.2-4.1.2.2">For "n=2", the Session-Id is therefore defined as</t>
<artwork name="" type="" align="left" alt="" pn="section-2.2-4.1.2.3">
Session-Id = 0x12 || RAND1 || RAND2 || NONCE_MT
</artwork>
<t indent="0" pn="section-2.2-4.1.2.4">which is 49 octets in length.</t>
<t indent="0" pn="section-2.2-4.1.2.5">For "n=3", the Session-Id is therefore defined as</t>
<artwork name="" type="" align="left" alt="" pn="section-2.2-4.1.2.6">
Session-Id = 0x12 || RAND1 || RAND2 || RAND3 || NONCE_MT
</artwork>
<t indent="0" pn="section-2.2-4.1.2.7">which is 65 octets in length.</t>
<t indent="0" pn="section-2.2-4.1.2.8">RAND1, RAND2, and RAND3 correspond to the RAND value from the
first, second, and third GSM triplet, respectively.</t>
<t indent="0" pn="section-2.2-4.1.2.9">When using fast reconnect, the EAP-SIM Session-Id is the
concatenation of the EAP Type Code (0x12) with the contents of the
NONCE_S field from the AT_NONCE_S attribute, followed by the contents
of the MAC field from the AT_MAC attribute from
EAP-Request/SIM/Reauthentication:</t>
<artwork name="" type="" align="left" alt="" pn="section-2.2-4.1.2.10">
Session-Id = 0x12 || NONCE_S || MAC
</artwork>
<t indent="0" pn="section-2.2-4.1.2.11">which is 33 octets in length.</t>
</dd>
</dl>
</blockquote>
</section>
<section anchor="sect-2.3" numbered="true" toc="include" removeInRFC="false" pn="section-2.3">
<name slugifiedName="name-rationale-for-eap-aka-and-e">Rationale for EAP-AKA and EAP-SIM Updates</name>
<t indent="0" pn="section-2.3-1">
<xref target="RFC5247" sectionFormat="of" section="A" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5247#appendix-A" derivedContent="RFC5247"/> was supposed to define exported parameters for
existing EAP methods. The way Session-Id was defined for
EAP-AKA and EAP-SIM works only for the full authentication case, i.e., it
cannot be used when the optional fast reconnect case is used since the used
parameters (RAND, AUTN, NONCE_MT) are not used in the fast reconnect
case. Based on <xref target="RFC4187" sectionFormat="comma" section="5.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4187#section-5.2" derivedContent="RFC4187"/>
and similar text in
<xref target="RFC4186" sectionFormat="comma" section="5.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4186#section-5.2" derivedContent="RFC4186"/>, NONCE_S corresponds to RAND and MAC
in EAP-Request/AKA-Reauthentication, and EAP-Request/SIM/Reauthentication
corresponds to AUTN. That would seem to imply that the Session-Id could be
defined using NONCE_S and MAC instead of RAND and AUTN/NONCE_MT.</t>
<t indent="0" pn="section-2.3-2">
This derivation is done via a random value created by the server,
along with a secret key and the peer's identity. We believe that
this derivation is secure, though no formal analysis has been done.</t>
</section>
</section>
<section anchor="sect-3" numbered="true" toc="include" removeInRFC="false" pn="section-3">
<name slugifiedName="name-session-id-for-peap">Session-Id for PEAP</name>
<t indent="0" pn="section-3-1">
<xref target="RFC5247" format="default" sectionFormat="of" derivedContent="RFC5247"/> did not define Session-Id for Microsoft's
Protected EAP (PEAP). For consistency with the EAP-TLS definition given in
<xref target="RFC5216" sectionFormat="comma" section="2.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5216#section-2.3" derivedContent="RFC5216"/>, we define it as:</t>
<artwork name="" type="" align="left" alt="" pn="section-3-2">
Session-Id = 0x19 || client.random || server.random
</artwork>
<t indent="0" pn="section-3-3">
This definition is that same for both full authentication and for fast reconnect.</t>
<t indent="0" pn="section-3-4">
This definition is already in widespread use in all known PEAP
implementations.</t>
<t indent="0" pn="section-3-5">
Note that this definition for Session-Id only applies when TLS 1.2 or
earlier is used. A different derivation is defined for TLS 1.3 in
<xref target="I-D.ietf-emu-tls-eap-types" format="default" sectionFormat="of" derivedContent="TLS-EAP-TYPES"/>.</t>
</section>
<section anchor="sect-4" numbered="true" toc="include" removeInRFC="false" pn="section-4">
<name slugifiedName="name-security-considerations">Security Considerations</name>
<t indent="0" pn="section-4-1">
This specification defines EAP Session-Ids for ERP with EAP-SIM and
EAP-AKA. It therefore enables ERP key hierarchy establishment using
fast reconnect with EAP-SIM and EAP-AKA.</t>
<t indent="0" pn="section-4-2">
The Session-Id definitions given here are unique per session, unforgeable, and unguessable by an outside party, as per the
requirements of <xref target="RFC5247" sectionFormat="comma" section="10" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5247#section-10" derivedContent="RFC5247"/>.</t>
<t indent="0" pn="section-4-3">
The definitions used here have been widely deployed for years in
all major EAP implementations. However, we acknowledge that very
little security analysis has been done for these definitions. As a
result, any security issues would result in serious issues for the
Internet as a whole. </t>
<t indent="0" pn="section-4-4">
These updates do not modify the security considerations outlined in
<xref target="RFC5247" format="default" sectionFormat="of" derivedContent="RFC5247"/>.</t>
</section>
<section anchor="sect-5" numbered="true" toc="include" removeInRFC="false" pn="section-5">
<name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t indent="0" pn="section-5-1">
This document has no IANA actions.</t>
</section>
</middle>
<back>
<displayreference target="I-D.ietf-emu-rfc5448bis" to="AKAP"/>
<displayreference target="I-D.ietf-emu-tls-eap-types" to="TLS-EAP-TYPES"/>
<displayreference target="I-D.josefsson-pppext-eap-tls-eap" to="PEAP"/>
<references pn="section-6">
<name slugifiedName="name-references">References</name>
<references pn="section-6.1">
<name slugifiedName="name-normative-references">Normative References</name>
<reference anchor="FILS" quoteTitle="true" target="https://doi.org/10.1109/IEEESTD.2016.7792308" derivedAnchor="FILS">
<front>
<title>IEEE Standard for Information technology--Telecommunications and information exchange between systems - Local and metropolitan area networks--Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - Amendment 1: Fast Initial Link Setup</title>
<author>
<organization showOnFrontPage="true">IEEE</organization>
</author>
<date month="December" year="2016"/>
</front>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7792308"/>
<seriesInfo name="IEEE" value="Std 802.11ai-2016"/>
</reference>
<reference anchor="RFC3748" target="https://www.rfc-editor.org/info/rfc3748" quoteTitle="true" derivedAnchor="RFC3748">
<front>
<title>Extensible Authentication Protocol (EAP)</title>
<author initials="B." surname="Aboba" fullname="B. Aboba">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Blunk" fullname="L. Blunk">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Vollbrecht" fullname="J. Vollbrecht">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Carlson" fullname="J. Carlson">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Levkowetz" fullname="H. Levkowetz" role="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2004" month="June"/>
<abstract>
<t indent="0">This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3748"/>
<seriesInfo name="DOI" value="10.17487/RFC3748"/>
</reference>
<reference anchor="RFC5216" target="https://www.rfc-editor.org/info/rfc5216" quoteTitle="true" derivedAnchor="RFC5216">
<front>
<title>The EAP-TLS Authentication Protocol</title>
<author initials="D." surname="Simon" fullname="D. Simon">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Aboba" fullname="B. Aboba">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Hurst" fullname="R. Hurst">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="March"/>
<abstract>
<t indent="0">The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Layer Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation.</t>
<t indent="0">This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5216"/>
<seriesInfo name="DOI" value="10.17487/RFC5216"/>
</reference>
<reference anchor="RFC5247" target="https://www.rfc-editor.org/info/rfc5247" quoteTitle="true" derivedAnchor="RFC5247">
<front>
<title>Extensible Authentication Protocol (EAP) Key Management Framework</title>
<author initials="B." surname="Aboba" fullname="B. Aboba">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Simon" fullname="D. Simon">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Eronen" fullname="P. Eronen">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="August"/>
<abstract>
<t indent="0">The Extensible Authentication Protocol (EAP), defined in RFC 3748, enables extensible network access authentication. This document specifies the EAP key hierarchy and provides a framework for the transport and usage of keying material and parameters generated by EAP authentication algorithms, known as "methods". It also provides a detailed system-level security analysis, describing the conditions under which the key management guidelines described in RFC 4962 can be satisfied. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5247"/>
<seriesInfo name="DOI" value="10.17487/RFC5247"/>
</reference>
</references>
<references pn="section-6.2">
<name slugifiedName="name-informative-references">Informative References</name>
<reference anchor="I-D.ietf-emu-rfc5448bis" quoteTitle="true" target="https://tools.ietf.org/html/draft-ietf-emu-rfc5448bis-07" derivedAnchor="AKAP">
<front>
<title>Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')</title>
<author fullname="Jari Arkko">
<organization showOnFrontPage="true">Ericsson</organization>
</author>
<author fullname="Vesa Lehtovirta">
<organization showOnFrontPage="true">Ericsson</organization>
</author>
<author fullname="Vesa Torvinen">
<organization showOnFrontPage="true">Ericsson</organization>
</author>
<author fullname="Pasi Eronen">
<organization showOnFrontPage="true">Independent</organization>
</author>
<date month="March" day="9" year="2020"/>
<abstract>
<t indent="0"> The 3GPP Mobile Network Authentication and Key Agreement (AKA) is the
primary authentication mechanism for devices wishing to access mobile
networks. RFC 4187 (EAP-AKA) made the use of this mechanism possible
within the Extensible Authentication Protocol (EAP) framework. RFC
5448 (EAP-AKA') was an improved version of EAP-AKA.
This memo replaces the specification of EAP-AKA'. EAP-AKA' was
defined in RFC 5448 and updated EAP-AKA RFC 4187. As such this
document obsoletes RFC 5448 and updates RFC 4187.
EAP-AKA' differs from EAP-AKA by providing a key derivation function
that binds the keys derived within the method to the name of the
access network. The key derivation function has been defined in the
3rd Generation Partnership Project (3GPP). EAP-AKA' allows its use
in EAP in an interoperable manner. EAP-AKA' also updates the
algorithm used in hash functions, as it employs SHA-256 / HMAC-
SHA-256 instead of SHA-1 / HMAC-SHA-1 as in EAP-AKA.
This version of EAP-AKA' specification specifies the protocol
behaviour for both 4G and 5G deployments, whereas the previous
version only did this for 4G.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-emu-rfc5448bis-07"/>
<format type="TXT" target="https://www.ietf.org/internet-drafts/draft-ietf-emu-rfc5448bis-07.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="Err5011" target="https://www.rfc-editor.org/errata/eid5011" quoteTitle="false" derivedAnchor="Err5011">
<front>
<title>Erratum ID 5011</title>
<author>
<organization showOnFrontPage="true">RFC Errata</organization>
</author>
</front>
<refcontent>RFC 5247</refcontent>
</reference>
<reference anchor="MS-PEAP" target="https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-peap/5308642b-90c9-4cc4-beec-fb367325c0f9" quoteTitle="true" derivedAnchor="MS-PEAP">
<front>
<title>[MS-PEAP]: Protected Extensible Authentication Protocol (PEAP)</title>
<author>
<organization showOnFrontPage="true">Microsoft</organization>
</author>
<date/>
</front>
</reference>
<reference anchor="I-D.josefsson-pppext-eap-tls-eap" quoteTitle="true" target="https://tools.ietf.org/html/draft-josefsson-pppext-eap-tls-eap-10" derivedAnchor="PEAP">
<front>
<title>Protected EAP Protocol (PEAP) Version 2</title>
<author initials="A." surname="Palekar" fullname="Ashwin Palekar">
<organization showOnFrontPage="true">Microsoft Corporation</organization>
</author>
<author initials="S." surname="Josefsson" fullname="Simon Josefsson">
<organization showOnFrontPage="true">Extundo</organization>
</author>
<author initials="D." surname="Simon" fullname="Daniel Simon">
<organization showOnFrontPage="true">Microsoft Corporation</organization>
</author>
<author initials="G." surname="Zorn" fullname="Glen Zorn">
<organization showOnFrontPage="true">Cisco Systems</organization>
</author>
<date month="October" day="21" year="2004"/>
<abstract>
<t indent="0">The Extensible Authentication Protocol (EAP) provides support for
multiple authentication methods. This document defines the Protected
Extensible Authentication Protocol (PEAP) Version 2, which provides
an encrypted and authenticated tunnel based on transport layer
security (TLS) that encapsulates EAP authentication mechanisms.
PEAPv2 uses TLS to protect against rogue authenticators, protect
against various attacks on the confidentiality and integrity of the
inner EAP method exchange and provide EAP peer identity privacy.
PEAPv2 also provides support for chaining multiple EAP mechanisms,
cryptographic binding between authentications performed by inner EAP
mechanisms and the tunnel, exchange of arbitrary parameters (TLVs),
and fragmentation and reassembly.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-josefsson-pppext-eap-tls-eap-10"/>
<format type="TXT" target="https://www.ietf.org/internet-drafts/draft-josefsson-pppext-eap-tls-eap-10.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="RFC4186" target="https://www.rfc-editor.org/info/rfc4186" quoteTitle="true" derivedAnchor="RFC4186">
<front>
<title>Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)</title>
<author initials="H." surname="Haverinen" fullname="H. Haverinen" role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Salowey" fullname="J. Salowey" role="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2006" month="January"/>
<abstract>
<t indent="0">This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the Global System for Mobile Communications (GSM) Subscriber Identity Module (SIM). GSM is a second generation mobile network standard. The EAP-SIM mechanism specifies enhancements to GSM authentication and key agreement whereby multiple authentication triplets can be combined to create authentication responses and session keys of greater strength than the individual GSM triplets. The mechanism also includes network authentication, user anonymity support, result indications, and a fast re-authentication procedure. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4186"/>
<seriesInfo name="DOI" value="10.17487/RFC4186"/>
</reference>
<reference anchor="RFC4187" target="https://www.rfc-editor.org/info/rfc4187" quoteTitle="true" derivedAnchor="RFC4187">
<front>
<title>Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)</title>
<author initials="J." surname="Arkko" fullname="J. Arkko">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Haverinen" fullname="H. Haverinen">
<organization showOnFrontPage="true"/>
</author>
<date year="2006" month="January"/>
<abstract>
<t indent="0">This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution that uses the Authentication and Key Agreement (AKA) mechanism. AKA is used in the 3rd generation mobile networks Universal Mobile Telecommunications System (UMTS) and CDMA2000. AKA is based on symmetric keys, and typically runs in a Subscriber Identity Module, which is a UMTS Subscriber Identity Module, USIM, or a (Removable) User Identity Module, (R)UIM, similar to a smart card.</t>
<t indent="0">EAP-AKA includes optional identity privacy support, optional result indications, and an optional fast re-authentication procedure. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4187"/>
<seriesInfo name="DOI" value="10.17487/RFC4187"/>
</reference>
<reference anchor="RFC6696" target="https://www.rfc-editor.org/info/rfc6696" quoteTitle="true" derivedAnchor="RFC6696">
<front>
<title>EAP Extensions for the EAP Re-authentication Protocol (ERP)</title>
<author initials="Z." surname="Cao" fullname="Z. Cao">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="He" fullname="B. He">
<organization showOnFrontPage="true"/>
</author>
<author initials="Y." surname="Shi" fullname="Y. Shi">
<organization showOnFrontPage="true"/>
</author>
<author initials="Q." surname="Wu" fullname="Q. Wu" role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Zorn" fullname="G. Zorn" role="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="July"/>
<abstract>
<t indent="0">The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to avoid repeating the entire EAP exchange with another authenticator. This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re- authentication between the peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network to which the peer is connecting. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6696"/>
<seriesInfo name="DOI" value="10.17487/RFC6696"/>
</reference>
<reference anchor="I-D.ietf-emu-tls-eap-types" quoteTitle="true" target="https://tools.ietf.org/html/draft-ietf-emu-tls-eap-types-01" derivedAnchor="TLS-EAP-TYPES">
<front>
<title>TLS-based EAP types and TLS 1.3</title>
<author fullname="Alan DeKok">
<organization showOnFrontPage="true">FreeRADIUS</organization>
</author>
<date month="July" day="29" year="2020"/>
<abstract>
<t indent="0"> EAP-TLS [RFC5216] is being updated for TLS 1.3 in [EAPTLS]. Many
other EAP [RFC3748] and [RFC5247] types also depend on TLS, such as
FAST [RFC4851], TTLS [RFC5281], TEAP [RFC7170], and possibly many
vendor specific EAP methods. This document updates those methods in
order to use the new key derivation methods available in TLS 1.3.
Additional changes necessitated by TLS 1.3 are also discussed.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-emu-tls-eap-types-01"/>
<format type="TXT" target="https://www.ietf.org/internet-drafts/draft-ietf-emu-tls-eap-types-01.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
</references>
</references>
<section numbered="false" anchor="acknowledgments" toc="include" removeInRFC="false" pn="section-appendix.a">
<name slugifiedName="name-acknowledgments">Acknowledgments</name>
<t indent="0" pn="section-appendix.a-1">
The issue corrected in this specification was first reported by <contact fullname="Jouni Malinen"/> in a technical erratum for RFC 5247 <xref target="Err5011" format="default" sectionFormat="of" derivedContent="Err5011"/>.</t>
<t indent="0" pn="section-appendix.a-2">
The text in this document follows Jouni's suggestions.
</t>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
<name slugifiedName="name-authors-address">Author's Address</name>
<author initials="A." surname="DeKok" fullname="Alan DeKok">
<organization abbrev="FreeRADIUS" showOnFrontPage="true">The FreeRADIUS Server Project</organization>
<address>
<email>aland@freeradius.org</email>
</address>
</author>
</section>
</back>
</rfc>
|
