-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathdraft-ietf-emu-rfc5448bis-01.txt
1904 lines (1259 loc) · 74.7 KB
/
draft-ietf-emu-rfc5448bis-01.txt
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
Network Working Group J. Arkko
Internet-Draft V. Lehtovirta
Obsoletes: 5448 (if approved) V. Torvinen
Updates: 4187 (if approved) Ericsson
Intended status: Informational P. Eronen
Expires: January 3, 2019 Nokia
July 2, 2018
Improved Extensible Authentication Protocol Method for 3rd Generation
Authentication and Key Agreement (EAP-AKA')
draft-ietf-emu-rfc5448bis-01
Abstract
This specification defines a new EAP method, EAP-AKA', a small
revision of the EAP-AKA method. The change is a new key derivation
function that binds the keys derived within the method to the name of
the access network. The new key derivation mechanism has been
defined in the 3rd Generation Partnership Project (3GPP). This
specification allows its use in EAP in an interoperable manner. In
addition, EAP-AKA' employs SHA-256 instead of SHA-1.
This specification also updates RFC 4187 EAP-AKA to prevent bidding
down attacks from EAP-AKA'.
This version of the EAP-AKA' specification updates a reference to
constructing one field in the protocol, so that EAP-AKA' becomes
compatible with 5G deployments as well.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 3, 2019.
Arkko, et al. Expires January 3, 2019 [Page 1]
Internet-Draft EAP-AKA' July 2018
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. EAP-AKA' . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. AT_KDF_INPUT . . . . . . . . . . . . . . . . . . . . . . 7
3.2. AT_KDF . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Key Generation . . . . . . . . . . . . . . . . . . . . . 12
3.4. Hash Functions . . . . . . . . . . . . . . . . . . . . . 14
3.4.1. PRF' . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.2. AT_MAC . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.3. AT_CHECKCODE . . . . . . . . . . . . . . . . . . . . 14
4. Bidding Down Prevention for EAP-AKA . . . . . . . . . . . . . 15
5. Identifier Usage in 5G . . . . . . . . . . . . . . . . . . . 16
5.1. Key Derivation . . . . . . . . . . . . . . . . . . . . . 17
5.2. EAP Identity Response and EAP-AKA' AT_IDENTITY Attribute 18
6. Exported Parameters . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7.1. Security Properties of Binding Network Names . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8.1. Type Value . . . . . . . . . . . . . . . . . . . . . . . 23
8.2. Attribute Type Values . . . . . . . . . . . . . . . . . . 23
8.3. Key Derivation Function Namespace . . . . . . . . . . . . 23
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Changes from RFC 5448 . . . . . . . . . . . . . . . 27
Appendix B. Changes from RFC 4187 to RFC 5448 . . . . . . . . . 27
Appendix C. Changes from Previous Version of This Draft . . . . 28
Appendix D. Importance of Explicit Negotiation . . . . . . . . . 28
Appendix E. Test Vectors . . . . . . . . . . . . . . . . . . . . 29
Arkko, et al. Expires January 3, 2019 [Page 2]
Internet-Draft EAP-AKA' July 2018
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction
This specification defines a new Extensible Authentication Protocol
(EAP)[RFC3748] method, EAP-AKA', a small revision of the EAP-AKA
method originally defined in [RFC4187]. What is new in EAP-AKA' is
that it has a new key derivation function, specified in
[TS-3GPP.33.402]. This function binds the keys derived within the
method to the name of the access network. This limits the effects of
compromised access network nodes and keys. This specification
defines the EAP encapsulation for AKA when the new key derivation
mechanism is in use.
3GPP has defined a number of applications for the revised AKA
mechanism, some based on native encapsulation of AKA over 3GPP radio
access networks and others based on the use of EAP.
For making the new key derivation mechanisms usable in EAP-AKA,
additional protocol mechanisms are necessary. Given that RFC 4187
calls for the use of CK (the encryption key) and IK (the integrity
key) from AKA, existing implementations continue to use these. Any
change of the key derivation must be unambiguous to both sides in the
protocol. That is, it must not be possible to accidentally connect
old equipment to new equipment and get the key derivation wrong or
attempt to use wrong keys without getting a proper error message.
The change must also be secure against bidding down attacks that
attempt to force the participants to use the least secure mechanism.
This specification therefore introduces a variant of the EAP-AKA
method, called EAP-AKA'. This method can employ the derived keys CK'
and IK' from the 3GPP specification and updates the used hash
function to SHA-256 [FIPS.180-4]. But it is otherwise equivalent to
RFC 4187. Given that a different EAP method type value is used for
EAP-AKA and EAP-AKA', a mutually supported method may be negotiated
using the standard mechanisms in EAP [RFC3748].
Note: Appendix D explains why it is important to be explicit about
the change of semantics for the keys, and why other approaches
would lead to severe interoperability problems.
This version of the EAP-AKA' specification obsoletes RFC 5448. The
changes consist of three things:
o Update the reference on how the Network Name field is constructed
in the protocol. The update helps ensure that EAP-AKA' becomes
compatible with 5G deployments as well. RFC 5448 referred to the
Arkko, et al. Expires January 3, 2019 [Page 3]
Internet-Draft EAP-AKA' July 2018
Release 8 version of [TS-3GPP.24.302] and this update points to
the first 5G version, Release 15.
o Specify how EAP and EAP-AKA' use identifiers in 5G, as additional
identifiers are introduced, and for interoperability, it is
important that implementations use the right ones.
o Specify session identifiers and other exported parameters, as
those were not specified in [RFC5448] despite requirements set
forward in [RFC5247] to do so. Also, while [RFC5247] specified
session identifiers for EAP-AKA, it only did so for the full
authentication case, not for the case of fast re-authentication.
Arguably, the updates are small. For the first update, the 3GPP
specification number for the updated calculation has not changed,
only the version. But this reference is crucial in correct
calculation of the keys resulting from running the EAP-AKA' method,
so an update of the RFC with the newest version pointer may be
warranted. As always, feedback is welcome on that point as well as
on any other topic within this document.
Note: It is an open issue whether this update should refer to only
the 5G version of the definition, or be explicit that any further
update of that specification is something that EAP-AKA'
implementations should take into account. Note that one should
keep in mind that specification being automatically updated is
different from implementations taking notice of new things.
The second update is needed to ensure that implementations use the
correct identifiers in the context of 5G, as it introduces additional
privacy-protected identifiers, and it is no longer clear which
identifiers are used in EAP-AKA'.
The third update is necessary in order to fix a problem in previous
RFCs.
It is an explicit non-goal of this draft to include any other
technical modifications, addition of new features or other changes.
The EAP-AKA' base protocol is stable and needs to stay that way. If
there are any extensions or variants, those need to be proposed as
standalone extensions or even as different authentication methods.
The rest of this specification is structured as follows. Section 3
defines the EAP-AKA' method. Section 4 adds support to EAP-AKA to
prevent bidding down attacks from EAP-AKA'. Section 7 explains the
security differences between EAP-AKA and EAP-AKA'. Section 8
describes the IANA considerations and Appendix A and Appendix B
explains what updates to RFC 5448 AKA' and RFC 4187 EAP-AKA have been
Arkko, et al. Expires January 3, 2019 [Page 4]
Internet-Draft EAP-AKA' July 2018
made in this specification. Appendix D explains some of the design
rationale for creating EAP-AKA' Finally, Appendix E provides test
vectors.
Editor's Note: The publication of this RFC depends on its
normative references [TS-3GPP.24.302] and [TS-3GPP.33.501]
reaching a stable status for Release 15, as indicated by 3GPP.
This is expected to happen shortly. The RFC Editor should check
with the 3GPP liaisons that this has happened. RFC Editor: Please
delete this note upon publication of this specification as an RFC.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. EAP-AKA'
EAP-AKA' is a new EAP method that follows the EAP-AKA specification
[RFC4187] in all respects except the following:
o It uses the Type code 50, not 23 (which is used by EAP-AKA).
o It carries the AT_KDF_INPUT attribute, as defined in Section 3.1,
to ensure that both the peer and server know the name of the
access network.
o It supports key derivation function negotiation via the AT_KDF
attribute (Section 3.2) to allow for future extensions.
o It calculates keys as defined in Section 3.3, not as defined in
EAP-AKA.
o It employs SHA-256, not SHA-1 [FIPS.180-4] (Section 3.4).
Figure 1 shows an example of the authentication process. Each
message AKA'-Challenge and so on represents the corresponding message
from EAP-AKA, but with EAP-AKA' Type code. The definition of these
messages, along with the definition of attributes AT_RAND, AT_AUTN,
AT_MAC, and AT_RES can be found in [RFC4187].
Arkko, et al. Expires January 3, 2019 [Page 5]
Internet-Draft EAP-AKA' July 2018
Peer Server
| EAP-Request/Identity |
|<-------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes user's Network Access Identifier, NAI) |
|------------------------------------------------------->|
| +--------------------------------------------------+
| | Server determines the network name and ensures |
| | that the given access network is authorized to |
| | use the claimed name. The server then runs the |
| | AKA' algorithms generating RAND and AUTN, and |
| | derives session keys from CK' and IK'. RAND and |
| | AUTN are sent as AT_RAND and AT_AUTN attributes, |
| | whereas the network name is transported in the |
| | AT_KDF_INPUT attribute. AT_KDF signals the used |
| | key derivation function. The session keys are |
| | used in creating the AT_MAC attribute. |
| +--------------------------------------------------+
| EAP-Request/AKA'-Challenge |
| (AT_RAND, AT_AUTN, AT_KDF, AT_KDF_INPUT, AT_MAC)|
|<-------------------------------------------------------|
+------------------------------------------------------+ |
| The peer determines what the network name should be, | |
| based on, e.g., what access technology it is using. | |
| The peer also retrieves the network name sent by | |
| the network from the AT_KDF_INPUT attribute. The | |
| two names are compared for discrepancies, and if | |
| necessary, the authentication is aborted. Otherwise,| |
| the network name from AT_KDF_INPUT attribute is | |
| used in running the AKA' algorithms, verifying AUTN | |
| from AT_AUTN and MAC from AT_MAC attributes. The | |
| peer then generates RES. The peer also derives | |
| session keys from CK'/IK'. The AT_RES and AT_MAC | |
| attributes are constructed. | |
+------------------------------------------------------+ |
| EAP-Response/AKA'-Challenge |
| (AT_RES, AT_MAC) |
|------------------------------------------------------->|
| +-------------------------------------------------+
| | Server checks the RES and MAC values received |
| | in AT_RES and AT_MAC, respectively. Success |
| | requires both to be found correct. |
| +-------------------------------------------------+
| EAP-Success |
|<-------------------------------------------------------|
Figure 1: EAP-AKA' Authentication Process
Arkko, et al. Expires January 3, 2019 [Page 6]
Internet-Draft EAP-AKA' July 2018
EAP-AKA' can operate on the same credentials as EAP-AKA and employ
the same identities. However, EAP-AKA' employs different leading
characters than EAP-AKA for the conventions given in Section 4.1.1 of
[RFC4187] for International Mobile Subscriber Identifier (IMSI) based
usernames. EAP-AKA' MUST use the leading character "6" (ASCII 36
hexadecimal) instead of "0" for IMSI-based permanent usernames. All
other usage and processing of the leading characters, usernames, and
identities is as defined by EAP-AKA [RFC4187]. For instance, the
pseudonym and fast re-authentication usernames need to be constructed
so that the server can recognize them. As an example, a pseudonym
could begin with a leading "7" character (ASCII 37 hexadecimal) and a
fast re-authentication username could begin with "8" (ASCII 38
hexadecimal). Note that a server that implements only EAP-AKA may
not recognize these leading characters. According to Section 4.1.4
of [RFC4187], such a server will re-request the identity via the EAP-
Request/AKA-Identity message, making obvious to the peer that EAP-AKA
and associated identity are expected.
3.1. AT_KDF_INPUT
The format of the AT_KDF_INPUT attribute is shown below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_KDF_INPUT | Length | Actual Network Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Network Name .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are as follows:
AT_KDF_INPUT
This is set to 23.
Length
The length of the attribute, calculated as defined in [RFC4187],
Section 8.1.
Actual Network Name Length
Arkko, et al. Expires January 3, 2019 [Page 7]
Internet-Draft EAP-AKA' July 2018
This is a 2 byte actual length field, needed due to the
requirement that the previous field is expressed in multiples of 4
bytes per the usual EAP-AKA rules. The Actual Network Name Length
field provides the length of the network name in bytes.
Network Name
This field contains the network name of the access network for
which the authentication is being performed. The name does not
include any terminating null characters. Because the length of
the entire attribute must be a multiple of 4 bytes, the sender
pads the name with 1, 2, or 3 bytes of all zero bits when
necessary.
Only the server sends the AT_KDF_INPUT attribute. The value is sent
as specified in [TS-3GPP.24.302] for non-3GPP access networks, and as
specified in [TS-3GPP.33.501] for 5G access networks. Per
[TS-3GPP.33.402], the server always verifies the authorization of a
given access network to use a particular name before sending it to
the peer over EAP-AKA'. The value of the AT_KDF_INPUT attribute from
the server MUST be non-empty. If it is empty, the peer behaves as if
AUTN had been incorrect and authentication fails. See Section 3 and
Figure 3 of [RFC4187] for an overview of how authentication failures
are handled.
Note: Currently, [TS-3GPP.24.302] or [TS-3GPP.33.501] specify
separate values. The former specifies what is called "Access
Network ID" and the latter specifies what is called "Serving
Network Name". However, from an EAP-AKA' perspective both occupy
the same field, and need to be distinghuishable from each other.
Currently specified values are distinguishable, but it would be
useful that this be specified explicitly in the 3GPP
specifications.
In addition, the peer MAY check the received value against its own
understanding of the network name. Upon detecting a discrepancy, the
peer either warns the user and continues, or fails the authentication
process. More specifically, the peer SHOULD have a configurable
policy that it can follow under these circumstances. If the policy
indicates that it can continue, the peer SHOULD log a warning message
or display it to the user. If the peer chooses to proceed, it MUST
use the network name as received in the AT_KDF_INPUT attribute. If
the policy indicates that the authentication should fail, the peer
behaves as if AUTN had been incorrect and authentication fails.
The Network Name field contains a UTF-8 string. This string MUST be
constructed as specified in [TS-3GPP.24.302] for "Access Network
Identity". The string is structured as fields separated by colons
Arkko, et al. Expires January 3, 2019 [Page 8]
Internet-Draft EAP-AKA' July 2018
(:). The algorithms and mechanisms to construct the identity string
depend on the used access technology.
On the network side, the network name construction is a configuration
issue in an access network and an authorization check in the
authentication server. On the peer, the network name is constructed
based on the local observations. For instance, the peer knows which
access technology it is using on the link, it can see information in
a link-layer beacon, and so on. The construction rules specify how
this information maps to an access network name. Typically, the
network name consists of the name of the access technology, or the
name of the access technology followed by some operator identifier
that was advertised in a link-layer beacon. In all cases,
[TS-3GPP.24.302] is the normative specification for the construction
in both the network and peer side. If the peer policy allows running
EAP-AKA' over an access technology for which that specification does
not provide network name construction rules, the peer SHOULD rely
only on the information from the AT_KDF_INPUT attribute and not
perform a comparison.
If a comparison of the locally determined network name and the one
received over EAP-AKA' is performed on the peer, it MUST be done as
follows. First, each name is broken down to the fields separated by
colons. If one of the names has more colons and fields than the
other one, the additional fields are ignored. The remaining
sequences of fields are compared, and they match only if they are
equal character by character. This algorithm allows a prefix match
where the peer would be able to match "", "FOO", and "FOO:BAR"
against the value "FOO:BAR" received from the server. This
capability is important in order to allow possible updates to the
specifications that dictate how the network names are constructed.
For instance, if a peer knows that it is running on access technology
"FOO", it can use the string "FOO" even if the server uses an
additional, more accurate description, e.g., "FOO:BAR", that contains
more information.
The allocation procedures in [TS-3GPP.24.302] ensure that conflicts
potentially arising from using the same name in different types of
networks are avoided. The specification also has detailed rules
about how a client can determine these based on information available
to the client, such as the type of protocol used to attach to the
network, beacons sent out by the network, and so on. Information
that the client cannot directly observe (such as the type or version
of the home network) is not used by this algorithm.
The AT_KDF_INPUT attribute MUST be sent and processed as explained
above when AT_KDF attribute has the value 1. Future definitions of
Arkko, et al. Expires January 3, 2019 [Page 9]
Internet-Draft EAP-AKA' July 2018
new AT_KDF values MUST define how this attribute is sent and
processed.
3.2. AT_KDF
AT_KDF is an attribute that the server uses to reference a specific
key derivation function. It offers a negotiation capability that can
be useful for future evolution of the key derivation functions.
The format of the AT_KDF attribute is shown below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_KDF | Length | Key Derivation Function |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are as follows:
AT_KDF
This is set to 24.
Length
The length of the attribute, MUST be set to 1.
Key Derivation Function
An enumerated value representing the key derivation function that
the server (or peer) wishes to use. Value 1 represents the
default key derivation function for EAP-AKA', i.e., employing CK'
and IK' as defined in Section 3.3.
Servers MUST send one or more AT_KDF attributes in the EAP-Request/
AKA'-Challenge message. These attributes represent the desired
functions ordered by preference, the most preferred function being
the first attribute.
Upon receiving a set of these attributes, if the peer supports and is
willing to use the key derivation function indicated by the first
attribute, the function is taken into use without any further
negotiation. However, if the peer does not support this function or
is unwilling to use it, it does not process the received EAP-Request/
AKA'-Challenge in any way except by responding with the EAP-Response/
AKA'-Challenge message that contains only one attribute, AT_KDF with
the value set to the selected alternative. If there is no suitable
Arkko, et al. Expires January 3, 2019 [Page 10]
Internet-Draft EAP-AKA' July 2018
alternative, the peer behaves as if AUTN had been incorrect and
authentication fails (see Figure 3 of [RFC4187]). The peer fails the
authentication also if there are any duplicate values within the list
of AT_KDF attributes (except where the duplication is due to a
request to change the key derivation function; see below for further
information).
Upon receiving an EAP-Response/AKA'-Challenge with AT_KDF from the
peer, the server checks that the suggested AT_KDF value was one of
the alternatives in its offer. The first AT_KDF value in the message
from the server is not a valid alternative. If the peer has replied
with the first AT_KDF value, the server behaves as if AT_MAC of the
response had been incorrect and fails the authentication. For an
overview of the failed authentication process in the server side, see
Section 3 and Figure 2 of [RFC4187]. Otherwise, the server re-sends
the EAP-Response/AKA'-Challenge message, but adds the selected
alternative to the beginning of the list of AT_KDF attributes and
retains the entire list following it. Note that this means that the
selected alternative appears twice in the set of AT_KDF values.
Responding to the peer's request to change the key derivation
function is the only legal situation where such duplication may
occur.
When the peer receives the new EAP-Request/AKA'-Challenge message, it
MUST check that the requested change, and only the requested change,
occurred in the list of AT_KDF attributes. If so, it continues with
processing the received EAP-Request/AKA'-Challenge as specified in
[RFC4187] and Section 3.1 of this document. If not, it behaves as if
AT_MAC had been incorrect and fails the authentication. If the peer
receives multiple EAP-Request/AKA'-Challenge messages with differing
AT_KDF attributes without having requested negotiation, the peer MUST
behave as if AT_MAC had been incorrect and fail the authentication.
Note that the peer may also request sequence number resynchronization
[RFC4187]. This happens after AT_KDF negotiation has already
completed. An AKA'-Synchronization-Failure message is sent as a
response to the newly received EAP-Request/AKA'-Challenge (the last
message of the AT_KDF negotiation). The AKA'-Synchronization-Failure
message MUST contain the AUTS parameter as specified in [RFC4187] and
a copy the AT_KDF attributes as they appeared in the last message of
the AT_KDF negotiation. If the AT_KDF attributes are found to differ
from their earlier values, the peer and server MUST behave as if
AT_MAC had been incorrect and fail the authentication.
Arkko, et al. Expires January 3, 2019 [Page 11]
Internet-Draft EAP-AKA' July 2018
3.3. Key Generation
Both the peer and server MUST derive the keys as follows.
AT_KDF set to 1
In this case, MK is derived and used as follows:
MK = PRF'(IK'|CK',"EAP-AKA'"|Identity)
K_encr = MK[0..127]
K_aut = MK[128..383]
K_re = MK[384..639]
MSK = MK[640..1151]
EMSK = MK[1152..1663]
Here [n..m] denotes the substring from bit n to m. PRF' is a new
pseudo-random function specified in Section 3.4. The first 1664
bits from its output are used for K_encr (encryption key, 128
bits), K_aut (authentication key, 256 bits), K_re (re-
authentication key, 256 bits), MSK (Master Session Key, 512 bits),
and EMSK (Extended Master Session Key, 512 bits). These keys are
used by the subsequent EAP-AKA' process. K_encr is used by the
AT_ENCR_DATA attribute, and K_aut by the AT_MAC attribute. K_re
is used later in this section. MSK and EMSK are outputs from a
successful EAP method run [RFC3748].
IK' and CK' are derived as specified in [TS-3GPP.33.402]. The
functions that derive IK' and CK' take the following parameters:
CK and IK produced by the AKA algorithm, and value of the Network
Name field comes from the AT_KDF_INPUT attribute (without length
or padding) .
The value "EAP-AKA'" is an eight-characters-long ASCII string. It
is used as is, without any trailing NUL characters.
Identity is the peer identity as specified in Section 7 of
[RFC4187].
When the server creates an AKA challenge and corresponding AUTN,
CK, CK', IK, and IK' values, it MUST set the Authentication
Management Field (AMF) separation bit to 1 in the AKA algorithm
[TS-3GPP.33.102]. Similarly, the peer MUST check that the AMF
separation bit is set to 1. If the bit is not set to 1, the peer
behaves as if the AUTN had been incorrect and fails the
authentication.
Arkko, et al. Expires January 3, 2019 [Page 12]
Internet-Draft EAP-AKA' July 2018
On fast re-authentication, the following keys are calculated:
MK = PRF'(K_re,"EAP-AKA' re-auth"|Identity|counter|NONCE_S)
MSK = MK[0..511]
EMSK = MK[512..1023]
MSK and EMSK are the resulting 512-bit keys, taking the first 1024
bits from the result of PRF'. Note that K_encr and K_aut are not
re-derived on fast re-authentication. K_re is the re-
authentication key from the preceding full authentication and
stays unchanged over any fast re-authentication(s) that may happen
based on it. The value "EAP-AKA' re-auth" is a sixteen-
characters-long ASCII string, again represented without any
trailing NUL characters. Identity is the fast re-authentication
identity, counter is the value from the AT_COUNTER attribute,
NONCE_S is the nonce value from the AT_NONCE_S attribute, all as
specified in Section 7 of [RFC4187]. To prevent the use of
compromised keys in other places, it is forbidden to change the
network name when going from the full to the fast re-
authentication process. The peer SHOULD NOT attempt fast re-
authentication when it knows that the network name in the current
access network is different from the one in the initial, full
authentication. Upon seeing a re-authentication request with a
changed network name, the server SHOULD behave as if the re-
authentication identifier had been unrecognized, and fall back to
full authentication. The server observes the change in the name
by comparing where the fast re-authentication and full
authentication EAP transactions were received at the
Authentication, Authorization, and Accounting (AAA) protocol
level.
AT_KDF has any other value
Future variations of key derivation functions may be defined, and
they will be represented by new values of AT_KDF. If the peer
does not recognize the value, it cannot calculate the keys and
behaves as explained in Section 3.2.
AT_KDF is missing
The peer behaves as if the AUTN had been incorrect and MUST fail
the authentication.
If the peer supports a given key derivation function but is unwilling
to perform it for policy reasons, it refuses to calculate the keys
and behaves as explained in Section 3.2.
Arkko, et al. Expires January 3, 2019 [Page 13]
Internet-Draft EAP-AKA' July 2018
3.4. Hash Functions
EAP-AKA' uses SHA-256, not SHA-1 (see [FIPS.180-4]) as in EAP-AKA.
This requires a change to the pseudo-random function (PRF) as well as
the AT_MAC and AT_CHECKCODE attributes.
3.4.1. PRF'
The PRF' construction is the same one IKEv2 uses (see Section 2.13 of
[RFC4306]). The function takes two arguments. K is a 256-bit value
and S is an octet string of arbitrary length. PRF' is defined as
follows:
PRF'(K,S) = T1 | T2 | T3 | T4 | ...
where:
T1 = HMAC-SHA-256 (K, S | 0x01)
T2 = HMAC-SHA-256 (K, T1 | S | 0x02)
T3 = HMAC-SHA-256 (K, T2 | S | 0x03)
T4 = HMAC-SHA-256 (K, T3 | S | 0x04)
...
PRF' produces as many bits of output as is needed. HMAC-SHA-256 is
the application of HMAC [RFC2104] to SHA-256.
3.4.2. AT_MAC
When used within EAP-AKA', the AT_MAC attribute is changed as
follows. The MAC algorithm is HMAC-SHA-256-128, a keyed hash value.
The HMAC-SHA-256-128 value is obtained from the 32-byte HMAC-SHA-256
value by truncating the output to the first 16 bytes. Hence, the
length of the MAC is 16 bytes.
Otherwise, the use of AT_MAC in EAP-AKA' follows Section 10.15 of
[RFC4187].
3.4.3. AT_CHECKCODE
When used within EAP-AKA', the AT_CHECKCODE attribute is changed as
follows. First, a 32-byte value is needed to accommodate a 256-bit
hash output:
Arkko, et al. Expires January 3, 2019 [Page 14]
Internet-Draft EAP-AKA' July 2018
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_CHECKCODE | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Checkcode (0 or 32 bytes) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Second, the checkcode is a hash value, calculated with SHA-256
[FIPS.180-4], over the data specified in Section 10.13 of [RFC4187].
4. Bidding Down Prevention for EAP-AKA
As discussed in [RFC3748], negotiation of methods within EAP is
insecure. That is, a man-in-the-middle attacker may force the
endpoints to use a method that is not the strongest that they both
support. This is a problem, as we expect EAP-AKA and EAP-AKA' to be
negotiated via EAP.
In order to prevent such attacks, this RFC specifies a new mechanism
for EAP-AKA that allows the endpoints to securely discover the
capabilities of each other. This mechanism comes in the form of the
AT_BIDDING attribute. This allows both endpoints to communicate
their desire and support for EAP-AKA' when exchanging EAP-AKA
messages. This attribute is not included in EAP-AKA' messages as
defined in this RFC. It is only included in EAP-AKA messages. This
is based on the assumption that EAP-AKA' is always preferable (see
Section 7). If during the EAP-AKA authentication process it is
discovered that both endpoints would have been able to use EAP-AKA',
the authentication process SHOULD be aborted, as a bidding down
attack may have happened.
The format of the AT_BIDDING attribute is shown below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_BIDDING | Length |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are as follows:
AT_BIDDING
Arkko, et al. Expires January 3, 2019 [Page 15]
Internet-Draft EAP-AKA' July 2018
This is set to 136.
Length
The length of the attribute, MUST be set to 1.
D
This bit is set to 1 if the sender supports EAP-AKA', is willing
to use it, and prefers it over EAP-AKA. Otherwise, it should be
set to zero.
Reserved
This field MUST be set to zero when sent and ignored on receipt.
The server sends this attribute in the EAP-Request/AKA-Challenge
message. If the peer supports EAP-AKA', it compares the received
value to its own capabilities. If it turns out that both the server
and peer would have been able to use EAP-AKA' and preferred it over
EAP-AKA, the peer behaves as if AUTN had been incorrect and fails the
authentication (see Figure 3 of [RFC4187]). A peer not supporting
EAP-AKA' will simply ignore this attribute. In all cases, the
attribute is protected by the integrity mechanisms of EAP-AKA, so it
cannot be removed by a man-in-the-middle attacker.
Note that we assume (Section 7) that EAP-AKA' is always stronger than
EAP-AKA. As a result, there is no need to prevent bidding "down"
attacks in the other direction, i.e., attackers forcing the endpoints
to use EAP-AKA'.
5. Identifier Usage in 5G
In EAP-AKA', the peer identity may be communicated to the server in
one of three ways:
o As a part of link layer establishment procedures, externally to
EAP.
o With the EAP-Response/Identity message in the beginning of the EAP
exchange, but before the selection of EAP-AKA'.
o Transmitted from the peer to the server using EAP-AKA messages
instead of EAP-Response/Identity. In this case, the server
includes an identity requesting attribute (AT_ANY_ID_REQ,
AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ) in the EAP-Request/AKA-
Identity message; and the peer includes the AT_IDENTITY attribute,
Arkko, et al. Expires January 3, 2019 [Page 16]
Internet-Draft EAP-AKA' July 2018
which contains the peer's identity, in the EAP-Response/AKA-
Identity message.
The identity carried above may be a permanent identity or a pseudonym
identity or fast re-authentication identity as defined in this RFC.
In networks where EAP is the only part handling such pseudonym or
fast re-authentication identities, this usage is clear. However, 5G
supports the concept of pseudonym or privacy identifiers, and it is
important for interoperability that the right type of identifiers are
used in the right place.
5G defines the SUbscription Permanent Identifier (SUPI) and
SUbscription Concealed Identifier (SUCI) [TS-3GPP.23.501]
[TS-3GPP.33.501]. SUPI is globally unique and allocated to each
subscriber. However, it is only used internally in the 5G network,
and is privacy sensitive. The SUCI is a privacy preserving
identifier containing the concealed SUPI, using public key
cryptography to encrypt the SUPI.
Given the choice between these two types of identifiers, two areas
need further specification in EAP-AKA' to ensure that different
implementations understand each other and stay interoperable:
o Where identifiers are used within EAP-AKA' -- such as key
derivation -- specify what values exactly should be used, to avoid
ambiguity.
o Where identifiers are carried within EAP-AKA' packets -- such as
in the AT_IDENTITY attribute -- specify which identifiers should
be filled in.
In 5G, the normal mode of operation is that identifiers are only
transmitted outside EAP. However, in a system involving terminals
from many generations and several connectivity options via 5G and
other mechanisms, implementations and the EAP-AKA' specification need
to prepare for many different situations, including sometimes having
to communicate identities within EAP.
The following sections clarify which identifiers are used and how.
5.1. Key Derivation
In EAP-AKA', the peer identity is used in the Section 3.3 key
derivation formula.
If the AT_KDF_INPUT parameter contains the prefix "5G:", the AT_KDF
parameter has the value 1, and this authentication is not a fast re-
Arkko, et al. Expires January 3, 2019 [Page 17]
Internet-Draft EAP-AKA' July 2018
authentication, then the peer identity used in the key derivation
MUST be the 5G SUPI for the peer. This rule applies to all full EAP-
AKA' authentication processes, even if the peer sent some other
identifier at a lower layer or as a response to an EAP Identity
Request or if no identity was sent.
In all other cases, the following applies:
The identity used in the key derivation formula MUST be exactly
the one sent in EAP-AKA' AT_IDENTITY attribute, if one was sent,
regardless of the kind of identity that it may have been. If no
AT_IDENTITY was sent, the identity MUST be the exactly the one
sent in the generic EAP Identity exchange, if one was made.
Again, the identity MUST be used exactly as sent.
If no identity was communicated inside EAP, then the identity is
the one communicated outside EAP in link layer messaging.
In this case, the used identity MUST be the identity most recently
communicated by the peer to the network, again regardless of what
type of identity it may have been.
5.2. EAP Identity Response and EAP-AKA' AT_IDENTITY Attribute
The EAP authentication option is only available in 5G when the new 5G
core network is also in use. However, in other networks an EAP-AKA'
peer may be connecting to other types of networks and existing
equipment.
When the EAP peer is connecting to a 5G access network and uses the
5G core network signalling mechanisms, it can assume that the EAP
server is in a 5G network. The EAP level identity exchanges are not
generally used in this case, but if there is, the EAP peer SHOULD
employ only the privacy preserving SUCI identifier within EAP (either
in EAP Identity Response or EAP-AKA' AT_IDENTITY attribute).
Similarly, if the peer is explicitly communicating through mechanisms
developed for 5G to connect to 5G networks over WLAN, it MUST assume
that the EAP server is in a 5G network, and again employ the SUCI
within EAP.
Otherwise, the peer SHOULD employ IMSI, SUPI, or a NAI as it is
configured to use.