Add compile option to disable internal handling of fatal signals
[strongswan.git] / doc / standards / rfc4187.txt
1
2
3
4
5
6
7 Network Working Group                                           J. Arkko
8 Request for Comments: 4187                                      Ericsson
9 Category: Informational                                     H. Haverinen
10                                                                    Nokia
11                                                             January 2006
12
13
14       Extensible Authentication Protocol Method for 3rd Generation
15                Authentication and Key Agreement (EAP-AKA)
16
17 Status of This Memo
18
19    This memo provides information for the Internet community.  It does
20    not specify an Internet standard of any kind.  Distribution of this
21    memo is unlimited.
22
23 Copyright Notice
24
25    Copyright (C) The Internet Society (2006).
26
27 IESG Note
28
29    The EAP-AKA protocol was developed by 3GPP.  The documentation of
30    EAP-AKA is provided as information to the Internet community.  While
31    the EAP WG has verified that EAP-AKA is compatible with EAP as
32    defined in RFC 3748, no other review has been done, including
33    validation of the security claims.  The IETF has also not reviewed
34    the security of the underlying UMTS AKA algorithms.
35
36 Abstract
37
38    This document specifies an Extensible Authentication Protocol (EAP)
39    mechanism for authentication and session key distribution that uses
40    the Authentication and Key Agreement (AKA) mechanism.  AKA is used in
41    the 3rd generation mobile networks Universal Mobile
42    Telecommunications System (UMTS) and CDMA2000.  AKA is based on
43    symmetric keys, and typically runs in a Subscriber Identity Module,
44    which is a UMTS Subscriber Identity Module, USIM, or a (Removable)
45    User Identity Module, (R)UIM, similar to a smart card.
46
47    EAP-AKA includes optional identity privacy support, optional result
48    indications, and an optional fast re-authentication procedure.
49
50
51
52
53
54
55
56
57
58 Arkko & Haverinen            Informational                      [Page 1]
59 \f
60 RFC 4187                 EAP-AKA Authentication             January 2006
61
62
63 Table of Contents
64
65    1. Introduction and Motivation .....................................4
66    2. Terms and Conventions Used in This Document .....................5
67    3. Protocol Overview ...............................................9
68    4. Operation ......................................................15
69       4.1. Identity Management .......................................15
70            4.1.1. Format, Generation, and Usage of Peer Identities ...15
71            4.1.2. Communicating the Peer Identity to the Server ......21
72            4.1.3. Choice of Identity for the EAP-Response/Identity ...23
73            4.1.4. Server Operation in the Beginning of
74                   EAP-AKA Exchange ...................................23
75            4.1.5. Processing of EAP-Request/AKA-Identity by
76                   the Peer ...........................................24
77            4.1.6. Attacks against Identity Privacy ...................25
78            4.1.7. Processing of AT_IDENTITY by the Server ............26
79       4.2. Message Sequence Examples (Informative) ...................27
80            4.2.1. Usage of AT_ANY_ID_REQ .............................27
81            4.2.2. Fall Back on Full Authentication ...................28
82            4.2.3. Requesting the Permanent Identity 1 ................29
83            4.2.4. Requesting the Permanent Identity 2 ................30
84            4.2.5. Three EAP/AKA-Identity Round Trips .................30
85    5. Fast Re-Authentication .........................................32
86       5.1. General ...................................................32
87       5.2. Comparison to AKA .........................................33
88       5.3. Fast Re-Authentication Identity ...........................33
89       5.4. Fast Re-Authentication Procedure ..........................35
90       5.5. Fast Re-Authentication Procedure when Counter is
91            Too Small .................................................37
92    6. EAP-AKA Notifications ..........................................38
93       6.1. General ...................................................38
94       6.2. Result Indications ........................................39
95       6.3. Error Cases ...............................................40
96            6.3.1. Peer Operation .....................................41
97            6.3.2. Server Operation ...................................41
98            6.3.3. EAP-Failure ........................................42
99            6.3.4. EAP-Success ........................................42
100    7. Key Generation .................................................43
101    8. Message Format and Protocol Extensibility ......................45
102       8.1. Message Format ............................................45
103       8.2. Protocol Extensibility ....................................47
104    9. Messages .......................................................48
105       9.1. EAP-Request/AKA-Identity ..................................48
106       9.2. EAP-Response/AKA-Identity .................................48
107       9.3. EAP-Request/AKA-Challenge .................................49
108       9.4. EAP-Response/AKA-Challenge ................................49
109       9.5. EAP-Response/AKA-Authentication-Reject ....................50
110       9.6. EAP-Response/AKA-Synchronization-Failure ..................50
111
112
113
114 Arkko & Haverinen            Informational                      [Page 2]
115 \f
116 RFC 4187                 EAP-AKA Authentication             January 2006
117
118
119       9.7. EAP-Request/AKA-Reauthentication ..........................50
120       9.8. EAP-Response/AKA-Reauthentication .........................51
121       9.9. EAP-Response/AKA-Client-Error .............................52
122       9.10. EAP-Request/AKA-Notification .............................52
123       9.11. EAP-Response/AKA-Notification ............................52
124    10. Attributes ....................................................53
125       10.1. Table of Attributes ......................................53
126       10.2. AT_PERMANENT_ID_REQ ......................................54
127       10.3. AT_ANY_ID_REQ ............................................54
128       10.4. AT_FULLAUTH_ID_REQ .......................................54
129       10.5. AT_IDENTITY ..............................................55
130       10.6. AT_RAND ..................................................55
131       10.7. AT_AUTN ..................................................56
132       10.8. AT_RES ...................................................56
133       10.9. AT_AUTS ..................................................57
134       10.10. AT_NEXT_PSEUDONYM .......................................57
135       10.11. AT_NEXT_REAUTH_ID .......................................58
136       10.12. AT_IV, AT_ENCR_DATA, and AT_PADDING .....................58
137       10.13. AT_CHECKCODE ............................................60
138       10.14. AT_RESULT_IND ...........................................62
139       10.15. AT_MAC ..................................................63
140       10.16. AT_COUNTER ..............................................64
141       10.17. AT_COUNTER_TOO_SMALL ....................................64
142       10.18. AT_NONCE_S ..............................................65
143       10.19. AT_NOTIFICATION .........................................65
144       10.20. AT_CLIENT_ERROR_CODE ....................................66
145    11. IANA and Protocol Numbering Considerations ....................66
146    12. Security Considerations .......................................68
147       12.1. Identity Protection ......................................69
148       12.2. Mutual Authentication ....................................69
149       12.3. Flooding the Authentication Centre .......................69
150       12.4. Key Derivation ...........................................70
151       12.5. Brute-Force and Dictionary Attacks .......................70
152       12.6. Protection, Replay Protection, and Confidentiality .......70
153       12.7. Negotiation Attacks ......................................71
154       12.8. Protected Result Indications .............................72
155       12.9. Man-in-the-Middle Attacks ................................72
156       12.10. Generating Random Numbers ...............................73
157    13. Security Claims ...............................................73
158    14. Acknowledgements and Contributions ............................74
159    15. References ....................................................74
160       15.1. Normative References .....................................74
161       15.2. Informative References ...................................76
162    Appendix A.  Pseudo-Random Number Generator .......................77
163
164
165
166
167
168
169
170 Arkko & Haverinen            Informational                      [Page 3]
171 \f
172 RFC 4187                 EAP-AKA Authentication             January 2006
173
174
175 1.  Introduction and Motivation
176
177    This document specifies an Extensible Authentication Protocol (EAP)
178    mechanism for authentication and session key distribution that uses
179    the 3rd generation Authentication and Key Agreement mechanism,
180    specified for Universal Mobile Telecommunications System (UMTS) in
181    [TS33.102] and for CDMA2000 in [S.S0055-A].  UMTS and CDMA2000 are
182    global 3rd generation mobile network standards that use the same AKA
183    mechanism.
184
185    2nd generation mobile networks and 3rd generation mobile networks use
186    different authentication and key agreement mechanisms.  The Global
187    System for Mobile communications (GSM) is a 2nd generation mobile
188    network standard, and EAP-SIM [EAP-SIM] specifies an EAP mechanism
189    that is based on the GSM authentication and key agreement primitives.
190
191    AKA is based on challenge-response mechanisms and symmetric
192    cryptography.  AKA typically runs in a UMTS Subscriber Identity
193    Module (USIM) or a CDMA2000 (Removable) User Identity Module
194    ((R)UIM).  In this document, both modules are referred to as identity
195    modules.  Compared to the 2nd generation mechanisms such as GSM AKA,
196    the 3rd generation AKA provides substantially longer key lengths and
197    mutual authentication.
198
199    The introduction of AKA inside EAP allows several new applications.
200    These include the following:
201
202    o  The use of the AKA also as a secure PPP authentication method in
203       devices that already contain an identity module.
204    o  The use of the 3rd generation mobile network authentication
205       infrastructure in the context of wireless LANs
206    o  Relying on AKA and the existing infrastructure in a seamless way
207       with any other technology that can use EAP.
208
209    AKA works in the following manner:
210
211    o  The identity module and the home environment have agreed on a
212       secret key beforehand.  (The "home environment" refers to the home
213       operator's authentication network infrastructure.)
214    o  The actual authentication process starts by having the home
215       environment produce an authentication vector, based on the secret
216       key and a sequence number.  The authentication vector contains a
217       random part RAND, an authenticator part AUTN used for
218       authenticating the network to the identity module, an expected
219       result part XRES, a 128-bit session key for integrity check IK,
220       and a 128-bit session key for encryption CK.
221
222
223
224
225
226 Arkko & Haverinen            Informational                      [Page 4]
227 \f
228 RFC 4187                 EAP-AKA Authentication             January 2006
229
230
231    o  The RAND and the AUTN are delivered to the identity module.
232    o  The identity module verifies the AUTN, again based on the secret
233       key and the sequence number.  If this process is successful (the
234       AUTN is valid and the sequence number used to generate AUTN is
235       within the correct range), the identity module produces an
236       authentication result RES and sends it to the home environment.
237    o  The home environment verifies the correct result from the identity
238       module.  If the result is correct, IK and CK can be used to
239       protect further communications between the identity module and the
240       home environment.
241
242    When verifying AUTN, the identity module may detect that the sequence
243    number the network uses is not within the correct range.  In this
244    case, the identity module calculates a sequence number
245    synchronization parameter AUTS and sends it to the network.  AKA
246    authentication may then be retried with a new authentication vector
247    generated using the synchronized sequence number.
248
249    For a specification of the AKA mechanisms and how the cryptographic
250    values AUTN, RES, IK, CK and AUTS are calculated, see [TS33.102] for
251    UMTS and [S.S0055-A] for CDMA2000.
252
253    In EAP-AKA, the EAP server node obtains the authentication vectors,
254    compares RES and XRES, and uses CK and IK in key derivation.
255
256    In the 3rd generation mobile networks, AKA is used for both radio
257    network authentication and IP multimedia service authentication
258    purposes.  Different user identities and formats are used for these;
259    the radio network uses the International Mobile Subscriber Identifier
260    (IMSI), whereas the IP multimedia service uses the Network Access
261    Identifier (NAI) [RFC4282].
262
263 2.  Terms and Conventions Used in This Document
264
265    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
266    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
267    document are to be interpreted as described in [RFC2119].
268
269    The terms and abbreviations "authenticator", "backend authentication
270    server", "EAP server", "peer", "Silently Discard", "Master Session
271    Key (MSK)", and "Extended Master Session Key (EMSK)" in this document
272    are to be interpreted as described in [RFC3748].
273
274    This document frequently uses the following terms and abbreviations.
275    The AKA parameters are specified in detail in [TS33.102] for UMTS and
276    [S.S0055-A] for CDMA2000.
277
278
279
280
281
282 Arkko & Haverinen            Informational                      [Page 5]
283 \f
284 RFC 4187                 EAP-AKA Authentication             January 2006
285
286
287    AAA protocol
288
289          Authentication, Authorization and Accounting protocol
290
291    AKA
292
293          Authentication and Key Agreement
294
295    AuC
296
297          Authentication Centre.  The mobile network element that can
298          authenticate subscribers in the mobile networks.
299
300    AUTN
301
302          AKA parameter.  AUTN is an authentication value generated by
303          the AuC, which, together with the RAND, authenticates the
304          server to the peer, 128 bits.
305
306    AUTS
307
308          AKA parameter.  A value generated by the peer upon
309          experiencing a synchronization failure, 112 bits.
310
311    EAP
312
313          Extensible Authentication Protocol [RFC3748]
314
315    Fast Re-Authentication
316
317          An EAP-AKA authentication exchange that is based on keys
318          derived upon a preceding full authentication exchange.  The
319          3rd Generation AKA is not used in the fast re-authentication
320          procedure.
321
322    Fast Re-Authentication Identity
323
324          A fast re-authentication identity of the peer, including an
325          NAI realm portion in environments where a realm is used.
326          Used on re-authentication only.
327
328    Fast Re-Authentication Username
329
330          The username portion of fast re-authentication identity,
331          i.e., not including any realm portions.
332
333
334
335
336
337
338 Arkko & Haverinen            Informational                      [Page 6]
339 \f
340 RFC 4187                 EAP-AKA Authentication             January 2006
341
342
343    Full Authentication
344
345          An EAP-AKA authentication exchange that is based on the
346          3rd Generation AKA procedure.
347
348    GSM
349
350          Global System for Mobile communications.
351
352    NAI
353
354          Network Access Identifier [RFC4282]
355
356    Identity Module
357
358          Identity module is used in this document to refer to the
359          part of the mobile device that contains authentication and
360          key agreement primitives.  The identity module may be an
361          integral part of the mobile device or it may be an application
362          on a smart card distributed by a mobile operator.  USIM and
363          (R)UIM are identity modules.
364
365    Nonce
366
367          A value that is used at most once or that is never repeated
368          within the same cryptographic context.  In general, a nonce can
369          be predictable (e.g., a counter) or unpredictable (e.g., a
370          random value).  Because some cryptographic properties may
371          depend on the randomness of the nonce, attention should be paid
372          to whether a nonce is required to be random or not.  In this
373          document, the term nonce is only used to denote random nonces,
374          and it is not used to denote counters.
375
376    Permanent Identity
377
378          The permanent identity of the peer, including an NAI realm
379          portion in environments where a realm is used.  The permanent
380          identity is usually based on the IMSI.  Used on full
381          authentication only.
382
383    Permanent Username
384
385          The username portion of permanent identity, i.e., not including
386          any realm portions.
387
388
389
390
391
392
393
394 Arkko & Haverinen            Informational                      [Page 7]
395 \f
396 RFC 4187                 EAP-AKA Authentication             January 2006
397
398
399    Pseudonym Identity
400
401          A pseudonym identity of the peer, including an NAI realm
402          portion in environments where a realm is used.  Used on full
403          authentication only.
404
405    Pseudonym Username
406
407          The username portion of pseudonym identity, i.e., not including
408          any realm portions.
409
410    RAND
411
412          An AKA parameter.  Random number generated by the AuC,
413          128 bits.
414
415    RES
416
417          Authentication result from the peer, which, together with
418          the RAND, authenticates the peer to the server,
419          128 bits.
420
421    (R)UIM
422
423          CDMA2000 (Removable) User Identity Module.  (R)UIM is an
424          application that is resident on devices such as smart cards,
425          which may be fixed in the terminal or distributed by CDMA2000
426          operators (when removable).
427
428    SQN
429
430          An AKA parameter.  Sequence number used in the authentication
431          process, 48 bits.
432
433    SIM
434
435          Subscriber Identity Module.  The SIM is traditionally a smart
436          card distributed by a GSM operator.
437
438    SRES
439
440          The authentication result parameter in GSM, corresponds to
441          the RES parameter in 3G AKA, 32 bits.
442
443
444
445
446
447
448
449
450 Arkko & Haverinen            Informational                      [Page 8]
451 \f
452 RFC 4187                 EAP-AKA Authentication             January 2006
453
454
455    UAK
456
457          UIM Authentication Key, used in CDMA2000 AKA.  Both the
458          identity module and the network can optionally generate the UAK
459          during the AKA computation in CDMA2000.  UAK is not used in
460          this version of EAP-AKA.
461
462    UIM
463
464          Please see (R)UIM.
465
466    USIM
467
468          UMTS Subscriber Identity Module.  USIM is an application that
469          is resident on devices such as smart cards distributed by UMTS
470          operators.
471
472 3.  Protocol Overview
473
474    Figure 1 shows the basic, successful full authentication exchange in
475    EAP-AKA, when optional result indications are not used.  The
476    authenticator typically communicates with an EAP server that is
477    located on a backend authentication server using an AAA protocol.
478    The authenticator shown in the figure is often simply relaying EAP
479    messages to and from the EAP server, but these backend AAA
480    communications are not shown.  At the minimum, EAP-AKA uses two
481    roundtrips to authenticate and authorize the peer and generate
482    session keys.  As in other EAP schemes, an identity request/response
483    message pair is usually exchanged first.  On full authentication, the
484    peer's identity response includes either the user's International
485    Mobile Subscriber Identity (IMSI), or a temporary identity
486    (pseudonym) if identity privacy is in effect, as specified in
487    Section 4.1.  (As specified in [RFC3748], the initial identity
488    request is not required, and MAY be bypassed in cases where the
489    network can presume the identity, such as when using leased lines,
490    dedicated dial-ups, etc.  Please see Section 4.1.2 for specification
491    of how to obtain the identity via EAP AKA messages.)
492
493    After obtaining the subscriber identity, the EAP server obtains an
494    authentication vector (RAND, AUTN, RES, CK, IK) for use in
495    authenticating the subscriber.  From the vector, the EAP server
496    derives the keying material, as specified in Section 6.4.  The vector
497    may be obtained by contacting an Authentication Centre (AuC) on the
498    mobile network; for example, per UMTS specifications, several vectors
499    may be obtained at a time.  Vectors may be stored in the EAP server
500    for use at a later time, but they may not be reused.
501
502
503
504
505
506 Arkko & Haverinen            Informational                      [Page 9]
507 \f
508 RFC 4187                 EAP-AKA Authentication             January 2006
509
510
511    In CDMA2000, the vector may include a sixth value called the User
512    Identity Module Authentication Key (UAK).  This key is not used in
513    EAP-AKA.
514
515    Next, the EAP server starts the actual AKA protocol by sending an
516    EAP-Request/AKA-Challenge message.  EAP-AKA packets encapsulate
517    parameters in attributes, encoded in a Type, Length, Value format.
518    The packet format and the use of attributes are specified in
519    Section 8.  The EAP-Request/AKA-Challenge message contains a RAND
520    random number (AT_RAND), a network authentication token (AT_AUTN),
521    and a message authentication code (AT_MAC).  The EAP-Request/
522    AKA-Challenge message MAY optionally contain encrypted data, which is
523    used for identity privacy and fast re-authentication support, as
524    described in Section 4.1.  The AT_MAC attribute contains a message
525    authentication code covering the EAP packet.  The encrypted data is
526    not shown in the figures of this section.
527
528    The peer runs the AKA algorithm (typically using an identity module)
529    and verifies the AUTN.  If this is successful, the peer is talking to
530    a legitimate EAP server and proceeds to send the EAP-Response/
531    AKA-Challenge.  This message contains a result parameter that allows
532    the EAP server, in turn, to authenticate the peer, and the AT_MAC
533    attribute to integrity protect the EAP message.
534
535    The EAP server verifies that the RES and the MAC in the EAP-Response/
536    AKA-Challenge packet are correct.  Because protected success
537    indications are not used in this example, the EAP server sends the
538    EAP-Success packet, indicating that the authentication was
539    successful.  (Protected success indications are discussed in
540    Section 6.2.)  The EAP server may also include derived keying
541    material in the message it sends to the authenticator.  The peer has
542    derived the same keying material, so the authenticator does not
543    forward the keying material to the peer along with EAP-Success.
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562 Arkko & Haverinen            Informational                     [Page 10]
563 \f
564 RFC 4187                 EAP-AKA Authentication             January 2006
565
566
567        Peer                                             Authenticator
568           |                      EAP-Request/Identity             |
569           |<------------------------------------------------------|
570           |                                                       |
571           | EAP-Response/Identity                                 |
572           | (Includes user's NAI)                                 |
573           |------------------------------------------------------>|
574           |                            +------------------------------+
575           |                            | Server runs AKA algorithms,  |
576           |                            | generates RAND and AUTN.     |
577           |                            +------------------------------+
578           |                         EAP-Request/AKA-Challenge     |
579           |                         (AT_RAND, AT_AUTN, AT_MAC)    |
580           |<------------------------------------------------------|
581       +-------------------------------------+                     |
582       | Peer runs AKA algorithms,           |                     |
583       | verifies AUTN and MAC, derives RES  |                     |
584       | and session key                     |                     |
585       +-------------------------------------+                     |
586           | EAP-Response/AKA-Challenge                            |
587           | (AT_RES, AT_MAC)                                      |
588           |------------------------------------------------------>|
589           |                          +--------------------------------+
590           |                          | Server checks the given RES,   |
591           |                          | and MAC and finds them correct.|
592           |                          +--------------------------------+
593           |                                          EAP-Success  |
594           |<------------------------------------------------------|
595
596               Figure 1: EAP-AKA full authentication procedure
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618 Arkko & Haverinen            Informational                     [Page 11]
619 \f
620 RFC 4187                 EAP-AKA Authentication             January 2006
621
622
623    Figure 2 shows how the EAP server rejects the Peer due to a failed
624    authentication.
625
626        Peer                                              Authenticator
627           |                      EAP-Request/Identity             |
628           |<------------------------------------------------------|
629           |                                                       |
630           | EAP-Response/Identity                                 |
631           | (Includes user's NAI)                                 |
632           |------------------------------------------------------>|
633           |                            +------------------------------+
634           |                            | Server runs AKA algorithms,  |
635           |                            | generates RAND and AUTN.     |
636           |                            +------------------------------+
637           |                      EAP-Request/AKA-Challenge        |
638           |                      (AT_RAND, AT_AUTN, AT_MAC)       |
639           |<------------------------------------------------------|
640       +-------------------------------------+                     |
641       | Peer runs AKA algorithms,           |                     |
642       | possibly verifies AUTN, and sends an|                     |
643       | invalid response                    |                     |
644       +-------------------------------------+                     |
645           | EAP-Response/AKA-Challenge                            |
646           | (AT_RES, AT_MAC)                                      |
647           |------------------------------------------------------>|
648           |              +------------------------------------------+
649           |              | Server checks the given RES and the MAC, |
650           |              | and finds one of them incorrect.         |
651           |              +------------------------------------------+
652           |                      EAP-Request/AKA-Notification     |
653           |<------------------------------------------------------|
654           | EAP-Response/AKA-Notification                         |
655           |------------------------------------------------------>|
656           |                                          EAP-Failure  |
657           |<------------------------------------------------------|
658
659                     Figure 2: Peer authentication fails
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674 Arkko & Haverinen            Informational                     [Page 12]
675 \f
676 RFC 4187                 EAP-AKA Authentication             January 2006
677
678
679    Figure 3 shows the peer rejecting the AUTN of the EAP server.
680
681    The peer sends an explicit error message (EAP-Response/
682    AKA-Authentication-Reject) to the EAP server, as usual in AKA when
683    AUTN is incorrect.  This allows the EAP server to produce the same
684    error statistics that AKA generally produces in UMTS or CDMA2000.
685
686         Peer                                             Authenticator
687           |                      EAP-Request/Identity             |
688           |<------------------------------------------------------|
689           | EAP-Response/Identity                                 |
690           | (Includes user's NAI)                                 |
691           |------------------------------------------------------>|
692           |                            +------------------------------+
693           |                            | Server runs AKA algorithms,  |
694           |                            | generates RAND and a bad AUTN|
695           |                            +------------------------------+
696           |                         EAP-Request/AKA-Challenge     |
697           |                         (AT_RAND, AT_AUTN, AT_MAC)    |
698           |<------------------------------------------------------|
699       +-------------------------------------+                     |
700       | Peer runs AKA algorithms            |                     |
701       | and discovers AUTN that can not be  |                     |
702       | verified                            |                     |
703       +-------------------------------------+                     |
704           | EAP-Response/AKA-Authentication-Reject                |
705           |------------------------------------------------------>|
706           |                                          EAP-Failure  |
707           |<------------------------------------------------------|
708
709                   Figure 3: Network authentication fails
710
711    The AKA uses shared secrets between the Peer and the Peer's home
712    operator, together with a sequence number, to actually perform an
713    authentication.  In certain circumstances, shown in Figure 4, it is
714    possible for the sequence numbers to get out of sequence.
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730 Arkko & Haverinen            Informational                     [Page 13]
731 \f
732 RFC 4187                 EAP-AKA Authentication             January 2006
733
734
735         Peer                                             Authenticator
736           |                      EAP-Request/Identity             |
737           |<------------------------------------------------------|
738           | EAP-Response/Identity                                 |
739           | (Includes user's NAI)                                 |
740           |------------------------------------------------------>|
741           |                            +------------------------------+
742           |                            | Server runs AKA algorithms,  |
743           |                            | generates RAND and AUTN.     |
744           |                            +------------------------------+
745           |                         EAP-Request/AKA-Challenge     |
746           |                         (AT_RAND, AT_AUTN, AT_MAC)    |
747           |<------------------------------------------------------|
748       +-------------------------------------+                     |
749       | Peer runs AKA algorithms            |                     |
750       | and discovers AUTN that contains an |                     |
751       | inappropriate sequence number       |                     |
752       +-------------------------------------+                     |
753           | EAP-Response/AKA-Synchronization-Failure              |
754           | (AT_AUTS)                                             |
755           |------------------------------------------------------>|
756           |                              +---------------------------+
757           |                              | Perform resynchronization |
758           |                              | Using AUTS and            |
759           |                              | the sent RAND             |
760           |                              +---------------------------+
761           |                                                       |
762
763                  Figure 4: Sequence number synchronization
764
765    After the resynchronization process has taken place in the server and
766    AAA side, the process continues by the server side sending a new
767    EAP-Request/AKA-Challenge message.
768
769    In addition to the full authentication scenarios described above,
770    EAP-AKA includes a fast re-authentication procedure, which is
771    specified in Section 5.  Fast re-authentication is based on keys
772    derived on full authentication.  If the peer has maintained state
773    information for re-authentication and wants to use fast
774    re-authentication, then the peer indicates this by using a specific
775    fast re-authentication identity instead of the permanent identity or
776    a pseudonym identity.
777
778
779
780
781
782
783
784
785
786 Arkko & Haverinen            Informational                     [Page 14]
787 \f
788 RFC 4187                 EAP-AKA Authentication             January 2006
789
790
791 4.  Operation
792
793 4.1.  Identity Management
794
795 4.1.1.  Format, Generation, and Usage of Peer Identities
796
797 4.1.1.1.  General
798
799    In the beginning of EAP authentication, the Authenticator or the EAP
800    server usually issues the EAP-Request/Identity packet to the peer.
801    The peer responds with EAP-Response/Identity, which contains the
802    user's identity.  The formats of these packets are specified in
803    [RFC3748].
804
805    Subscribers of mobile networks are identified with the International
806    Mobile Subscriber Identity (IMSI) [TS23.003].  The IMSI is a string
807    of not more than 15 digits.  It is composed of a Mobile Country Code
808    (MCC) of 3 digits, a Mobile Network Code (MNC) of 2 or 3 digits, and
809    a Mobile Subscriber Identification Number (MSIN) of not more than 10
810    digits.  MCC and MNC uniquely identify the GSM operator and help
811    identify the AuC from which the authentication vectors need to be
812    retrieved for this subscriber.
813
814    Internet AAA protocols identify users with the Network Access
815    Identifier (NAI) [RFC4282].  When used in a roaming environment, the
816    NAI is composed of a username and a realm, separated with "@"
817    (username@realm).  The username portion identifies the subscriber
818    within the realm.
819
820    This section specifies the peer identity format used in EAP-AKA.  In
821    this document, the term identity or peer identity refers to the whole
822    identity string that is used to identify the peer.  The peer identity
823    may include a realm portion.  "Username" refers to the portion of the
824    peer identity that identifies the user, i.e., the username does not
825    include the realm portion.
826
827 4.1.1.2.  Identity Privacy Support
828
829    EAP-AKA includes optional identity privacy (anonymity) support that
830    can be used to hide the cleartext permanent identity and thereby make
831    the subscriber's EAP exchanges untraceable to eavesdroppers.  Because
832    the permanent identity never changes, revealing it would help
833    observers to track the user.  The permanent identity is usually based
834    on the IMSI, which may further help the tracking, because the same
835    identifier may be used in other contexts as well.  Identity privacy
836    is based on temporary identities, or pseudonyms, which are equivalent
837
838
839
840
841
842 Arkko & Haverinen            Informational                     [Page 15]
843 \f
844 RFC 4187                 EAP-AKA Authentication             January 2006
845
846
847    to but separate from the Temporary Mobile Subscriber Identities
848    (TMSI) that are used on cellular networks.  Please see Section 12.1
849    for security considerations regarding identity privacy.
850
851 4.1.1.3.  Username Types in EAP-AKA Identities
852
853    There are three types of usernames in EAP-AKA peer identities:
854
855    (1) Permanent usernames.  For example,
856    0123456789098765@myoperator.com might be a valid permanent identity.
857    In this example, 0123456789098765 is the permanent username.
858
859    (2) Pseudonym usernames.  For example, 2s7ah6n9q@myoperator.com might
860    be a valid pseudonym identity.  In this example, 2s7ah6n9q is the
861    pseudonym username.
862
863    (3) Fast re-authentication usernames.  For example,
864    43953754@myoperator.com might be a valid fast re-authentication
865    identity.  In this case, 43953754 is the fast re-authentication
866    username.  Unlike permanent usernames and pseudonym usernames, fast
867    re-authentication usernames are one-time identifiers, which are not
868    re-used across EAP exchanges.
869
870    The first two types of identities are used only on full
871    authentication, and the last type only on fast re-authentication.
872    When the optional identity privacy support is not used, the
873    non-pseudonym permanent identity is used on full authentication.  The
874    fast re-authentication exchange is specified in Section 5.
875
876 4.1.1.4.  Username Decoration
877
878    In some environments, the peer may need to decorate the identity by
879    prepending or appending the username with a string, in order to
880    indicate supplementary AAA routing information in addition to the NAI
881    realm.  (The usage of an NAI realm portion is not considered to be
882    decoration.)  Username decoration is out of the scope of this
883    document.  However, it should be noted that username decoration might
884    prevent the server from recognizing a valid username.  Hence,
885    although the peer MAY use username decoration in the identities that
886    the peer includes in EAP-Response/Identity, and although the EAP
887    server MAY accept a decorated peer username in this message, the peer
888    or the EAP server MUST NOT decorate any other peer identities that
889    are used in various EAP-AKA attributes.  Only the identity used in
890    EAP-Response/Identity may be decorated.
891
892
893
894
895
896
897
898 Arkko & Haverinen            Informational                     [Page 16]
899 \f
900 RFC 4187                 EAP-AKA Authentication             January 2006
901
902
903 4.1.1.5.  NAI Realm Portion
904
905    The peer MAY include a realm portion in the peer identity, as per the
906    NAI format.  The use of a realm portion is not mandatory.
907
908    If a realm is used, the realm MAY be chosen by the subscriber's home
909    operator and it MAY be a configurable parameter in the EAP-AKA peer
910    implementation.  In this case, the peer is typically configured with
911    the NAI realm of the home operator.  Operators MAY reserve a specific
912    realm name for EAP-AKA users.  This convention makes it easy to
913    recognize that the NAI identifies an AKA subscriber.  Such a reserved
914    NAI realm may be useful as a hint of the first authentication method
915    to use during method negotiation.  When the peer is using a pseudonym
916    username instead of the permanent username, the peer selects the
917    realm name portion similarly to how it selects the realm portion when
918    using the permanent username.
919
920    If no configured realm name is available, the peer MAY derive the
921    realm name from the MCC and MNC portions of the IMSI.  A RECOMMENDED
922    way to derive the realm from the IMSI, using the realm
923    3gppnetwork.org, will be specified in [TS23.003].
924
925    Some old implementations derive the realm name from the IMSI by
926    concatenating "mnc", the MNC digits of IMSI, ".mcc", the MCC digits
927    of IMSI, and ".owlan.org".  For example, if the IMSI is
928    123456789098765, and the MNC is three digits long, then the derived
929    realm name is "mnc456.mcc123.owlan.org".  As there are no DNS servers
930    running at owlan.org, these realm names can only be used with
931    manually configured AAA routing.  New implementations SHOULD use the
932    mechanism specified in [TS23.003] instead of owlan.org.
933
934    The IMSI is a string of digits without any explicit structure, so the
935    peer may not be able to determine the length of the MNC portion.  If
936    the peer is not able to determine whether the MNC is two or three
937    digits long, the peer MAY use a 3-digit MNC.  If the correct length
938    of the MNC is two, then the MNC used in the realm name includes the
939    first digit of MSIN.  Hence, when configuring AAA networks for
940    operators that have 2-digit MNC's, the network SHOULD also be
941    prepared for realm names with incorrect 3-digit MNC's.
942
943 4.1.1.6.  Format of the Permanent Username
944
945    The non-pseudonym permanent username SHOULD be derived from the IMSI.
946    In this case, the permanent username MUST be of the format "0" |
947    IMSI, where the character "|" denotes concatenation.  In other words,
948    the first character of the username is the digit zero (ASCII value 30
949    hexadecimal), followed by the IMSI.  The IMSI is an ASCII string that
950    consists of not more than 15 decimal digits (ASCII values between 30
951
952
953
954 Arkko & Haverinen            Informational                     [Page 17]
955 \f
956 RFC 4187                 EAP-AKA Authentication             January 2006
957
958
959    and 39 hexadecimal), one character per IMSI digit, in the order as
960    specified in [TS23.003].  For example, a permanent username derived
961    from the IMSI 295023820005424 would be encoded as the ASCII string
962    "0295023820005424" (byte values in hexadecimal notation: 30 32 39 35
963    30 32 33 38 32 30 30 30 35 34 32 34)
964
965    The EAP server MAY use the leading "0" as a hint to try EAP-AKA as
966    the first authentication method during method negotiation, rather
967    than using, for example, EAP-SIM.  The EAP-AKA server MAY propose
968    EAP-AKA even if the leading character was not "0".
969
970    Alternatively, an implementation MAY choose a permanent username that
971    is not based on the IMSI.  In this case the selection of the
972    username, its format, and its processing is out of the scope of this
973    document.  In this case, the peer implementation MUST NOT prepend any
974    leading characters to the username.
975
976 4.1.1.7.  Generating Pseudonyms and Fast Re-Authentication Identities by
977           the Server
978
979    Pseudonym usernames and fast re-authentication identities are
980    generated by the EAP server.  The EAP server produces pseudonym
981    usernames and fast re-authentication identities in an
982    implementation-dependent manner.  Only the EAP server needs to be
983    able to map the pseudonym username to the permanent identity, or to
984    recognize a fast re-authentication identity.
985
986    EAP-AKA includes no provisions to ensure that the same EAP server
987    that generated a pseudonym username will be used on the
988    authentication exchange when the pseudonym username is used.  It is
989    recommended that the EAP servers implement some centralized mechanism
990    to allow all EAP servers of the home operator to map pseudonyms
991    generated by other severs to the permanent identity.  If no such
992    mechanism is available, then the EAP server, failing to understand a
993    pseudonym issued by another server, can request the peer to send the
994    permanent identity.
995
996    When issuing a fast re-authentication identity, the EAP server may
997    include a realm name in the identity that will cause the fast
998    re-authentication request to be forwarded to the same EAP server.
999
1000    When generating fast re-authentication identities, the server SHOULD
1001    choose a fresh, new fast re-authentication identity that is different
1002    from the previous ones that were used after the same full
1003    authentication exchange.  A full authentication exchange and the
1004    associated fast re-authentication exchanges are referred to here as
1005    the same "full authentication context".  The fast re-authentication
1006    identity SHOULD include a random component.  The random component
1007
1008
1009
1010 Arkko & Haverinen            Informational                     [Page 18]
1011 \f
1012 RFC 4187                 EAP-AKA Authentication             January 2006
1013
1014
1015    works as a full authentication context identifier.  A context-
1016    specific fast re-authentication identity can help the server to
1017    detect whether its fast re-authentication state information matches
1018    the peer's fast re-authentication state information (in other words,
1019    whether the state information is from the same full authentication
1020    exchange).  The random component also makes the fast re-
1021    authentication identities unpredictable, so an attacker cannot
1022    initiate a fast re-authentication exchange to get the server's
1023    EAP-Request/AKA-Reauthentication packet.
1024
1025    Transmitting pseudonyms and fast re-authentication identities from
1026    the server to the peer is discussed in Section 4.1.1.8.  The
1027    pseudonym is transmitted as a username, without an NAI realm, and the
1028    fast re-authentication identity is transmitted as a complete NAI,
1029    including a realm portion if a realm is required.  The realm is
1030    included in the fast re-authentication identity in order to allow the
1031    server to include a server-specific realm.
1032
1033    Regardless of construction method, the pseudonym username MUST
1034    conform to the grammar specified for the username portion of an NAI.
1035    Also, the fast re-authentication identity MUST conform to the NAI
1036    grammar.  The EAP servers that the subscribers of an operator can use
1037    MUST ensure that the pseudonym usernames and the username portions
1038    used in fast re-authentication identities that they generate are
1039    unique.
1040
1041    In any case, it is necessary that permanent usernames, pseudonym
1042    usernames, and fast re-authentication usernames are separate and
1043    recognizable from each other.  It is also desirable that EAP-SIM and
1044    EAP-AKA usernames be recognizable from each other as an aid to the
1045    server when deciding which method to offer.
1046
1047    In general, it is the task of the EAP server and the policies of its
1048    administrator to ensure sufficient separation of the usernames.
1049    Pseudonym usernames and fast re-authentication usernames are both
1050    produced and used by the EAP server.  The EAP server MUST compose
1051    pseudonym usernames and fast re-authentication usernames so that it
1052    can recognize if an NAI username is an EAP-AKA pseudonym username or
1053    an EAP-AKA fast re-authentication username.  For instance, when the
1054    usernames have been derived from the IMSI, the server could use
1055    different leading characters in the pseudonym usernames and fast
1056    re-authentication usernames (e.g., the pseudonym could begin with a
1057    leading "2" character).  When mapping a fast re-authentication
1058    identity to a permanent identity, the server SHOULD only examine the
1059    username portion of the fast re-authentication identity and ignore
1060    the realm portion of the identity.
1061
1062
1063
1064
1065
1066 Arkko & Haverinen            Informational                     [Page 19]
1067 \f
1068 RFC 4187                 EAP-AKA Authentication             January 2006
1069
1070
1071    Because the peer may fail to save a pseudonym username that was sent
1072    in an EAP-Request/AKA-Challenge (for example, due to malfunction),
1073    the EAP server SHOULD maintain, at least, the most recently used
1074    pseudonym username in addition to the most recently issued pseudonym
1075    username.  If the authentication exchange is not completed
1076    successfully, then the server SHOULD NOT overwrite the pseudonym
1077    username that was issued during the most recent successful
1078    authentication exchange.
1079
1080 4.1.1.8.  Transmitting Pseudonyms and Fast Re-Authentication Identities
1081           to the Peer
1082
1083    The server transmits pseudonym usernames and fast re-authentication
1084    identities to the peer in cipher, using the AT_ENCR_DATA attribute.
1085
1086    The EAP-Request/AKA-Challenge message MAY include an encrypted
1087    pseudonym username and/or an encrypted fast re-authentication
1088    identity in the value field of the AT_ENCR_DATA attribute.  Because
1089    identity privacy support and fast re-authentication are optional to
1090    implement, the peer MAY ignore the AT_ENCR_DATA attribute and always
1091    use the permanent identity.  On fast re-authentication (discussed in
1092    Section 5), the server MAY include a new, encrypted fast re-
1093    authentication identity in the EAP-Request/AKA-Reauthentication
1094    message.
1095
1096    On receipt of the EAP-Request/AKA-Challenge, the peer MAY decrypt the
1097    encrypted data in AT_ENCR_DATA; and if a pseudonym username is
1098    included, the peer may use the obtained pseudonym username on the
1099    next full authentication.  If a fast re-authentication identity is
1100    included, then the peer MAY save it together with other fast re-
1101    authentication state information, as discussed in Section 5, for the
1102    next fast re-authentication.
1103
1104    If the peer does not receive a new pseudonym username in the
1105    EAP-Request/AKA-Challenge message, the peer MAY use an old pseudonym
1106    username instead of the permanent username on next full
1107    authentication.  The username portions of fast re-authentication
1108    identities are one-time usernames, which the peer MUST NOT re-use.
1109    When the peer uses a fast re-authentication identity in an EAP
1110    exchange, the peer MUST discard the fast re-authentication identity
1111    and not re-use it in another EAP authentication exchange, even if the
1112    authentication exchange was not completed.
1113
1114 4.1.1.9.  Usage of the Pseudonym by the Peer
1115
1116    When the optional identity privacy support is used on full
1117    authentication, the peer MAY use a pseudonym username received as
1118    part of a previous full authentication sequence as the username
1119
1120
1121
1122 Arkko & Haverinen            Informational                     [Page 20]
1123 \f
1124 RFC 4187                 EAP-AKA Authentication             January 2006
1125
1126
1127    portion of the NAI.  The peer MUST NOT modify the pseudonym username
1128    received in AT_NEXT_PSEUDONYM.  However, as discussed above, the peer
1129    MAY need to decorate the username in some environments by appending
1130    or prepending the username with a string that indicates supplementary
1131    AAA routing information.
1132
1133    When using a pseudonym username in an environment where a realm
1134    portion is used, the peer concatenates the received pseudonym
1135    username with the "@" character and an NAI realm portion.  The
1136    selection of the NAI realm is discussed above.  The peer can select
1137    the realm portion similarly, regardless of whether it uses the
1138    permanent username or a pseudonym username.
1139
1140 4.1.1.10.  Usage of the Fast Re-Authentication Identity by the Peer
1141
1142    On fast re-authentication, the peer uses the fast re-authentication
1143    identity received as part of the previous authentication sequence.  A
1144    new fast re-authentication identity may be delivered as part of both
1145    full authentication and fast re-authentication.  The peer MUST NOT
1146    modify the username part of the fast re-authentication identity
1147    received in AT_NEXT_REAUTH_ID, except in cases when username
1148    decoration is required.  Even in these cases, the "root" fast
1149    re-authentication username must not be modified, but it may be
1150    appended or prepended with another string.
1151
1152 4.1.2.  Communicating the Peer Identity to the Server
1153
1154 4.1.2.1.  General
1155
1156    The peer identity MAY be communicated to the server with the
1157    EAP-Response/Identity message.  This message MAY contain the
1158    permanent identity, a pseudonym identity, or a fast re-authentication
1159    identity.  If the peer uses the permanent identity or a pseudonym
1160    identity, which the server is able to map to the permanent identity,
1161    then the authentication proceeds as discussed in the overview of
1162    Section 3.  If the peer uses a fast re-authentication identity, and
1163    if the fast re-authentication identity matches with a valid fast
1164    re-authentication identity maintained by the server, then a fast
1165    re-authentication exchange is performed, as described in Section 5.
1166
1167    The peer identity can also be transmitted from the peer to the server
1168    using EAP-AKA messages instead of EAP-Response/Identity.  In this
1169    case, the server includes an identity requesting attribute
1170    (AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ) in the
1171    EAP-Request/AKA-Identity message; and the peer includes the
1172    AT_IDENTITY attribute, which contains the peer's identity, in the
1173    EAP-Response/AKA-Identity message.  The AT_ANY_ID_REQ attribute is a
1174    general identity requesting attribute, which the server uses if it
1175
1176
1177
1178 Arkko & Haverinen            Informational                     [Page 21]
1179 \f
1180 RFC 4187                 EAP-AKA Authentication             January 2006
1181
1182
1183    does not specify which kind of an identity the peer should return in
1184    AT_IDENTITY.  The server uses the AT_FULLAUTH_ID_REQ attribute to
1185    request either the permanent identity or a pseudonym identity.  The
1186    server uses the AT_PERMANENT_ID_REQ attribute to request that the
1187    peer send its permanent identity.  The EAP-Request/AKA-Challenge,
1188    EAP-Response/AKA-Challenge, or the packets used on fast re-
1189    authentication may optionally include the AT_CHECKCODE attribute,
1190    which enables the protocol peers to ensure the integrity of the
1191    AKA-Identity packets.  AT_CHECKCODE is specified in Section 10.13.
1192
1193    The identity format in the AT_IDENTITY attribute is the same as in
1194    the EAP-Response/Identity packet (except that identity decoration is
1195    not allowed).  The AT_IDENTITY attribute contains a permanent
1196    identity, a pseudonym identity, or a fast re-authentication identity.
1197
1198    Please note that only the EAP-AKA peer and the EAP-AKA server process
1199    the AT_IDENTITY attribute and entities that pass through; EAP packets
1200    do not process this attribute.  Hence, the authenticator and other
1201    intermediate AAA elements (such as possible AAA proxy servers) will
1202    continue to refer to the peer with the original identity from the
1203    EAP-Response/Identity packet unless the identity authenticated in the
1204    AT_IDENTITY attribute is communicated to them in another way within
1205    the AAA protocol.
1206
1207 4.1.2.2.  Relying on EAP-Response/Identity Discouraged
1208
1209    The EAP-Response/Identity packet is not method specific; therefore,
1210    in many implementations it may be handled by an EAP Framework.  This
1211    introduces an additional layer of processing between the EAP peer and
1212    EAP server.  The extra layer of processing may cache identity
1213    responses or add decorations to the identity.  A modification of the
1214    identity response will cause the EAP peer and EAP server to use
1215    different identities in the key derivation, which will cause the
1216    protocol to fail.
1217
1218    For this reason, it is RECOMMENDED that the EAP peer and server use
1219    the method-specific identity attributes in EAP-AKA, and the server is
1220    strongly discouraged from relying upon the EAP-Response/Identity.
1221
1222    In particular, if the EAP server receives a decorated identity in
1223    EAP-Response/Identity, then the EAP server MUST use the
1224    identity-requesting attributes to request the peer to send an
1225    unmodified and undecorated copy of the identity in AT_IDENTITY.
1226
1227
1228
1229
1230
1231
1232
1233
1234 Arkko & Haverinen            Informational                     [Page 22]
1235 \f
1236 RFC 4187                 EAP-AKA Authentication             January 2006
1237
1238
1239 4.1.3.  Choice of Identity for the EAP-Response/Identity
1240
1241    If EAP-AKA peer is started upon receiving an EAP-Request/Identity
1242    message, then the peer MAY use an EAP-AKA identity in the EAP-
1243    Response/Identity packet.  In this case, the peer performs the
1244    following steps.
1245
1246    If the peer has maintained fast re-authentication state information
1247    and if the peer wants to use fast re-authentication, then the peer
1248    transmits the fast re-authentication identity in
1249    EAP-Response/Identity.
1250
1251    Else, if the peer has a pseudonym username available, then the peer
1252    transmits the pseudonym identity in EAP-Response/Identity.
1253
1254    In other cases, the peer transmits the permanent identity in
1255    EAP-Response/Identity.
1256
1257 4.1.4.  Server Operation in the Beginning of EAP-AKA Exchange
1258
1259    As discussed in Section 4.1.2.2, the server SHOULD NOT rely on an
1260    identity string received in EAP-Response/Identity.  Therefore, the
1261    RECOMMENDED way to start an EAP-AKA exchange is to ignore any
1262    received identity strings.  The server SHOULD begin the EAP-AKA
1263    exchange by issuing the EAP-Request/AKA-Identity packet with an
1264    identity-requesting attribute to indicate that the server wants the
1265    peer to include an identity in the AT_IDENTITY attribute of the EAP-
1266    Response/AKA-Identity message.  Three methods to request an identity
1267    from the peer are discussed below.
1268
1269    If the server chooses to not ignore the contents of
1270    EAP-Response/Identity, then the server may already receive an EAP-AKA
1271    identity in this packet.  However, if the EAP server has not received
1272    any EAP-AKA peer identity (permanent identity, pseudonym identity, or
1273    fast re-authentication identity) from the peer when sending the first
1274    EAP-AKA request, or if the EAP server has received an
1275    EAP-Response/Identity packet but the contents do not appear to be a
1276    valid permanent identity, pseudonym identity, or a re-authentication
1277    identity, then the server MUST request an identity from the peer
1278    using one of the methods below.
1279
1280    The server sends the EAP-Request/AKA-Identity message with the
1281    AT_PERMANENT_ID_REQ attribute to indicate that the server wants the
1282    peer to include the permanent identity in the AT_IDENTITY attribute
1283    of the EAP-Response/AKA-Identity message.  This is done in the
1284    following cases:
1285
1286
1287
1288
1289
1290 Arkko & Haverinen            Informational                     [Page 23]
1291 \f
1292 RFC 4187                 EAP-AKA Authentication             January 2006
1293
1294
1295    o  The server does not support fast re-authentication or identity
1296       privacy.
1297    o  The server decided to process a received identity, and the server
1298       recognizes the received identity as a pseudonym identity, but the
1299       server is not able to map the pseudonym identity to a permanent
1300       identity.
1301
1302    The server issues the EAP-Request/AKA-Identity packet with the
1303    AT_FULLAUTH_ID_REQ attribute to indicate that the server wants the
1304    peer to include a full authentication identity (pseudonym identity or
1305    permanent identity) in the AT_IDENTITY attribute of the
1306    EAP-Response/AKA-Identity message.  This is done in the following
1307    cases:
1308
1309    o  The server does not support fast re-authentication and the server
1310       supports identity privacy
1311    o  The server decided to process a received identity, and the server
1312       recognizes the received identity as a re-authentication identity
1313       but the server is not able to map the re-authentication identity
1314       to a permanent identity
1315
1316    The server issues the EAP-Request/AKA-Identity packet with the
1317    AT_ANY_ID_REQ attribute to indicate that the server wants the peer to
1318    include an identity in the AT_IDENTITY attribute of the
1319    EAP-Response/AKA-Identity message, and the server does not indicate
1320    any preferred type for the identity.  This is done in other cases,
1321    such as when the server ignores a received EAP-Response/Identity,
1322    when the server does not have any identity, or when the server does
1323    not recognize the format of a received identity.
1324
1325 4.1.5.  Processing of EAP-Request/AKA-Identity by the Peer
1326
1327    Upon receipt of an EAP-Request/AKA-Identity message, the peer MUST
1328    perform the following steps.
1329
1330    If the EAP-Request/AKA-Identity includes AT_PERMANENT_ID_REQ, and if
1331    the peer does not have a pseudonym available, then the peer MUST
1332    respond with EAP-Response/AKA-Identity and include the permanent
1333    identity in AT_IDENTITY.  If the peer has a pseudonym available, then
1334    the peer MAY refuse to send the permanent identity; hence, in this
1335    case the peer MUST either respond with EAP-Response/AKA-Identity and
1336    include the permanent identity in AT_IDENTITY or respond with
1337    EAP-Response/AKA-Client-Error packet with code "unable to process
1338    packet".
1339
1340    If the EAP-Request/AKA-Identity includes AT_FULL_AUTH_ID_REQ, and if
1341    the peer has a pseudonym available, then the peer SHOULD respond with
1342    EAP-Response/AKA-Identity and include the pseudonym identity in
1343
1344
1345
1346 Arkko & Haverinen            Informational                     [Page 24]
1347 \f
1348 RFC 4187                 EAP-AKA Authentication             January 2006
1349
1350
1351    AT_IDENTITY.  If the peer does not have a pseudonym when it receives
1352    this message, then the peer MUST respond with EAP-Response/
1353    AKA-Identity and include the permanent identity in AT_IDENTITY.  The
1354    Peer MUST NOT use a fast re-authentication identity in the
1355    AT_IDENTITY attribute.
1356
1357    If the EAP-Request/AKA-Identity includes AT_ANY_ID_REQ, and if the
1358    peer has maintained fast re-authentication state information and
1359    wants to use fast re-authentication, then the peer responds with
1360    EAP-Response/AKA-Identity and includes the fast re-authentication
1361    identity in AT_IDENTITY.  Else, if the peer has a pseudonym identity
1362    available, then the peer responds with EAP-Response/AKA-Identity and
1363    includes the pseudonym identity in AT_IDENTITY.  Else, the peer
1364    responds with EAP-Response/AKA-Identity and includes the permanent
1365    identity in AT_IDENTITY.
1366
1367    An EAP-AKA exchange may include several EAP/AKA-Identity rounds.  The
1368    server may issue a second EAP-Request/AKA-Identity, if it was not
1369    able to recognize the identity the peer used in the previous
1370    AT_IDENTITY attribute.  At most three EAP/AKA-Identity rounds can be
1371    used, so the peer MUST NOT respond to more than three
1372    EAP-Request/AKA-Identity messages within an EAP exchange.  The peer
1373    MUST verify that the sequence of EAP-Request/AKA-Identity packets the
1374    peer receives comply with the sequencing rules defined in this
1375    document.  That is, AT_ANY_ID_REQ can only be used in the first
1376    EAP-Request/AKA-Identity; in other words, AT_ANY_ID_REQ MUST NOT be
1377    used in the second or third EAP-Request/AKA-Identity.
1378    AT_FULLAUTH_ID_REQ MUST NOT be used if the previous
1379    EAP-Request/AKA-Identity included AT_PERMANENT_ID_REQ.  The peer
1380    operation, in cases when it receives an unexpected attribute or an
1381    unexpected message, is specified in Section 6.3.1.
1382
1383 4.1.6.  Attacks against Identity Privacy
1384
1385    The section above specifies two possible ways the peer can operate
1386    upon receipt of AT_PERMANENT_ID_REQ because a received
1387    AT_PERMANENT_ID_REQ does not necessarily originate from the valid
1388    network.  However, an active attacker may transmit an
1389    EAP-Request/AKA-Identity packet with an AT_PERMANENT_ID_REQ attribute
1390    to the peer, in an effort to find out the true identity of the user.
1391    If the peer does not want to reveal its permanent identity, then the
1392    peer sends the EAP-Response/AKA-Client-Error packet with the error
1393    code "unable to process packet", and the authentication exchange
1394    terminates.
1395
1396    Basically, there are two different policies that the peer can employ
1397    with regard to AT_PERMANENT_ID_REQ.  A "conservative" peer assumes
1398    that the network is able to maintain pseudonyms robustly.  Therefore,
1399
1400
1401
1402 Arkko & Haverinen            Informational                     [Page 25]
1403 \f
1404 RFC 4187                 EAP-AKA Authentication             January 2006
1405
1406
1407    if a conservative peer has a pseudonym username, the peer responds
1408    with EAP-Response/AKA-Client-Error to the EAP packet with
1409    AT_PERMANENT_ID_REQ, because the peer believes that the valid network
1410    is able to map the pseudonym identity to the peer's permanent
1411    identity.  (Alternatively, the conservative peer may accept
1412    AT_PERMANENT_ID_REQ in certain circumstances, for example if the
1413    pseudonym was received a long time ago.)  The benefit of this policy
1414    is that it protects the peer against active attacks on anonymity.  On
1415    the other hand, a "liberal" peer always accepts the
1416    AT_PERMANENT_ID_REQ and responds with the permanent identity.  The
1417    benefit of this policy is that it works even if the valid network
1418    sometimes loses pseudonyms and is not able to map them to the
1419    permanent identity.
1420
1421 4.1.7.  Processing of AT_IDENTITY by the Server
1422
1423    When the server receives an EAP-Response/AKA-Identity message with
1424    the AT_IDENTITY (in response to the server's identity requesting
1425    attribute), the server MUST operate as follows.
1426
1427    If the server used AT_PERMANENT_ID_REQ, and if the AT_IDENTITY does
1428    not contain a valid permanent identity, then the server sends an
1429    EAP-Request/AKA-Notification packet with AT_NOTIFICATION code
1430    "General failure" (16384) to terminate the EAP exchange.  If the
1431    server recognizes the permanent identity and is able to continue,
1432    then the server proceeds with full authentication by sending
1433    EAP-Request/AKA-Challenge.
1434
1435    If the server used AT_FULLAUTH_ID_REQ, and if AT_IDENTITY contains a
1436    valid permanent identity or a pseudonym identity that the server can
1437    map to a valid permanent identity, then the server proceeds with full
1438    authentication by sending EAP-Request/AKA-Challenge.  If AT_IDENTITY
1439    contains a pseudonym identity that the server is not able to map to a
1440    valid permanent identity, or an identity that the server is not able
1441    to recognize or classify, then the server sends EAP-Request/
1442    AKA-Identity with AT_PERMANENT_ID_REQ.
1443
1444    If the server used AT_ANY_ID_REQ, and if the AT_IDENTITY contains a
1445    valid permanent identity or a pseudonym identity that the server can
1446    map to a valid permanent identity, then the server proceeds with full
1447    authentication by sending EAP-Request/ AKA-Challenge.
1448
1449    If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid
1450    fast re-authentication identity and the server agrees on using
1451    re-authentication, then the server proceeds with fast
1452    re-authentication by sending EAP-Request/AKA-Reauthentication
1453    (Section 5).
1454
1455
1456
1457
1458 Arkko & Haverinen            Informational                     [Page 26]
1459 \f
1460 RFC 4187                 EAP-AKA Authentication             January 2006
1461
1462
1463    If the server used AT_ANY_ID_REQ, and if the peer sent an EAP-
1464    Response/AKA-Identity with AT_IDENTITY that contains an identity that
1465    the server recognizes as a fast re-authentication identity, but the
1466    server is not able to map the identity to a permanent identity, then
1467    the server sends EAP-Request/AKA-Identity with AT_FULLAUTH_ID_REQ.
1468
1469    If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid
1470    fast re-authentication identity, which the server is able to map to a
1471    permanent identity, and if the server does not want to use fast
1472    re-authentication, then the server proceeds with full authentication
1473    by sending EAP-Request/AKA-Challenge.
1474
1475    If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an
1476    identity that the server recognizes as a pseudonym identity but the
1477    server is not able to map the pseudonym identity to a permanent
1478    identity, then the server sends EAP-Request/AKA-Identity with
1479    AT_PERMANENT_ID_REQ.
1480
1481    If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an
1482    identity that the server is not able to recognize or classify, then
1483    the server sends EAP-Request/AKA-Identity with AT_FULLAUTH_ID_REQ.
1484
1485 4.2.  Message Sequence Examples (Informative)
1486
1487    This section contains non-normative message sequence examples to
1488    illustrate how the peer identity can be communicated to the server.
1489
1490 4.2.1.  Usage of AT_ANY_ID_REQ
1491
1492    Obtaining the peer identity with EAP-AKA attributes is illustrated in
1493    Figure 5 below.
1494
1495        Peer                                             Authenticator
1496           |                                                       |
1497           |                            +------------------------------+
1498           |                            | Server does not have any     |
1499           |                            | Subscriber identity available|
1500           |                            | When starting EAP-AKA        |
1501           |                            +------------------------------+
1502           |          EAP-Request/AKA-Identity                     |
1503           |          (AT_ANY_ID_REQ)                              |
1504           |<------------------------------------------------------|
1505           |                                                       |
1506           | EAP-Response/AKA-Identity                             |
1507           | (AT_IDENTITY)                                         |
1508           |------------------------------------------------------>|
1509           |                                                       |
1510                      Figure 5: Usage of AT_ANY_ID_REQ
1511
1512
1513
1514 Arkko & Haverinen            Informational                     [Page 27]
1515 \f
1516 RFC 4187                 EAP-AKA Authentication             January 2006
1517
1518
1519 4.2.2.  Fall Back on Full Authentication
1520
1521    Figure 6 illustrates the case when the server does not recognize the
1522    fast re-authentication identity the peer used in AT_IDENTITY.
1523
1524        Peer                                             Authenticator
1525           |                                                       |
1526           |                            +------------------------------+
1527           |                            | Server does not have any     |
1528           |                            | Subscriber identity available|
1529           |                            | When starting EAP-AKA        |
1530           |                            +------------------------------+
1531           |        EAP-Request/AKA-Identity                       |
1532           |        (AT_ANY_ID_REQ)                                |
1533           |<------------------------------------------------------|
1534           |                                                       |
1535           | EAP-Response/AKA-Identity                             |
1536           | (AT_IDENTITY containing a fast re-auth. identity)     |
1537           |------------------------------------------------------>|
1538           |                            +------------------------------+
1539           |                            | Server does not recognize    |
1540           |                            | The fast re-auth.            |
1541           |                            | Identity                     |
1542           |                            +------------------------------+
1543           |     EAP-Request/AKA-Identity                          |
1544           |     (AT_FULLAUTH_ID_REQ)                              |
1545           |<------------------------------------------------------|
1546           | EAP-Response/AKA-Identity                             |
1547           | (AT_IDENTITY with a full-auth. Identity)              |
1548           |------------------------------------------------------>|
1549           |                                                       |
1550
1551                 Figure 6: Fall back on full authentication
1552
1553    If the server recognizes the fast re-authentication identity, but
1554    still wants to fall back on full authentication, the server may issue
1555    the EAP-Request/AKA-Challenge packet.  In this case, the full
1556    authentication procedure proceeds as usual.
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570 Arkko & Haverinen            Informational                     [Page 28]
1571 \f
1572 RFC 4187                 EAP-AKA Authentication             January 2006
1573
1574
1575 4.2.3.  Requesting the Permanent Identity 1
1576
1577    Figure 7 illustrates the case when the EAP server fails to decode a
1578    pseudonym identity included in the EAP-Response/Identity packet.
1579
1580        Peer                                             Authenticator
1581           |                               EAP-Request/Identity    |
1582           |<------------------------------------------------------|
1583           | EAP-Response/Identity                                 |
1584           | (Includes a pseudonym)                                |
1585           |------------------------------------------------------>|
1586           |                            +------------------------------+
1587           |                            | Server fails to decode the   |
1588           |                            | Pseudonym.                   |
1589           |                            +------------------------------+
1590           |  EAP-Request/AKA-Identity                             |
1591           |  (AT_PERMANENT_ID_REQ)                                |
1592           |<------------------------------------------------------|
1593           |                                                       |
1594           | EAP-Response/AKA-Identity                             |
1595           | (AT_IDENTITY with permanent identity)                 |
1596           |------------------------------------------------------>|
1597           |                                                       |
1598
1599                Figure 7: Requesting the permanent identity 1
1600
1601    If the server recognizes the permanent identity, then the
1602    authentication sequence proceeds as usual with the EAP Server issuing
1603    the EAP-Request/AKA-Challenge message.
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626 Arkko & Haverinen            Informational                     [Page 29]
1627 \f
1628 RFC 4187                 EAP-AKA Authentication             January 2006
1629
1630
1631 4.2.4.  Requesting the Permanent Identity 2
1632
1633    Figure 8 illustrates the case when the EAP server fails to decode the
1634    pseudonym included in the AT_IDENTITY attribute.
1635
1636        Peer                                             Authenticator
1637           |                                                       |
1638           |                            +------------------------------+
1639           |                            | Server does not have any     |
1640           |                            | Subscriber identity available|
1641           |                            | When starting EAP-AKA        |
1642           |                            +------------------------------+
1643           |        EAP-Request/AKA-Identity                       |
1644           |        (AT_ANY_ID_REQ)                                |
1645           |<------------------------------------------------------|
1646           |                                                       |
1647           |EAP-Response/AKA-Identity                              |
1648           |(AT_IDENTITY with a pseudonym identity)                |
1649           |------------------------------------------------------>|
1650           |                            +------------------------------+
1651           |                            | Server fails to decode the   |
1652           |                            | Pseudonym in AT_IDENTITY     |
1653           |                            +------------------------------+
1654           |                EAP-Request/AKA-Identity               |
1655           |                (AT_PERMANENT_ID_REQ)                  |
1656           |<------------------------------------------------------|
1657           | EAP-Response/AKA-Identity                             |
1658           | (AT_IDENTITY with permanent identity)                 |
1659           |------------------------------------------------------>|
1660           |                                                       |
1661
1662                Figure 8: Requesting the permanent identity 2
1663
1664 4.2.5.  Three EAP/AKA-Identity Round Trips
1665
1666    Figure 9 illustrates the case with three EAP/AKA-Identity round
1667    trips.
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682 Arkko & Haverinen            Informational                     [Page 30]
1683 \f
1684 RFC 4187                 EAP-AKA Authentication             January 2006
1685
1686
1687        Peer                                             Authenticator
1688           |                                                       |
1689           |                            +------------------------------+
1690           |                            | Server does not have any     |
1691           |                            | Subscriber identity available|
1692           |                            | When starting EAP-AKA        |
1693           |                            +------------------------------+
1694           |        EAP-Request/AKA-Identity                       |
1695           |        (AT_ANY_ID_REQ)                                |
1696           |<------------------------------------------------------|
1697           |                                                       |
1698           | EAP-Response/AKA-Identity                             |
1699           | (AT_IDENTITY with fast re-auth. identity)             |
1700           |------------------------------------------------------>|
1701           |                            +------------------------------+
1702           |                            | Server does not accept       |
1703           |                            | The fast re-authentication   |
1704           |                            | Identity                     |
1705           |                            +------------------------------+
1706           |                                                       |
1707           :                                                       :
1708           :                                                       :
1709
1710
1711           :                                                       :
1712           :                                                       :
1713           |     EAP-Request/AKA-Identity                          |
1714           |     (AT_FULLAUTH_ID_REQ)                              |
1715           |<------------------------------------------------------|
1716           |EAP-Response/AKA-Identity                              |
1717           |(AT_IDENTITY with a pseudonym identity)                |
1718           |------------------------------------------------------>|
1719           |                            +------------------------------+
1720           |                            | Server fails to decode the   |
1721           |                            | Pseudonym in AT_IDENTITY     |
1722           |                            +------------------------------+
1723           |           EAP-Request/AKA-Identity                    |
1724           |           (AT_PERMANENT_ID_REQ)                       |
1725           |<------------------------------------------------------|
1726           | EAP-Response/AKA-Identity                             |
1727           | (AT_IDENTITY with permanent identity)                 |
1728           |------------------------------------------------------>|
1729           |                                                       |
1730
1731                    Figure 9: Three EAP-AKA Start rounds
1732
1733    After the last EAP-Response/AKA-Identity message, the full
1734    authentication sequence proceeds as usual.
1735
1736
1737
1738 Arkko & Haverinen            Informational                     [Page 31]
1739 \f
1740 RFC 4187                 EAP-AKA Authentication             January 2006
1741
1742
1743 5.  Fast Re-Authentication
1744
1745 5.1.  General
1746
1747    In some environments, EAP authentication may be performed frequently.
1748    Because the EAP-AKA full authentication procedure uses the AKA
1749    algorithms, and therefore requires fresh authentication vectors from
1750    the Authentication Centre, the full authentication procedure may
1751    result in many network operations when used very frequently.
1752    Therefore, EAP-AKA includes a more inexpensive fast re-authentication
1753    procedure that does not make use of the AKA algorithms and does not
1754    need new vectors from the Authentication Centre.
1755
1756    Fast re-authentication is optional to implement for both the EAP-AKA
1757    server and peer.  On each EAP authentication, either one of the
1758    entities may fall back on full authentication if is does not want to
1759    use fast re-authentication.
1760
1761    Fast re-authentication is based on the keys derived on the preceding
1762    full authentication.  The same K_aut and K_encr keys used in full
1763    authentication are used to protect EAP-AKA packets and attributes,
1764    and the original Master Key from full authentication is used to
1765    generate a fresh Master Session Key, as specified in Section 7.
1766
1767    The fast re-authentication exchange makes use of an unsigned 16-bit
1768    counter, included in the AT_COUNTER attribute.  The counter has three
1769    goals: 1) it can be used to limit the number of successive
1770    reauthentication exchanges without full-authentication 2) it
1771    contributes to the keying material, and 3) it protects the peer and
1772    the server from replays.  On full authentication, both the server and
1773    the peer initialize the counter to one.  The counter value of at
1774    least one is used on the first fast re-authentication.  On subsequent
1775    fast re-authentications, the counter MUST be greater than on any of
1776    the previous fast re-authentications.  For example, on the second
1777    fast re-authentication, counter value is two or greater, etc.  The
1778    AT_COUNTER attribute is encrypted.
1779
1780    Both the peer and the EAP server maintain a copy of the counter.  The
1781    EAP server sends its counter value to the peer in the fast
1782    re-authentication request.  The peer MUST verify that its counter
1783    value is less than or equal to the value sent by the EAP server.
1784
1785    The server includes an encrypted server random nonce (AT_NONCE_S) in
1786    the fast re-authentication request.  The AT_MAC attribute in the
1787    peer's response is calculated over NONCE_S to provide a
1788    challenge/response authentication scheme.  The NONCE_S also
1789    contributes to the new Master Session Key.
1790
1791
1792
1793
1794 Arkko & Haverinen            Informational                     [Page 32]
1795 \f
1796 RFC 4187                 EAP-AKA Authentication             January 2006
1797
1798
1799    Both the peer and the server SHOULD have an upper limit for the
1800    number of subsequent fast re-authentications allowed before a full
1801    authentication needs to be performed.  Because a 16-bit counter is
1802    used in fast re-authentication, the theoretical maximum number of
1803    re-authentications is reached when the counter value reaches FFFF
1804    hexadecimal.  In order to use fast re-authentication, the peer and
1805    the EAP server need to store the following values: Master Key, latest
1806    counter value and the next fast re-authentication identity.  K_aut
1807    and K_encr may either be stored or derived again from MK.  The server
1808    may also need to store the permanent identity of the user.
1809
1810 5.2.  Comparison to AKA
1811
1812    When analyzing the fast re-authentication exchange, it may be helpful
1813    to compare it with the 3rd generation Authentication and Key
1814    Agreement (AKA) exchange used on full authentication.  The counter
1815    corresponds to the AKA sequence number, NONCE_S corresponds to RAND,
1816    the AT_MAC in EAP-Request/AKA-Reauthentication corresponds to AUTN,
1817    the AT_MAC in EAP-Response/AKA-Reauthentication corresponds to RES,
1818    AT_COUNTER_TOO_SMALL corresponds to AUTS, and encrypting the counter
1819    corresponds to the usage of the Anonymity Key.  Also, the key
1820    generation on fast re-authentication, with regard to random or fresh
1821    material, is similar to AKA -- the server generates the NONCE_S and
1822    counter values, and the peer only verifies that the counter value is
1823    fresh.
1824
1825    It should also be noted that encrypting the AT_NONCE_S, AT_COUNTER,
1826    or AT_COUNTER_TOO_SMALL attributes is not important to the security
1827    of the fast re-authentication exchange.
1828
1829 5.3.  Fast Re-Authentication Identity
1830
1831    The fast re-authentication procedure makes use of separate
1832    re-authentication user identities.  Pseudonyms and the permanent
1833    identity are reserved for full authentication only.  If a fast
1834    re-authentication identity is lost and the network does not recognize
1835    it, the EAP server can fall back on full authentication.  If the EAP
1836    server supports fast re-authentication, it MAY include the skippable
1837    AT_NEXT_REAUTH_ID attribute in the encrypted data of EAP- Request/-
1838    AKA-Challenge message.  This attribute contains a new
1839    re-authentication identity for the next fast re-authentication.  The
1840    attribute also works as a capability flag that indicates that the
1841    server supports fast re-authentication and that the server wants to
1842    continue using fast re-authentication within the current context.
1843    The peer MAY ignore this attribute, in which case it will use full
1844    authentication next time.  If the peer wants to use fast
1845    re-authentication, it uses this fast re-authentication identity on
1846    next authentication.  Even if the peer has a fast re-authentication
1847
1848
1849
1850 Arkko & Haverinen            Informational                     [Page 33]
1851 \f
1852 RFC 4187                 EAP-AKA Authentication             January 2006
1853
1854
1855    identity, the peer MAY discard the re-authentication identity and use
1856    a pseudonym or the permanent identity instead, in which case full
1857    authentication MUST be performed.  If the EAP server does not include
1858    the AT_NEXT_REAUTH_ID in the encrypted data of
1859    EAP-Request/AKA-Challenge or EAP-Request/AKA-Reauthentication, then
1860    the peer MUST discard its current fast re-authentication state
1861    information and perform a full authentication next time.
1862
1863    In environments where a realm portion is needed in the peer identity,
1864    the fast re-authentication identity received in AT_NEXT_REAUTH_ID
1865    MUST contain both a username portion and a realm portion, as per the
1866    NAI format.  The EAP Server can choose an appropriate realm part in
1867    order to have the AAA infrastructure route subsequent fast
1868    re-authentication-related requests to the same AAA server.  For
1869    example, the realm part MAY include a portion that is specific to the
1870    AAA server.  Hence, it is sufficient to store the context required
1871    for fast re-authentication in the AAA server that performed the full
1872    authentication.
1873
1874    The peer MAY use the fast re-authentication identity in the
1875    EAP-Response/Identity packet or, in response to the server's
1876    AT_ANY_ID_REQ attribute, the peer MAY use the fast re-authentication
1877    identity in the AT_IDENTITY attribute of the EAP-Response/
1878    AKA-Identity packet.
1879
1880    The peer MUST NOT modify the username portion of the fast
1881    re-authentication identity, but the peer MAY modify the realm portion
1882    or replace it with another realm portion.  The peer might need to
1883    modify the realm in order to influence the AAA routing, for example,
1884    to make sure that the correct server is reached.  It should be noted
1885    that sharing the same fast re-authentication key among several
1886    servers may have security risks, so changing the realm portion of the
1887    NAI in order to change the EAP server is not desirable.
1888
1889    Even if the peer uses a fast re-authentication identity, the server
1890    may want to fall back on full authentication, for example, because
1891    the server does not recognize the fast re-authentication identity or
1892    does not want to use fast re-authentication.  If the server was able
1893    to decode the fast re-authentication identity to the permanent
1894    identity, the server issues the EAP-Request/AKA-Challenge packet to
1895    initiate full authentication.  If the server was not able to recover
1896    the peer's identity from the fast re-authentication identity, the
1897    server starts the full authentication procedure by issuing an
1898    EAP-Request/AKA-Identity packet.  This packet always starts a full
1899    authentication sequence if it does not include the AT_ANY_ID_REQ
1900    attribute.
1901
1902
1903
1904
1905
1906 Arkko & Haverinen            Informational                     [Page 34]
1907 \f
1908 RFC 4187                 EAP-AKA Authentication             January 2006
1909
1910
1911 5.4.  Fast Re-Authentication Procedure
1912
1913    Figure 10 illustrates the fast re-authentication procedure.  In this
1914    example, the optional protected success indication is not used.
1915    Encrypted attributes are denoted with '*'.  The peer uses its fast
1916    re-authentication identity in the EAP-Response/Identity packet.  As
1917    discussed above, an alternative way to communicate the fast
1918    re-authentication identity to the server is for the peer to use the
1919    AT_IDENTITY attribute in the EAP-Response/AKA-Identity message.  This
1920    latter case is not illustrated in the figure below, and it is only
1921    possible when the server requests that the peer send its identity by
1922    including the AT_ANY_ID_REQ attribute in the EAP-Request/AKA-Identity
1923    packet.
1924
1925    If the server recognizes the identity as a valid fast
1926    re-authentication identity, and if the server agrees to use fast
1927    re-authentication, then the server sends the EAP- Request/AKA-
1928    Reauthentication packet to the peer.  This packet MUST include the
1929    encrypted AT_COUNTER attribute, with a fresh counter value, the
1930    encrypted AT_NONCE_S attribute that contains a random number chosen
1931    by the server, the AT_ENCR_DATA and the AT_IV attributes used for
1932    encryption, and the AT_MAC attribute that contains a message
1933    authentication code over the packet.  The packet MAY also include an
1934    encrypted AT_NEXT_REAUTH_ID attribute that contains the next fast
1935    re-authentication identity.
1936
1937    Fast re-authentication identities are one-time identities.  If the
1938    peer does not receive a new fast re-authentication identity, it MUST
1939    use either the permanent identity or a pseudonym identity on the next
1940    authentication to initiate full authentication.
1941
1942    The peer verifies that AT_MAC is correct and that the counter value
1943    is fresh (greater than any previously used value).  The peer MAY save
1944    the next fast re-authentication identity from the encrypted
1945    AT_NEXT_REAUTH_ID for next time.  If all checks are successful, the
1946    peer responds with the EAP-Response/AKA-Reauthentication packet,
1947    including the AT_COUNTER attribute with the same counter value and
1948    the AT_MAC attribute.
1949
1950    The server verifies the AT_MAC attribute and also verifies that the
1951    counter value is the same that it used in the
1952    EAP-Request/AKA-Reauthentication packet.  If these checks are
1953    successful, the fast re-authentication has succeeded and the server
1954    sends the EAP-Success packet to the peer.
1955
1956    If protected success indications (Section 6.2) were used, the
1957    EAP-Success packet would be preceded by an EAP-AKA notification
1958    round.
1959
1960
1961
1962 Arkko & Haverinen            Informational                     [Page 35]
1963 \f
1964 RFC 4187                 EAP-AKA Authentication             January 2006
1965
1966
1967         Peer                                             Authenticator
1968           |                                                       |
1969           |                               EAP-Request/Identity    |
1970           |<------------------------------------------------------|
1971           |                                                       |
1972           | EAP-Response/Identity                                 |
1973           | (Includes a fast re-authentication identity)          |
1974           |------------------------------------------------------>|
1975           |                          +--------------------------------+
1976           |                          | Server recognizes the identity |
1977           |                          | and agrees on using fast       |
1978           |                          | re-authentication              |
1979           |                          +--------------------------------+
1980           |  EAP-Request/AKA-Reauthentication                     |
1981           |  (AT_IV, AT_ENCR_DATA, *AT_COUNTER,                   |
1982           |   *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC)            |
1983           |<------------------------------------------------------|
1984           |                                                       |
1985           :                                                       :
1986           :                                                       :
1987
1988
1989           :                                                       :
1990           :                                                       :
1991           |                                                       |
1992      +-----------------------------------------------+            |
1993      | Peer verifies AT_MAC and the freshness of     |            |
1994      | the counter. Peer MAY store the new re-       |            |
1995      | authentication identity for next re-auth.     |            |
1996      +-----------------------------------------------+            |
1997           |                                                       |
1998           | EAP-Response/AKA-Reauthentication                     |
1999           | (AT_IV, AT_ENCR_DATA, *AT_COUNTER with same value,    |
2000           |  AT_MAC)                                              |
2001           |------------------------------------------------------>|
2002           |                          +--------------------------------+
2003           |                          | Server verifies AT_MAC and     |
2004           |                          | the counter                    |
2005           |                          +--------------------------------+
2006           |                                          EAP-Success  |
2007           |<------------------------------------------------------|
2008           |                                                       |
2009
2010                         Figure 10: Reauthentication
2011
2012
2013
2014
2015
2016
2017
2018 Arkko & Haverinen            Informational                     [Page 36]
2019 \f
2020 RFC 4187                 EAP-AKA Authentication             January 2006
2021
2022
2023 5.5.  Fast Re-Authentication Procedure when Counter is Too Small
2024
2025    If the peer does not accept the counter value of EAP-Request/
2026    AKA-Reauthentication, it indicates the counter synchronization
2027    problem by including the encrypted AT_COUNTER_TOO_SMALL in
2028    EAP-Response/AKA-Reauthentication.  The server responds with
2029    EAP-Request/AKA-Challenge to initiate a normal full authentication
2030    procedure.  This is illustrated in Figure 11.  Encrypted attributes
2031    are denoted with '*'.
2032
2033         Peer                                             Authenticator
2034           |          EAP-Request/AKA-Identity                     |
2035           |          (AT_ANY_ID_REQ)                              |
2036           |<------------------------------------------------------|
2037           |                                                       |
2038           | EAP-Response/AKA-Identity                             |
2039           | (AT_IDENTITY)                                         |
2040           | (Includes a fast re-authentication identity)          |
2041           |------------------------------------------------------>|
2042           |                                                       |
2043           |  EAP-Request/AKA-Reauthentication                     |
2044           |  (AT_IV, AT_ENCR_DATA, *AT_COUNTER,                   |
2045           |   *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC)            |
2046           |<------------------------------------------------------|
2047      +-----------------------------------------------+            |
2048      | AT_MAC is valid but the counter is not fresh. |            |
2049      +-----------------------------------------------+            |
2050           | EAP-Response/AKA-Reauthentication                     |
2051           | (AT_IV, AT_ENCR_DATA, *AT_COUNTER_TOO_SMALL,          |
2052           |  *AT_COUNTER, AT_MAC)                                 |
2053           |------------------------------------------------------>|
2054           |            +----------------------------------------------+
2055           |            | Server verifies AT_MAC but detects           |
2056           |            | That peer has included AT_COUNTER_TOO_SMALL|
2057           |            +----------------------------------------------+
2058           |                        EAP-Request/AKA-Challenge      |
2059           |<------------------------------------------------------|
2060      +---------------------------------------------------------------+
2061      |                Normal full authentication follows.            |
2062      +---------------------------------------------------------------+
2063           |                                                       |
2064
2065             Figure 11: Fast re-authentication counter too small
2066
2067    In the figure above, the first three messages are similar to the
2068    basic fast re-authentication case.  When the peer detects that the
2069    counter value is not fresh, it includes the AT_COUNTER_TOO_SMALL
2070    attribute in EAP-Response/AKA-Reauthentication.  This attribute
2071
2072
2073
2074 Arkko & Haverinen            Informational                     [Page 37]
2075 \f
2076 RFC 4187                 EAP-AKA Authentication             January 2006
2077
2078
2079    doesn't contain any data but it is a request for the server to
2080    initiate full authentication.  In this case, the peer MUST ignore the
2081    contents of the server's AT_NEXT_REAUTH_ID attribute.
2082
2083    On receipt of AT_COUNTER_TOO_SMALL, the server verifies AT_MAC and
2084    verifies that AT_COUNTER contains the same counter value as in the
2085    EAP-Request/AKA-Reauthentication packet.  If not, the server
2086    terminates the authentication exchange by sending the
2087    EAP-Request/AKA-Notification packet with AT_NOTIFICATION code
2088    "General failure" (16384).  If all checks on the packet are
2089    successful, the server transmits an EAP-Request/AKA-Challenge packet
2090    and the full authentication procedure is performed as usual.  Because
2091    the server already knows the subscriber identity, it MUST NOT use the
2092    EAP-Request/AKA-Identity packet to request the identity.
2093
2094    It should be noted that in this case, peer identity is only
2095    transmitted in the AT_IDENTITY attribute at the beginning of the
2096    whole EAP exchange.  The fast re-authentication identity used in this
2097    AT_IDENTITY attribute will be used in key derivation (see Section 7).
2098
2099 6.  EAP-AKA Notifications
2100
2101 6.1.  General
2102
2103    EAP-AKA does not prohibit the use of the EAP Notifications as
2104    specified in [RFC3748].  EAP Notifications can be used at any time in
2105    the EAP-AKA exchange.  It should be noted that EAP-AKA does not
2106    protect EAP Notifications.  EAP-AKA also specifies method-specific
2107    EAP-AKA notifications, which are protected in some cases.
2108
2109    The EAP server can use EAP-AKA notifications to convey notifications
2110    and result indications (Section 6.2) to the peer.
2111
2112    The server MUST use notifications in cases discussed in
2113    Section 6.3.2.  When the EAP server issues an
2114    EAP-Request/AKA-Notification packet to the peer, the peer MUST
2115    process the notification packet.  The peer MAY show a notification
2116    message to the user and the peer MUST respond to the EAP server with
2117    an EAP-Response/AKA-Notification packet, even if the peer did not
2118    recognize the notification code.
2119
2120    An EAP-AKA full authentication exchange or a fast re-authentication
2121    exchange MUST NOT include more than one EAP-AKA notification round.
2122
2123    The notification code is a 16-bit number.  The most significant bit
2124    is called the Success bit (S bit).  The S bit specifies whether the
2125    notification implies failure.  The code values with the S bit set to
2126    zero (code values 0...32767) are used on unsuccessful cases.  The
2127
2128
2129
2130 Arkko & Haverinen            Informational                     [Page 38]
2131 \f
2132 RFC 4187                 EAP-AKA Authentication             January 2006
2133
2134
2135    receipt of a notification code from this range implies failed EAP
2136    exchange, so the peer can use the notification as a failure
2137    indication.  After receiving the EAP-Response/AKA-Notification for
2138    these notification codes, the server MUST send the EAP-Failure
2139    packet.
2140
2141    The receipt of a notification code with the S bit set to one (values
2142    32768...65536) does not imply failure.  Notification code "Success"
2143    (32768) has been reserved as a general notification code to indicate
2144    successful authentication.
2145
2146    The second most significant bit of the notification code is called
2147    the Phase bit (P bit).  It specifies at which phase of the EAP-AKA
2148    exchange the notification can be used.  If the P bit is set to zero,
2149    the notification can only be used after a successful EAP/AKA-
2150    Challenge round in full authentication or a successful EAP/AKA-
2151    Reauthentication round in re-authentication.  A re-authentication
2152    round is considered successful only if the peer has successfully
2153    verified AT_MAC and AT_COUNTER attributes, and does not include the
2154    AT_COUNTER_TOO_SMALL attribute in EAP-Response/AKA-Reauthentication.
2155
2156    If the P bit is set to one, the notification can only by used before
2157    the EAP/AKA-Challenge round in full authentication or before the
2158    EAP/AKA-Reauthentication round in reauthentication.  These
2159    notifications can only be used to indicate various failure cases.  In
2160    other words, if the P bit is set to one, then the S bit MUST be set
2161    to zero.
2162
2163    Section 9.10 and Section 9.11 specify what other attributes must be
2164    included in the notification packets.
2165
2166    Some of the notification codes are authorization related and hence
2167    not usually considered as part of the responsibility of an EAP
2168    method.  However, they are included as part of EAP-AKA because there
2169    are currently no other ways to convey this information to the user in
2170    a localizable way, and the information is potentially useful for the
2171    user.  An EAP-AKA server implementation may decide never to send
2172    these EAP-AKA notifications.
2173
2174 6.2.  Result Indications
2175
2176    As discussed in Section 6.3, the server and the peer use explicit
2177    error messages in all error cases.  If the server detects an error
2178    after successful authentication, the server uses an EAP-AKA
2179    notification to indicate failure to the peer.  In this case, the
2180    result indication is integrity and replay protected.
2181
2182
2183
2184
2185
2186 Arkko & Haverinen            Informational                     [Page 39]
2187 \f
2188 RFC 4187                 EAP-AKA Authentication             January 2006
2189
2190
2191    By sending an EAP-Response/AKA-Challenge packet or an
2192    EAP-Response/AKA-Reauthentication packet (without
2193    AT_COUNTER_TOO_SMALL), the peer indicates that it has successfully
2194    authenticated the server and that the peer's local policy accepts the
2195    EAP exchange.  In other words, these packets are implicit success
2196    indications from the peer to the server.
2197
2198    EAP-AKA also supports optional protected success indications from the
2199    server to the peer.  If the EAP server wants to use protected success
2200    indications, it includes the AT_RESULT_IND attribute in the
2201    EAP-Request/AKA-Challenge or the EAP-Request/AKA-Reauthentication
2202    packet.  This attribute indicates that the EAP server would like to
2203    use result indications in both successful and unsuccessful cases.  If
2204    the peer also wants this, the peer includes AT_RESULT_IND in
2205    EAP-Response/AKA-Challenge or EAP-Response/AKA-Reauthentication.  The
2206    peer MUST NOT include AT_RESULT_IND if it did not receive
2207    AT_RESULT_IND from the server.  If both the peer and the server used
2208    AT_RESULT_IND, then the EAP exchange is not complete yet, but an
2209    EAP-AKA notification round will follow.  The following EAP-AKA
2210    notification may indicate either failure or success.
2211
2212    Success indications with the AT_NOTIFICATION code "Success" (32768)
2213    can only be used if both the server and the peer indicate they want
2214    to use them with AT_RESULT_IND.  If the server did not include
2215    AT_RESULT_IND in the EAP-Request/AKA-Challenge or
2216    EAP-Request/AKA-Reauthentication packet, or if the peer did not
2217    include AT_RESULT_IND in the corresponding response packet, then the
2218    server MUST NOT use protected success indications.
2219
2220    Because the server uses the AT_NOTIFICATION code "Success" (32768) to
2221    indicate that the EAP exchange has completed successfully, the EAP
2222    exchange cannot fail when the server processes the EAP-AKA response
2223    to this notification.  Hence, the server MUST ignore the contents of
2224    the EAP-AKA response it receives to the EAP-Request/AKA-Notification
2225    with this code.  Regardless of the contents of the EAP-AKA response,
2226    the server MUST send EAP-Success as the next packet.
2227
2228 6.3.  Error Cases
2229
2230    This section specifies the operation of the peer and the server in
2231    error cases.  The subsections below require the EAP-AKA peer and
2232    server to send an error packet (EAP-Response/AKA-Client-Error,
2233    EAP-Response/AKA-Authentication-Reject or
2234    EAP-Response/AKA-Synchronization-Failure from the peer and
2235    EAP-Request/AKA-Notification from the server) in error cases.
2236    However, implementations SHOULD NOT rely upon the correct error
2237    reporting behavior of the peer, authenticator, or server.  It is
2238    possible for error messages and other messages to be lost in transit,
2239
2240
2241
2242 Arkko & Haverinen            Informational                     [Page 40]
2243 \f
2244 RFC 4187                 EAP-AKA Authentication             January 2006
2245
2246
2247    or for a malicious participant to attempt to consume resources by not
2248    issuing error messages.  Both the peer and the EAP server SHOULD have
2249    a mechanism to clean up state even if an error message or EAP-Success
2250    is not received after a timeout period.
2251
2252 6.3.1.  Peer Operation
2253
2254    Two special error messages have been specified for error cases that
2255    are related to the processing of the AKA AUTN parameter, as described
2256    in Section 3: (1) if the peer does not accept AUTN, the peer responds
2257    with EAP-Response/AKA-Authentication-Reject (Section 9.5), and the
2258    server issues EAP-Failure, and (2) if the peer detects that the
2259    sequence number in AUTN is not correct, the peer responds with
2260    EAP-Response/AKA-Synchronization-Failure (Section 9.6), and the
2261    server proceeds with a new EAP-Request/AKA-Challenge.
2262
2263    In other error cases, when an EAP-AKA peer detects an error in a
2264    received EAP-AKA packet, the EAP-AKA peer responds with the
2265    EAP-Response/AKA-Client-Error packet.  In response to the
2266    EAP-Response/AKA-Client-Error, the EAP server MUST issue the
2267    EAP-Failure packet, and the authentication exchange terminates.
2268
2269    By default, the peer uses the client error code 0, "unable to process
2270    packet".  This error code is used in the following cases:
2271
2272    o  EAP exchange is not acceptable according to the peer's local
2273       policy.
2274    o  The peer is not able to parse the EAP request, i.e., the EAP
2275       request is malformed.
2276    o  The peer encountered a malformed attribute.
2277    o  Wrong attribute types or duplicate attributes have been included
2278       in the EAP request.
2279    o  A mandatory attribute is missing.
2280    o  Unrecognized non-skippable attribute.
2281    o  Unrecognized or unexpected EAP-AKA Subtype in the EAP request.
2282    o  Invalid AT_MAC.  The peer SHOULD log this event.
2283    o  Invalid AT_CHECKCODE.  The peer SHOULD log this event.
2284    o  Invalid pad bytes in AT_PADDING.
2285    o  The peer does not want to process AT_PERMANENT_ID_REQ.
2286
2287 6.3.2.  Server Operation
2288
2289    If an EAP-AKA server detects an error in a received EAP-AKA response,
2290    the server MUST issue the EAP-Request/AKA-Notification packet with an
2291    AT_NOTIFICATION code that implies failure.  By default, the server
2292    uses one of the general failure codes ("General failure after
2293    authentication" (0) or "General failure" (16384)).  The choice
2294
2295
2296
2297
2298 Arkko & Haverinen            Informational                     [Page 41]
2299 \f
2300 RFC 4187                 EAP-AKA Authentication             January 2006
2301
2302
2303    between these two codes depends on the phase of the EAP-AKA exchange,
2304    see Section 6.  The error cases when the server issues an
2305    EAP-Request/AKA-Notification that implies failure include the
2306    following:
2307
2308    o  The server is not able to parse the peer's EAP response.
2309    o  The server encounters a malformed attribute, a non-recognized
2310       non-skippable attribute, or a duplicate attribute.
2311    o  A mandatory attribute is missing or an invalid attribute was
2312       included.
2313    o  Unrecognized or unexpected EAP-AKA Subtype in the EAP Response.
2314    o  Invalid AT_MAC.  The server SHOULD log this event.
2315    o  Invalid AT_CHECKCODE.  The server SHOULD log this event.
2316    o  Invalid AT_COUNTER.
2317
2318 6.3.3.  EAP-Failure
2319
2320    The EAP-AKA server sends EAP-Failure in three cases:
2321
2322    1.  In response to an EAP-Response/AKA-Client-Error packet the server
2323        has received from the peer, or
2324
2325    2.  In response to an EAP-Response/AKA-Authentication-Reject packet
2326        the server has received from the peer, or
2327
2328    3.  Following an EAP-AKA notification round, when the AT_NOTIFICATION
2329        code implies failure.
2330
2331    The EAP-AKA server MUST NOT send EAP-Failure in other cases than
2332    these three.  However, it should be noted that even though the
2333    EAP-AKA server would not send an EAP-Failure, an authorization
2334    decision that happens outside EAP-AKA, such as in the AAA server or
2335    in an intermediate AAA proxy, may result in a failed exchange.
2336
2337    The peer MUST accept the EAP-Failure packet in case 1), case 2), and
2338    case 3) above.  The peer SHOULD silently discard the EAP-Failure
2339    packet in other cases.
2340
2341 6.3.4.  EAP-Success
2342
2343    On full authentication, the server can only send EAP-Success after
2344    the EAP/AKA-Challenge round.  The peer MUST silently discard any
2345    EAP-Success packets if they are received before the peer has
2346    successfully authenticated the server and sent the
2347    EAP-Response/AKA-Challenge packet.
2348
2349
2350
2351
2352
2353
2354 Arkko & Haverinen            Informational                     [Page 42]
2355 \f
2356 RFC 4187                 EAP-AKA Authentication             January 2006
2357
2358
2359    If the peer did not indicate that it wants to use protected success
2360    indications with AT_RESULT_IND (as discussed in Section 6.2) on full
2361    authentication, then the peer MUST accept EAP-Success after a
2362    successful EAP/AKA-Challenge round.
2363
2364    If the peer indicated that it wants to use protected success
2365    indications with AT_RESULT_IND (as discussed in Section 6.2), then
2366    the peer MUST NOT accept EAP-Success after a successful EAP/
2367    AKA-Challenge round.  In this case, the peer MUST only accept
2368    EAP-Success after receiving an EAP-AKA Notification with the
2369    AT_NOTIFICATION code "Success" (32768).
2370
2371    On fast re-authentication, EAP-Success can only be sent after the
2372    EAP/AKA-Reauthentication round.  The peer MUST silently discard any
2373    EAP-Success packets if they are received before the peer has
2374    successfully authenticated the server and sent the
2375    EAP-Response/AKA-Reauthentication packet.
2376
2377    If the peer did not indicate that it wants to use protected success
2378    indications with AT_RESULT_IND (as discussed in Section 6.2) on fast
2379    re-authentication, then the peer MUST accept EAP-Success after a
2380    successful EAP/AKA-Reauthentication round.
2381
2382    If the peer indicated that it wants to use protected success
2383    indications with AT_RESULT_IND (as discussed in Section 6.2), then
2384    the peer MUST NOT accept EAP-Success after a successful EAP/AKA-
2385    Reauthentication round.  In this case, the peer MUST only accept
2386    EAP-Success after receiving an EAP-AKA Notification with the
2387    AT_NOTIFICATION code "Success" (32768).
2388
2389    If the peer receives an EAP-AKA notification (Section 6) that
2390    indicates failure, then the peer MUST no longer accept the
2391    EAP-Success packet, even if the server authentication was
2392    successfully completed.
2393
2394 7.  Key Generation
2395
2396    This section specifies how keying material is generated.
2397
2398    On EAP-AKA full authentication, a Master Key (MK) is derived from the
2399    underlying AKA values (CK and IK keys), and the identity, as follows.
2400
2401    MK = SHA1(Identity|IK|CK)
2402
2403    In the formula above, the "|" character denotes concatenation.
2404    Identity denotes the peer identity string without any terminating
2405    null characters.  It is the identity from the last AT_IDENTITY
2406    attribute sent by the peer in this exchange, or, if AT_IDENTITY was
2407
2408
2409
2410 Arkko & Haverinen            Informational                     [Page 43]
2411 \f
2412 RFC 4187                 EAP-AKA Authentication             January 2006
2413
2414
2415    not used, the identity from the EAP-Response/Identity packet.  The
2416    identity string is included as-is, without any changes.  As discussed
2417    in Section 4.1.2.2, relying on EAP-Response/Identity for conveying
2418    the EAP-AKA peer identity is discouraged, and the server SHOULD use
2419    the EAP-AKA method-specific identity attributes.  The hash function
2420    SHA-1 is specified in [SHA-1].
2421
2422    The Master Key is fed into a Pseudo-Random number Function (PRF),
2423    which generates separate Transient EAP Keys (TEKs) for protecting
2424    EAP-AKA packets, as well as a Master Session Key (MSK) for link layer
2425    security and an Extended Master Session Key (EMSK) for other
2426    purposes.  On fast re-authentication, the same TEKs MUST be used for
2427    protecting EAP packets, but a new MSK and a new EMSK MUST be derived
2428    from the original MK and from new values exchanged in the fast
2429    re-authentication.
2430
2431    EAP-AKA requires two TEKs for its own purposes: the authentication
2432    key K_aut, to be used with the AT_MAC attribute, and the encryption
2433    key K_encr, to be used with the AT_ENCR_DATA attribute.  The same
2434    K_aut and K_encr keys are used in full authentication and subsequent
2435    fast re-authentications.
2436
2437    Key derivation is based on the random number generation specified in
2438    NIST Federal Information Processing Standards (FIPS) Publication
2439    186-2 [PRF].  The pseudo-random number generator is specified in the
2440    change notice 1 (2001 October 5) of [PRF] (Algorithm 1).  As
2441    specified in the change notice (page 74), when Algorithm 1 is used as
2442    a general-purpose pseudo-random number generator, the "mod q" term in
2443    step 3.3 is omitted.  The function G used in the algorithm is
2444    constructed via Secure Hash Standard as specified in Appendix 3.3 of
2445    the standard.  It should be noted that the function G is very similar
2446    to SHA-1, but the message padding is different.  Please refer to
2447    [PRF] for full details.  For convenience, the random number algorithm
2448    with the correct modification is cited in Annex A.
2449
2450    160-bit XKEY and XVAL values are used, so b = 160.  On each full
2451    authentication, the Master Key is used as the initial secret seed-key
2452    XKEY.  The optional user input values (XSEED_j) in step 3.1 are set
2453    to zero.
2454
2455    On full authentication, the resulting 320-bit random numbers x_0,
2456    x_1, ..., x_m-1 are concatenated and partitioned into suitable-sized
2457    chunks and used as keys in the following order: K_encr (128 bits),
2458    K_aut (128 bits), Master Session Key (64 bytes), Extended Master
2459    Session Key (64 bytes).
2460
2461
2462
2463
2464
2465
2466 Arkko & Haverinen            Informational                     [Page 44]
2467 \f
2468 RFC 4187                 EAP-AKA Authentication             January 2006
2469
2470
2471    On fast re-authentication, the same pseudo-random number generator
2472    can be used to generate a new Master Session Key and a new Extended
2473    Master Session Key.  The seed value XKEY' is calculated as follows:
2474
2475    XKEY' = SHA1(Identity|counter|NONCE_S| MK)
2476
2477    In the formula above, the Identity denotes the fast re-authentication
2478    identity, without any terminating null characters, from the
2479    AT_IDENTITY attribute of the EAP-Response/AKA-Identity packet, or, if
2480    EAP-Response/AKA-Identity was not used on fast re-authentication, it
2481    denotes the identity string from the EAP-Response/Identity packet.
2482    The counter denotes the counter value from the AT_COUNTER attribute
2483    used in the EAP-Response/AKA-Reauthentication packet.  The counter is
2484    used in network byte order.  NONCE_S denotes the 16-byte random
2485    NONCE_S value from the AT_NONCE_S attribute used in the
2486    EAP-Request/AKA-Reauthentication packet.  The MK is the Master Key
2487    derived on the preceding full authentication.
2488
2489    On fast re-authentication, the pseudo-random number generator is run
2490    with the new seed value XKEY', and the resulting 320-bit random
2491    numbers x_0, x_1, ..., x_m-1 are concatenated and partitioned into
2492    64-byte chunks and used as the new 64-byte Master Session Key and the
2493    new 64-byte Extended Master Session Key.  Note that because K_encr
2494    and K_aut are not derived on fast re-authentication, the Master
2495    Session Key and the Extended Master Session key are obtained from the
2496    beginning of the key stream x_0, x_1, ....
2497
2498    The first 32 bytes of the MSK can be used as the Pairwise Master Key
2499    (PMK) for IEEE 802.11i.
2500
2501    When the RADIUS attributes specified in [RFC2548] are used to
2502    transport keying material, then the first 32 bytes of the MSK
2503    correspond to MS-MPPE-RECV-KEY and the second 32 bytes to
2504    MS-MPPE-SEND-KEY.  In this case, only 64 bytes of keying material
2505    (the MSK) are used.
2506
2507 8.  Message Format and Protocol Extensibility
2508
2509 8.1.  Message Format
2510
2511    As specified in [RFC3748], EAP packets begin with the Code,
2512    Identifiers, Length, and Type fields, which are followed by
2513    EAP-method-specific Type-Data.  The Code field in the EAP header is
2514    set to 1 for EAP requests, and to 2 for EAP Responses.  The usage of
2515    the Length and Identifier fields in the EAP header is also specified
2516    in [RFC3748].  In EAP-AKA, the Type field is set to 23.
2517
2518
2519
2520
2521
2522 Arkko & Haverinen            Informational                     [Page 45]
2523 \f
2524 RFC 4187                 EAP-AKA Authentication             January 2006
2525
2526
2527    In EAP-AKA, the Type-Data begins with an EAP-AKA header that consists
2528    of a 1-octet Subtype field, and a 2-octet reserved field.  The
2529    Subtype values used in EAP-AKA are defined in Section 11.  The
2530    formats of the EAP header and the EAP-AKA header are shown below.
2531
2532     0                   1                   2                   3
2533     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
2534    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2535    |     Code      |  Identifier   |            Length             |
2536    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2537    |     Type      |    Subtype    |           Reserved            |
2538    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2539
2540    The rest of the Type-Data, immediately following the EAP-AKA header,
2541    consists of attributes that are encoded in Type, Length, Value
2542    format.  The figure below shows the generic format of an attribute.
2543
2544     0                   1                   2                   3
2545     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
2546    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2547    |Attribute Type |    Length     | Value...
2548    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2549
2550    Attribute Type
2551
2552          Indicates the particular type of attribute.  The attribute type
2553          values are listed in Section 11.
2554
2555    Length
2556
2557          Indicates the length of this attribute in multiples of 4 bytes.
2558          The maximum length of an attribute is 1024 bytes.  The length
2559          includes the Attribute Type and Length bytes.
2560
2561    Value
2562
2563          The particular data associated with this attribute.  This field
2564          is always included and it is two or more bytes in length.  The
2565          type and length fields determine the format and length of the
2566          value field.
2567
2568    Attributes numbered within the range 0 through 127 are called
2569    non-skippable attributes.  When an EAP-AKA peer encounters a
2570    non-skippable attribute type that the peer does not recognize, the
2571    peer MUST send the EAP-Response/AKA-Client-Error packet, and the
2572    authentication exchange terminates.  If an EAP-AKA server encounters
2573    a non-skippable attribute that the server does not recognize, then
2574    the server sends EAP-Request/AKA-Notification packet with an
2575
2576
2577
2578 Arkko & Haverinen            Informational                     [Page 46]
2579 \f
2580 RFC 4187                 EAP-AKA Authentication             January 2006
2581
2582
2583    AT_NOTIFICATION code that implies general failure ("General failure
2584    after authentication" (0), or "General failure" (16384), depending on
2585    the phase of the exchange), and the authentication exchange
2586    terminates.
2587
2588    When an attribute numbered in the range 128 through 255 is
2589    encountered but not recognized, that particular attribute is ignored,
2590    but the rest of the attributes and message data MUST still be
2591    processed.  The Length field of the attribute is used to skip the
2592    attribute value when searching for the next attribute.  These
2593    attributes are called skippable attributes.
2594
2595    Unless otherwise specified, the order of the attributes in an EAP-AKA
2596    message is insignificant, and an EAP-AKA implementation should not
2597    assume a certain order will be used.
2598
2599    Attributes can be encapsulated within other attributes.  In other
2600    words, the value field of an attribute type can be specified to
2601    contain other attributes.
2602
2603 8.2.  Protocol Extensibility
2604
2605    EAP-AKA can be extended by specifying new attribute types.  If
2606    skippable attributes are used, it is possible to extend the protocol
2607    without breaking old implementations.  As specified in Section 10.13,
2608    if new attributes are specified for EAP-Request/AKA-Identity or
2609    EAP-Response/AKA-Identity, then the AT_CHECKCODE MUST be used to
2610    integrity protect the new attributes.
2611
2612    When specifying new attributes, it should be noted that EAP-AKA does
2613    not support message fragmentation.  Hence, the sizes of the new
2614    extensions MUST be limited so that the maximum transfer unit (MTU) of
2615    the underlying lower layer is not exceeded.  According to [RFC3748],
2616    lower layers must provide an EAP MTU of 1020 bytes or greater, so any
2617    extensions to EAP-AKA SHOULD NOT exceed the EAP MTU of 1020 bytes.
2618
2619    EAP-AKA packets do not include a version field.  However, should
2620    there be a reason to revise this protocol in the future, new
2621    non-skippable or skippable attributes could be specified in order to
2622    implement revised EAP-AKA versions in a backward-compatible manner.
2623    It is possible to introduce version negotiation in the
2624    EAP-Request/AKA-Identity and EAP-Response/AKA-Identity messages by
2625    specifying new skippable attributes.
2626
2627
2628
2629
2630
2631
2632
2633
2634 Arkko & Haverinen            Informational                     [Page 47]
2635 \f
2636 RFC 4187                 EAP-AKA Authentication             January 2006
2637
2638
2639 9.  Messages
2640
2641    This section specifies the messages used in EAP-AKA.  It specifies
2642    when a message may be transmitted or accepted, which attributes are
2643    allowed in a message, which attributes are required in a message, and
2644    other message-specific details.  Message format is specified in
2645    Section 8.1.
2646
2647 9.1.  EAP-Request/AKA-Identity
2648
2649    The EAP/AKA-Identity roundtrip MAY be used for obtaining the peer
2650    identity from the server.  As discussed in Section 4.1, several
2651    AKA-Identity rounds may be required in order to obtain a valid peer
2652    identity.
2653
2654    The server MUST include one of the following identity requesting
2655    attributes: AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, AT_ANY_ID_REQ.
2656    These three attributes are mutually exclusive, so the server MUST NOT
2657    include more than one of the attributes.
2658
2659    If the server has previously issued an EAP-Request/AKA-Identity
2660    message with the AT_PERMANENT_ID_REQ attribute, and if the server has
2661    received a response from the peer, then the server MUST NOT issue a
2662    new EAP-Request/AKA-Identity packet.
2663
2664    If the server has previously issued an EAP-Request/AKA-Identity
2665    message with the AT_FULLAUTH_ID_REQ attribute, and if the server has
2666    received a response from the peer, then the server MUST NOT issue a
2667    new EAP-Request/AKA-Identity packet with the AT_ANY_ID_REQ or
2668    AT_FULLAUTH_ID_REQ attributes.
2669
2670    If the server has previously issued an EAP-Request/AKA-Identity
2671    message with the AT_ANY_ID_REQ attribute, and if the server has
2672    received a response from the peer, then the server MUST NOT issue a
2673    new EAP-Request/AKA-Identity packet with the AT_ANY_ID_REQ.
2674
2675    This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA.
2676
2677 9.2.  EAP-Response/AKA-Identity
2678
2679    The peer sends EAP-Response/AKA-Identity in response to a valid
2680    EAP-Request/AKA-Identity from the server.
2681
2682    The peer MUST include the AT_IDENTITY attribute.  The usage of
2683    AT_IDENTITY is defined in Section 4.1.
2684
2685    This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA.
2686
2687
2688
2689
2690 Arkko & Haverinen            Informational                     [Page 48]
2691 \f
2692 RFC 4187                 EAP-AKA Authentication             January 2006
2693
2694
2695 9.3.  EAP-Request/AKA-Challenge
2696
2697    The server sends the EAP-Request/AKA-Challenge on full authentication
2698    after successfully obtaining the subscriber identity.
2699
2700    The AT_RAND attribute MUST be included.
2701
2702    AT_MAC MUST be included.  In EAP-Request/AKA-Challenge, there is no
2703    message-specific data covered by the MAC, see Section 10.15.
2704
2705    The AT_RESULT_IND attribute MAY be included.  The usage of this
2706    attribute is discussed in Section 6.2.
2707
2708    The AT_CHECKCODE attribute MAY be included, and in certain cases
2709    specified in Section 10.13, it MUST be included.
2710
2711    The EAP-Request/AKA-Challenge packet MAY include encrypted attributes
2712    for identity privacy and for communicating the next re-authentication
2713    identity.  In this case, the AT_IV and AT_ENCR_DATA attributes are
2714    included (Section 10.12).
2715
2716    The plaintext of the AT_ENCR_DATA value field consists of nested
2717    attributes.  The nested attributes MAY include AT_PADDING (as
2718    specified in Section 10.12).  If the server supports identity privacy
2719    and wants to communicate a pseudonym to the peer for the next full
2720    authentication, then the nested encrypted attributes include the
2721    AT_NEXT_PSEUDONYM attribute.  If the server supports
2722    re-authentication and wants to communicate a fast re-authentication
2723    identity to the peer, then the nested encrypted attributes include
2724    the AT_NEXT_REAUTH_ID attribute.  Later versions of this protocol MAY
2725    specify additional attributes to be included within the encrypted
2726    data.
2727
2728    When processing this message, the peer MUST process AT_RAND and
2729    AT_AUTN before processing other attributes.  Only if these attributes
2730    are verified to be valid, the peer derives keys and verifies AT_MAC.
2731    The operation in case an error occurs is specified in Section 6.3.1.
2732
2733 9.4.  EAP-Response/AKA-Challenge
2734
2735    The peer sends EAP-Response/AKA-Challenge in response to a valid
2736    EAP-Request/AKA-Challenge.
2737
2738    Sending this packet indicates that the peer has successfully
2739    authenticated the server and that the EAP exchange will be accepted
2740    by the peer's local policy.  Hence, if these conditions are not met,
2741    then the peer MUST NOT send EAP-Response/AKA-Challenge, but the peer
2742    MUST send EAP-Response/AKA-Client-Error.
2743
2744
2745
2746 Arkko & Haverinen            Informational                     [Page 49]
2747 \f
2748 RFC 4187                 EAP-AKA Authentication             January 2006
2749
2750
2751    The AT_MAC attribute MUST be included.  In
2752    EAP-Response/AKA-Challenge, there is no message-specific data covered
2753    by the MAC, see Section 10.15.
2754
2755    The AT_RES attribute MUST be included.
2756
2757    The AT_CHECKCODE attribute MAY be included, and in certain cases
2758    specified in Section 10.13, it MUST be included.
2759
2760    The AT_RESULT_IND attribute MAY be included, if it was included in
2761    EAP-Request/AKA-Challenge.  The usage of this attribute is discussed
2762    in Section 6.2.
2763
2764    Later versions of this protocol MAY make use of the AT_ENCR_DATA and
2765    AT_IV attributes in this message to include encrypted (skippable)
2766    attributes.  The EAP server MUST process EAP-Response/AKA-Challenge
2767    messages that include these attributes even if the server did not
2768    implement these optional attributes.
2769
2770 9.5.  EAP-Response/AKA-Authentication-Reject
2771
2772    The peer sends the EAP-Response/AKA-Authentication-Reject packet if
2773    it does not accept the AUTN parameter.  This version of the protocol
2774    does not specify any attributes for this message.  Future versions of
2775    the protocol MAY specify attributes for this message.
2776
2777    The AT_MAC, AT_ENCR_DATA, or AT_IV attributes MUST NOT be used in
2778    this message.
2779
2780 9.6.  EAP-Response/AKA-Synchronization-Failure
2781
2782    The peer sends the EAP-Response/AKA-Synchronization-Failure, when the
2783    sequence number in the AUTN parameter is incorrect.
2784
2785    The peer MUST include the AT_AUTS attribute.  Future versions of the
2786    protocol MAY specify other additional attributes for this message.
2787
2788    The AT_MAC, AT_ENCR_DATA, or AT_IV attributes MUST NOT be used in
2789    this message.
2790
2791 9.7.  EAP-Request/AKA-Reauthentication
2792
2793    The server sends the EAP-Request/AKA-Reauthentication message if it
2794    wants to use fast re-authentication, and if it has received a valid
2795    fast re-authentication identity in EAP-Response/Identity or
2796    EAP-Response/AKA-Identity.
2797
2798
2799
2800
2801
2802 Arkko & Haverinen            Informational                     [Page 50]
2803 \f
2804 RFC 4187                 EAP-AKA Authentication             January 2006
2805
2806
2807    The AT_MAC attribute MUST be included.  No message-specific data is
2808    included in the MAC calculation, see Section 10.15.
2809
2810    The AT_RESULT_IND attribute MAY be included.  The usage of this
2811    attribute is discussed in Section 6.2.
2812
2813    The AT_CHECKCODE attribute MAY be included, and in certain cases
2814    specified in Section 10.13, it MUST be included.
2815
2816    The AT_IV and AT_ENCR_DATA attributes MUST be included.  The
2817    plaintext consists of the following nested encrypted attributes,
2818    which MUST be included: AT_COUNTER and AT_NONCE_S.  In addition, the
2819    nested encrypted attributes MAY include the following attributes:
2820    AT_NEXT_REAUTH_ID and AT_PADDING.
2821
2822 9.8.  EAP-Response/AKA-Reauthentication
2823
2824    The client sends the EAP-Response/AKA-Reauthentication packet in
2825    response to a valid EAP-Request/AKA-Reauthentication.
2826
2827    The AT_MAC attribute MUST be included.  For
2828    EAP-Response/AKA-Reauthentication, the MAC code is calculated over
2829    the following data:  EAP packet| NONCE_S.  The EAP packet is
2830    represented as specified in Section 8.1.  It is followed by the
2831    16-byte NONCE_S value from the server's AT_NONCE_S attribute.
2832
2833    The AT_CHECKCODE attribute MAY be included, and in certain cases
2834    specified in Section 10.13, it MUST be included.
2835
2836    The AT_IV and AT_ENCR_DATA attributes MUST be included.  The nested
2837    encrypted attributes MUST include the AT_COUNTER attribute.  The
2838    AT_COUNTER_TOO_SMALL attribute MAY be included in the nested
2839    encrypted attributes, and it is included in cases specified in
2840    Section 5.  The AT_PADDING attribute MAY be included.
2841
2842    The AT_RESULT_IND attribute MAY be included, if it was included in
2843    EAP-Request/AKA-Reauthentication.  The usage of this attribute is
2844    discussed in Section 6.2.
2845
2846    Sending this packet without AT_COUNTER_TOO_SMALL indicates that the
2847    peer has successfully authenticated the server and that the EAP
2848    exchange will be accepted by the peer's local policy.  Hence, if
2849    these conditions are not met, then the peer MUST NOT send
2850    EAP-Response/AKA-Reauthentication, but the peer MUST send
2851    EAP-Response/ AKA-Client-Error.
2852
2853
2854
2855
2856
2857
2858 Arkko & Haverinen            Informational                     [Page 51]
2859 \f
2860 RFC 4187                 EAP-AKA Authentication             January 2006
2861
2862
2863 9.9.  EAP-Response/AKA-Client-Error
2864
2865    The peer sends EAP-Response/AKA-Client-Error in error cases, as
2866    specified in Section 6.3.1.
2867
2868    The AT_CLIENT_ERROR_CODE attribute MUST be included.  The AT_MAC,
2869    AT_IV, or AT_ENCR_DATA attributes MUST NOT be used with this packet.
2870
2871 9.10.  EAP-Request/AKA-Notification
2872
2873    The usage of this message is specified in Section 6.
2874
2875    The AT_NOTIFICATION attribute MUST be included.
2876
2877    The AT_MAC attribute MUST be included if the P bit of the
2878    AT_NOTIFICATION code is set to zero, and MUST NOT be included if the
2879    P bit is set to one.  The P bit is discussed in Section 6.
2880
2881    No message-specific data is included in the MAC calculation.  See
2882    Section 10.15.
2883
2884    If EAP-Request/AKA-Notification is used on a fast re-authentication
2885    exchange, and if the P bit in AT_NOTIFICATION is set to zero, then
2886    AT_COUNTER is used for replay protection.  In this case, the
2887    AT_ENCR_DATA and AT_IV attributes MUST be included, and the
2888    encapsulated plaintext attributes MUST include the AT_COUNTER
2889    attribute.  The counter value included in AT_COUNTER MUST be the same
2890    as in the EAP-Request/AKA-Reauthentication packet on the same fast
2891    re-authentication exchange.
2892
2893 9.11.  EAP-Response/AKA-Notification
2894
2895    The usage of this message is specified in Section 6.  This packet is
2896    an acknowledgement of EAP-Request/AKA-Notification.
2897
2898    The AT_MAC attribute MUST be included in cases when the P bit of the
2899    notification code in AT_NOTIFICATION of EAP-Request/AKA-Notification
2900    is set to zero, and MUST NOT be included in cases when the P bit is
2901    set to one.  The P bit is discussed in Section 6.
2902
2903    If EAP-Request/AKA-Notification is used on a fast re-authentication
2904    exchange, and if the P bit in AT_NOTIFICATION is set to zero, then
2905    AT_COUNTER is used for replay protection.  In this case, the
2906    AT_ENCR_DATA and AT_IV attributes MUST be included, and the
2907    encapsulated plaintext attributes MUST include the AT_COUNTER
2908    attribute.  The counter value included in AT_COUNTER MUST be the same
2909    as in the EAP-Request/AKA-Reauthentication packet on the same fast
2910    re-authentication exchange.
2911
2912
2913
2914 Arkko & Haverinen            Informational                     [Page 52]
2915 \f
2916 RFC 4187                 EAP-AKA Authentication             January 2006
2917
2918
2919 10.  Attributes
2920
2921    This section specifies the format of message attributes.  The
2922    attribute type numbers are specified in Section 11.
2923
2924 10.1.  Table of Attributes
2925
2926    The following table provides a guide to which attributes may be found
2927    in which kinds of messages, and in what quantity.  Messages are
2928    denoted with numbers in parentheses as follows: (1) EAP-Request/
2929    AKA-Identity, (2) EAP-Response/AKA-Identity, (3) EAP-Request/
2930    AKA-Challenge, (4) EAP-Response/AKA-Challenge, (5) EAP-Request/
2931    AKA-Notification, (6) EAP-Response/AKA-Notification, (7) EAP-
2932    Response/AKA-Client-Error (8) EAP-Request/AKA-Reauthentication, (9)
2933    EAP-Response/AKA-Reauthentication, (10) EAP-Response/AKA-
2934    Authentication-Reject, and (11) EAP-Response/AKA-Synchronization-
2935    Failure.  The column denoted with "E" indicates whether the attribute
2936    is a nested attribute that MUST be included within AT_ENCR_DATA.
2937
2938    "0" indicates that the attribute MUST NOT be included in the message,
2939    "1" indicates that the attribute MUST be included in the message,
2940    "0-1" indicates that the attribute is sometimes included in the
2941    message, and "0*" indicates that the attribute is not included in the
2942    message in cases specified in this document, but MAY be included in
2943    the future versions of the protocol.
2944
2945               Attribute (1) (2) (3) (4) (5) (6) (7) (8) (9) (10)(11) E
2946     AT_PERMANENT_ID_REQ 0-1  0   0   0   0   0   0   0   0   0   0   N
2947           AT_ANY_ID_REQ 0-1  0   0   0   0   0   0   0   0   0   0   N
2948      AT_FULLAUTH_ID_REQ 0-1  0   0   0   0   0   0   0   0   0   0   N
2949             AT_IDENTITY  0  0-1  0   0   0   0   0   0   0   0   0   N
2950                 AT_RAND  0   0   1   0   0   0   0   0   0   0   0   N
2951                 AT_AUTN  0   0   1   0   0   0   0   0   0   0   0   N
2952                  AT_RES  0   0   0   1   0   0   0   0   0   0   0   N
2953                 AT_AUTS  0   0   0   0   0   0   0   0   0   0   1   N
2954       AT_NEXT_PSEUDONYM  0   0  0-1  0   0   0   0   0   0   0   0   Y
2955       AT_NEXT_REAUTH_ID  0   0  0-1  0   0   0   0  0-1  0   0   0   Y
2956                   AT_IV  0   0  0-1  0* 0-1 0-1  0   1   1   0   0   N
2957            AT_ENCR_DATA  0   0  0-1  0* 0-1 0-1  0   1   1   0   0   N
2958              AT_PADDING  0   0  0-1  0* 0-1 0-1  0  0-1 0-1  0   0   Y
2959            AT_CHECKCODE  0   0  0-1 0-1  0   0   0  0-1 0-1  0   0   N
2960           AT_RESULT_IND  0   0  0-1 0-1  0   0   0  0-1 0-1  0   0   N
2961                  AT_MAC  0   0   1   1  0-1 0-1  0   1   1   0   0   N
2962              AT_COUNTER  0   0   0   0  0-1 0-1  0   1   1   0   0   Y
2963    AT_COUNTER_TOO_SMALL  0   0   0   0   0   0   0   0  0-1  0   0   Y
2964              AT_NONCE_S  0   0   0   0   0   0   0   1   0   0   0   Y
2965         AT_NOTIFICATION  0   0   0   0   1   0   0   0   0   0   0   N
2966    AT_CLIENT_ERROR_CODE  0   0   0   0   0   0   1   0   0   0   0   N
2967
2968
2969
2970 Arkko & Haverinen            Informational                     [Page 53]
2971 \f
2972 RFC 4187                 EAP-AKA Authentication             January 2006
2973
2974
2975    It should be noted that attributes AT_PERMANENT_ID_REQ,
2976    AT_ANY_ID_REQ, and AT_FULLAUTH_ID_REQ are mutually exclusive, so that
2977    only one of them can be included at the same time.  If one of the
2978    attributes AT_IV or AT_ENCR_DATA is included, then both of the
2979    attributes MUST be included.
2980
2981 10.2.  AT_PERMANENT_ID_REQ
2982
2983    The format of the AT_PERMANENT_ID_REQ attribute is shown below.
2984
2985     0                   1                   2                   3
2986     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
2987    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2988    |AT_PERM..._REQ | Length = 1    |           Reserved            |
2989    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2990
2991    The use of the AT_PERMANENT_ID_REQ is defined in Section 4.1.  The
2992    value field only contains two reserved bytes, which are set to zero
2993    on sending and ignored on reception.
2994
2995 10.3.  AT_ANY_ID_REQ
2996
2997    The format of the AT_ANY_ID_REQ attribute is shown below.
2998
2999     0                   1                   2                   3
3000     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
3001    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3002    |AT_ANY_ID_REQ  | Length = 1    |           Reserved            |
3003    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3004
3005    The use of the AT_ANY_ID_REQ is defined in Section 4.1.  The value
3006    field only contains two reserved bytes, which are set to zero on
3007    sending and ignored on reception.
3008
3009 10.4.  AT_FULLAUTH_ID_REQ
3010
3011    The format of the AT_FULLAUTH_ID_REQ attribute is shown below.
3012
3013     0                   1                   2                   3
3014     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
3015    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3016    |AT_FULLAUTH_...| Length = 1    |           Reserved            |
3017    +---------------+---------------+-------------------------------+
3018
3019    The use of the AT_FULLAUTH_ID_REQ is defined in Section 4.1.  The
3020    value field only contains two reserved bytes, which are set to zero
3021    on sending and ignored on reception.
3022
3023
3024
3025
3026 Arkko & Haverinen            Informational                     [Page 54]
3027 \f
3028 RFC 4187                 EAP-AKA Authentication             January 2006
3029
3030
3031 10.5.  AT_IDENTITY
3032
3033    The format of the AT_IDENTITY attribute is shown below.
3034
3035     0                   1                   2                   3
3036     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
3037    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3038    | AT_IDENTITY   | Length        | Actual Identity Length        |
3039    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3040    |                                                               |
3041    .                       Identity                                .
3042    .                                                               .
3043    |                                                               |
3044    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3045
3046    The use of the AT_IDENTITY is defined in Section 4.1.  The value
3047    field of this attribute begins with 2-byte actual identity length,
3048    which specifies the length of the identity in bytes.  This field is
3049    followed by the subscriber identity of the indicated actual length.
3050    The identity is the permanent identity, a pseudonym identity or a
3051    fast re-authentication identity.  The identity format is specified in
3052    Section 4.1.1.  The same identity format is used in the AT_IDENTITY
3053    attribute and the EAP-Response/Identity packet, with the exception
3054    that the peer MUST NOT decorate the identity it includes in
3055    AT_IDENTITY.  The identity does not include any terminating null
3056    characters.  Because the length of the attribute must be a multiple
3057    of 4 bytes, the sender pads the identity with zero bytes when
3058    necessary.
3059
3060 10.6.  AT_RAND
3061
3062    The format of the AT_RAND attribute is shown below.
3063
3064     0                   1                   2                   3
3065     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
3066    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3067    |    AT_RAND    | Length = 5    |           Reserved            |
3068    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3069    |                                                               |
3070    |                             RAND                              |
3071    |                                                               |
3072    |                                                               |
3073    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3074
3075    The value field of this attribute contains two reserved bytes
3076    followed by the AKA RAND parameter, 16 bytes (128 bits).  The
3077    reserved bytes are set to zero when sending and ignored on reception.
3078
3079
3080
3081
3082 Arkko & Haverinen            Informational                     [Page 55]
3083 \f
3084 RFC 4187                 EAP-AKA Authentication             January 2006
3085
3086
3087 10.7.  AT_AUTN
3088
3089    The format of the AT_AUTN attribute is shown below.
3090
3091     0                   1                   2                   3
3092     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
3093    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3094    |    AT_AUTN    | Length = 5    |           Reserved            |
3095    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3096    |                                                               |
3097    |                        AUTN                                   |
3098    |                                                               |
3099    |                                                               |
3100    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3101
3102    The value field of this attribute contains two reserved bytes
3103    followed by the AKA AUTN parameter, 16 bytes (128 bits).  The
3104    reserved bytes are set to zero when sending and ignored on reception.
3105
3106 10.8.  AT_RES
3107
3108    The format of the AT_RES attribute is shown below.
3109
3110     0                   1                   2                   3
3111     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
3112    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3113    |     AT_RES    |    Length     |          RES Length           |
3114    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
3115    |                                                               |
3116    |                             RES                               |
3117    |                                                               |
3118    |                                                               |
3119    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3120
3121    The value field of this attribute begins with the 2-byte RES Length,
3122    which identifies the exact length of the RES in bits.  The RES length
3123    is followed by the AKA RES parameter.  According to [TS33.105], the
3124    length of the AKA RES can vary between 32 and 128 bits.  Because the
3125    length of the AT_RES attribute must be a multiple of 4 bytes, the
3126    sender pads the RES with zero bits where necessary.
3127
3128
3129
3130
3131
3132
3133
3134
3135
3136
3137
3138 Arkko & Haverinen            Informational                     [Page 56]
3139 \f
3140 RFC 4187                 EAP-AKA Authentication             January 2006
3141
3142
3143 10.9.  AT_AUTS
3144
3145    The format of the AT_AUTS attribute is shown below.
3146
3147     0                   1                   2                   3
3148     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
3149    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
3150    |    AT_AUTS    | Length = 4    |                               |
3151    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
3152    |                                                               |
3153    |                             AUTS                              |
3154    |                                                               |
3155    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3156
3157    The value field of this attribute contains the AKA AUTS parameter,
3158    112 bits (14 bytes).
3159
3160 10.10.  AT_NEXT_PSEUDONYM
3161
3162    The format of the AT_NEXT_PSEUDONYM attribute is shown below.
3163
3164     0                   1                   2                   3
3165     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
3166    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3167    | AT_NEXT_PSEU..| Length        | Actual Pseudonym Length       |
3168    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3169    |                                                               |
3170    .                          Next Pseudonym                       .
3171    .                                                               .
3172    |                                                               |
3173    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3174
3175    The value field of this attribute begins with a 2-byte actual
3176    pseudonym length, which specifies the length of the following
3177    pseudonym in bytes.  This field is followed by a pseudonym username
3178    that the peer can use in the next authentication.  The username MUST
3179    NOT include any realm portion.  The username does not include any
3180    terminating null characters.  Because the length of the attribute
3181    must be a multiple of 4 bytes, the sender pads the pseudonym with
3182    zero bytes when necessary.  The username encoding MUST follow the
3183    UTF-8 transformation format [RFC3629].  This attribute MUST always be
3184    encrypted by encapsulating it within the AT_ENCR_DATA attribute.
3185
3186
3187
3188
3189
3190
3191
3192
3193
3194 Arkko & Haverinen            Informational                     [Page 57]
3195 \f
3196 RFC 4187                 EAP-AKA Authentication             January 2006
3197
3198
3199 10.11.  AT_NEXT_REAUTH_ID
3200
3201    The format of the AT_NEXT_REAUTH_ID attribute is shown below.
3202
3203     0                   1                   2                   3
3204     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
3205    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3206    | AT_NEXT_REAU..| Length        | Actual Re-Auth Identity Length|
3207    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3208    |                                                               |
3209    .              Next Fast Re-Authentication Username             .
3210    .                                                               .
3211    |                                                               |
3212    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3213
3214    The value field of this attribute begins with a 2-byte actual
3215    re-authentication identity length which specifies the length of the
3216    following fast re-authentication identity in bytes.  This field is
3217    followed by a fast re-authentication identity that the peer can use
3218    in the next fast re-authentication, as described in Section 5.  In
3219    environments where a realm portion is required, the fast
3220    re-authentication identity includes both a username portion and a
3221    realm name portion.  The fast re-authentication identity does not
3222    include any terminating null characters.  Because the length of the
3223    attribute must be a multiple of 4 bytes, the sender pads the fast
3224    re-authentication identity with zero bytes when necessary.  The
3225    identity encoding MUST follow the UTF-8 transformation format
3226    [RFC3629].  This attribute MUST always be encrypted by encapsulating
3227    it within the AT_ENCR_DATA attribute.
3228
3229 10.12.  AT_IV, AT_ENCR_DATA, and AT_PADDING
3230
3231    AT_IV and AT_ENCR_DATA attributes can be used to transmit encrypted
3232    information between the EAP-AKA peer and server.
3233
3234    The value field of AT_IV contains two reserved bytes followed by a
3235    16-byte initialization vector required by the AT_ENCR_DATA attribute.
3236    The reserved bytes are set to zero when sending and ignored on
3237    reception.  The AT_IV attribute MUST be included if and only if the
3238    AT_ENCR_DATA is included.  Section 6.3 specifies the operation if a
3239    packet that does not meet this condition is encountered.
3240
3241    The sender of the AT_IV attribute chooses the initialization vector
3242    at random.  The sender MUST NOT reuse the initialization vector value
3243    from previous EAP-AKA packets.  The sender SHOULD use a good source
3244    of randomness to generate the initialization vector.  Please see
3245    [RFC4086] for more information about generating random