3 Network Working Group H. Haverinen (editor)
7 Expires: 27 April, 2004 27 October, 2003
11 EAP SIM Authentication
12 draft-haverinen-pppext-eap-sim-12.txt
17 This document is an Internet-Draft and is subject to all provisions
18 of Section 10 of RFC2026.
20 Internet-Drafts are working documents of the Internet Engineering
21 Task Force (IETF), its areas, and its working groups. Note that
22 other groups may also distribute working documents as Internet-
25 Internet-Drafts are draft documents valid for a maximum of six
26 months and may be updated, replaced, or obsoleted by other documents
27 at any time. It is inappropriate to use Internet- Drafts as
28 reference material or to cite them other than as "work in progress."
30 The list of current Internet-Drafts can be accessed at:
31 http://www.ietf.org/ietf/1id-abstracts.txt
33 The list of Internet-Draft Shadow Directories can be accessed at:
34 http://www.ietf.org/shadow.html.
36 Comments should be submitted to the eap@frascone.com mailing list.
38 Distribution of this memo is unlimited.
42 This document specifies an Extensible Authentication Protocol (EAP)
43 mechanism for authentication and session key distribution using the
44 GSM Subscriber Identity Module (SIM). The mechanism specifies
45 enhancements to GSM authentication and key agreement whereby
46 multiple authentication triplets can be combined to create
47 authentication responses and session keys of greater strength than
48 the individual GSM triplets. The mechanism also includes network
49 authentication, user anonymity support and a re-authentication
58 Haverinen and Salowey [Page 1]
61 Internet Draft EAP SIM Authentication 27 October, 2003
67 Status of this Memo.........................................1
68 Abstract....................................................1
69 Table of Contents...........................................2
70 1. Introduction.............................................3
71 2. Terms....................................................4
72 3. Overview.................................................6
73 4. Operation................................................8
74 4.1. Version Negotiation....................................8
75 4.2. Identity Management....................................9
76 4.3. Re-Authentication.....................................25
77 4.4. EAP/SIM Notifications.................................30
78 4.5. Error Cases...........................................31
79 4.6. Key Generation........................................33
80 5. Message Format and Protocol Extensibility...............35
81 5.1. Message Format........................................35
82 5.2. Protocol Extensibility................................37
83 6. Messages................................................37
84 6.1. EAP-Request/SIM/Start.................................37
85 6.2. EAP-Response/SIM/Start................................38
86 6.3. EAP-Request/SIM/Challenge.............................38
87 6.4. EAP-Response/SIM/Challenge............................39
88 6.5. EAP-Request/SIM/Re-authentication.....................40
89 6.6. EAP-Response/SIM/Re-authentication....................40
90 6.7. EAP-Response/SIM/Client-Error.........................40
91 6.8. EAP-Request/SIM/Notification..........................40
92 6.9. EAP-Response/SIM/Notification.........................41
93 7. Attributes..............................................41
94 7.1. Table of Attributes...................................41
95 7.2. AT_MAC................................................42
96 7.3. AT_IV, AT_ENCR_DATA and AT_PADDING....................43
97 7.4. AT_VERSION_LIST.......................................45
98 7.5. AT_SELECTED_VERSION...................................46
99 7.6. AT_NONCE_MT...........................................46
100 7.7. AT_PERMANENT_ID_REQ...................................46
101 7.8. AT_ANY_ID_REQ.........................................47
102 7.9. AT_FULLAUTH_ID_REQ....................................47
103 7.10. AT_IDENTITY..........................................47
104 7.11. AT_RAND..............................................48
105 7.12. AT_NEXT_PSEUDONYM....................................49
106 7.13. AT_NEXT_REAUTH_ID....................................49
107 7.14. AT_COUNTER...........................................50
108 7.15. AT_COUNTER_TOO_SMALL.................................50
109 7.16. AT_NONCE_S...........................................50
110 7.17. AT_NOTIFICATION......................................51
111 7.18. AT_CLIENT_ERROR_CODE.................................52
112 8. IANA Considerations.....................................52
113 9. Security Considerations.................................54
114 9.1. Identity Protection...................................54
115 9.2. Mutual Authentication and Triplet Exposure............54
116 9.3. Key Derivation........................................55
118 Haverinen and Salowey Expires: 27 April, 2004 [Page 2]
121 Internet Draft EAP SIM Authentication 27 October, 2003
124 9.4. Dictionary Attacks....................................56
125 9.5. Credentials Reuse.....................................56
126 9.6. Integrity and Replay Protection, and Confidentiality..57
127 9.7. Negotiation Attacks...................................57
128 9.8. Fast Reconnect........................................58
129 9.9. Acknowledged Result Indications.......................58
130 9.10. Man-in-the-middle Attacks............................58
131 9.11. Generating Random Numbers............................59
132 10. Security Claims........................................59
133 11. Intellectual Property Right Notice.....................59
134 12. Acknowledgements and Contributions.....................59
135 12.1. Contributors.........................................59
136 12.2. Acknowledgements.....................................60
137 Normative References.......................................60
138 Informative References.....................................61
139 Editors' and Contributors' Contact Information.............63
140 Annex A. Test Vectors......................................64
141 Annex B. Pseudo-Random Number Generator....................72
145 This document specifies an Extensible Authentication Protocol (EAP)
146 [EAP] mechanism for authentication and session key distribution
147 using the GSM Subscriber Identity Module (SIM).
149 GSM authentication is based on a challenge-response mechanism. The
150 A3/A8 authentication algorithms that run on the SIM can be given a
151 128-bit random number (RAND) as a challenge. The SIM runs an
152 operator-specific algorithm, which takes the RAND and a secret key
153 Ki stored on the SIM as input, and produces a 32-bit response (SRES)
154 and a 64-bit long key Kc as output. The Kc key is originally
155 intended to be used as an encryption key over the air interface, but
156 in this protocol it is used for deriving keying material and not
157 directly used. Hence the secrecy of Kc is critical to the security
158 of this protocol. Please find more information about GSM
159 authentication in [GSM 03.20].
161 The lack of mutual authentication is a weakness in GSM
162 authentication. The 64 bit cipher key (Kc) that is derived is not
163 strong enough for data networks where stronger and longer keys are
164 required. Hence in EAP/SIM, several RAND challenges are used for
165 generating several 64-bit Kc keys, which are combined to constitute
166 stronger keying material. In EAP/SIM the client issues a random
167 number NONCE_MT to the network, in order to contribute to key
168 derivation, and to prevent replays of EAP/SIM requests from previous
169 exchanges. The NONCE_MT can be conceived as the client's challenge
170 to the network. EAP/SIM also extends the combined RAND challenges
171 and other messages with a message authentication code in order to
172 provide message integrity protection along with mutual
175 EAP/SIM specifies optional support for protecting the privacy of
176 subscriber identity using the same concept as GSM, which is using
178 Haverinen and Salowey Expires: 27 April, 2004 [Page 3]
181 Internet Draft EAP SIM Authentication 27 October, 2003
184 pseudonyms/temporary identifiers. It also specifies an optional re-
185 authentication procedure.
187 The security of EAP/SIM builds on underlying GSM mechanisms. The
188 security properties of EAP/SIM are documented in Section 9 of this
189 document. Implementers and users of EAP/SIM are advised to carefully
190 study the security considerations in Section 9 in order to determine
191 whether the security properties are sufficient for the environment
192 in question, especially as the secrecy of Kc keys is key to the
193 security of EAP/SIM. In brief, EAP/SIM is in no sense weaker than
194 the GSM mechanisms. In some cases EAP/SIM provides better security
195 properties than the underlying GSM mechanisms, particularly if the
196 SIM credentials are only used for EAP/SIM and not re-used from
197 GSM/GPRS. Many of the security features of EAP_SIM rely upon the
198 secrecy of the Kc values in the SIM triplets, so protecting these
199 values is key to the security of the EAP-SIM protocol. In any case,
200 if the GSM authentication mechanisms are considered to be sufficient
201 for use on the cellular networks, then EAP/SIM is expected to be
202 sufficiently secure for other networks.
204 The 3rd Generation Partnership Project (3GPP) has specified an
205 enhanced Authentication and Key Exchange (AKA) architecture for the
206 Universal Mobile Telecommunications System (UMTS). The UMTS AKA
207 mechanism includes mutual authentication, replay protection and
208 derivation of longer session keys. EAP AKA [EAP AKA] specifies an
209 EAP method that is based on UMTS AKA. EAP AKA, which is a more
210 secure protocol, may be used instead of EAP/SIM, if USIMs and 3G
211 network infrastructure are available.
215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
217 document are to be interpreted as described in [RFC 2119].
219 The terms and abbreviations "authenticator", "backend authentication
220 server", "EAP server", "Silently Discard", "Master Session Key
221 (MSK)", and "Extended Master Session Key (EMSK)" in this document
222 are to be interpreted as described in [EAP].
224 This document frequently uses the following terms and abbreviations:
228 Authentication, Authorization and Accounting protocol
232 Authentication Centre. The GSM network element that provides the
233 authentication triplets for authenticating the subscriber.
238 Haverinen and Salowey Expires: 27 April, 2004 [Page 4]
241 Internet Draft EAP SIM Authentication 27 October, 2003
244 Authentication vector
246 GSM triplets can be alternatively called authentication vectors.
250 Extensible Authentication Protocol.
254 Global System for Mobile communications.
258 The tuple formed by the three GSM authentication values RAND, Kc
263 International Mobile Subscriber Identifier, used in GSM to
264 identify subscribers.
268 Message Authentication Code
272 Network Access Identifier
276 The permanent identity of the peer, including an NAI realm
277 portion in environments where a realm is used. The permanent
278 identity is usually based on the IMSI. Used on full
283 The username portion of permanent identity, ie. not including any
288 A pseudonym identity of the peer, including an NAI realm portion
289 in environments where a real is used. Used on full authentication
294 The username portion of pseudonym identity, ie. not including any
298 Haverinen and Salowey Expires: 27 April, 2004 [Page 5]
301 Internet Draft EAP SIM Authentication 27 October, 2003
304 Re-authentication Identity
306 A re-authentication identity of the peer, including an NAI realm
307 portion in environments where a real is used. Used on re-
310 Re-authentication Username
312 The username portion of re-authentication identity, ie. not
313 including any realm portions.
317 Subscriber Identity Module. The SIM is an application
318 traditionally resident on smart cards distributed by GSM
323 Figure 1 shows an overview of the EAP/SIM full authentication
324 procedure. The authenticator typically communicates with an EAP
325 server that is located on a backend authentication server using an
326 AAA protocol. The AAA communications is not shown in the figure.
328 The first EAP Request issued by the network is EAP-Request/Identity.
329 On full authentication, the peer's response includes either the
330 user's International Mobile Subscriber Identity (IMSI) or a
331 temporary identity (pseudonym) if identity privacy is in effect, as
332 specified in Section 4.2.
334 Following the peer's EAP-Response/Identity packet, the peer receives
335 EAP Requests of type 18 (SIM) from the EAP server and sends the
336 corresponding EAP Responses. The EAP packets that are of the Type
337 SIM also have a Subtype field. On full authentication, the first
338 EAP-Request/SIM packet is of the Subtype 10 (Start). EAP SIM packets
339 encapsulate parameters in attributes, encoded in a Type, Length,
340 Value format. The packet format and the use of attributes are
341 specified in Section 5.
343 The EAP-Request/SIM/Start packet contains the list of EAP/SIM
344 version supported by the EAP server in the AT_VERSION_LIST
345 attribute. This packet may also include attributes for requesting
346 the subscriber identity, as specified in Section 4.2.
348 The peer responds to EAP-Request/SIM/Start with the EAP-
349 Response/SIM/Start packet, which includes the AT_NONCE_MT attribute
350 that contains a random number NONCE_MT, chosen by the peer, and the
351 AT_SELECTED_VERSION attribute that contains the version number
352 selected by the peer. The version negotiation is protected by
353 including the version list and the selected version in the
354 calculation of keying material (Section 4.6).
358 Haverinen and Salowey Expires: 27 April, 2004 [Page 6]
361 Internet Draft EAP SIM Authentication 27 October, 2003
364 After receiving the EAP Response/SIM/Start, the EAP server obtains n
365 GSM triplets for use in authenticating the subscriber, where n = 2
366 or n = 3. From the triplets, the EAP server derives the keying
367 material, as specified in Section 4.6. The triplets may be obtained
368 by contacting an Authentication Centre (AuC) on the GSM network; per
369 GSM specifications, between 1 and 5 triplets may be obtained at a
372 The next EAP Request the EAP Server issues is of the type SIM and
373 subtype Challenge (11). It contains the RAND challenges and a
374 message authentication code attribute AT_MAC to cover the
377 On receipt of the EAP-Request/SIM/Challenge message, the peer runs
378 the GSM authentication algorithm and calculates a copy of the
379 message authentication code. The peer then verifies that the
380 calculated MAC equals the received MAC. If the MAC's do not match,
381 then the peer sends the EAP-Response/SIM/Client-Error packet and the
382 authentication exchange terminates.
384 Since the RAND's given to a peer are accompanied with the message
385 authentication code AT_MAC, and since the peer's NONCE_MT value
386 contributes to AT_MAC, the peer is able to verify that the EAP SIM
387 message is fresh (not a replay) and that the sender possesses valid
388 GSM triplets for the subscriber.
390 If all checks out, the peer responds with the EAP-
391 Response/SIM/Challenge, containing the AT_MAC attribute that covers
392 the peer's SRES response values (Section 6.4). The EAP server
393 verifies that the MAC is correct and sends the EAP-Success packet,
394 indicating that the authentication was successful. The EAP server
395 may also include derived keying material in the message it sends to
418 Haverinen and Salowey Expires: 27 April, 2004 [Page 7]
421 Internet Draft EAP SIM Authentication 27 October, 2003
426 | EAP-Request/Identity |
427 |<---------------------------------------------------------|
429 | EAP-Response/Identity |
430 |--------------------------------------------------------->|
432 | EAP-Request/SIM/Start |
433 | (AT_VERSION_LIST) |
434 |<---------------------------------------------------------|
436 | EAP-Response/SIM/Start |
437 | (AT_NONCE_MT, AT_SELECTED_VERSION) |
438 |--------------------------------------------------------->|
440 | EAP-Request/SIM/Challenge |
441 | (AT_RAND, AT_MAC) |
442 |<---------------------------------------------------------|
444 +-------------------------------------+ |
445 | Peer runs GSM algorithms, | |
446 | verifies AT_MAC and derives | |
448 +-------------------------------------+ |
450 | EAP-Response/SIM/Challenge |
452 |--------------------------------------------------------->|
456 |<---------------------------------------------------------|
459 Figure 1 EAP/SIM full authentication procedure
461 EAP SIM also includes a separate re-authentication procedure, which
462 does not make use of the A3/A8 algorithms or the GSM infrastructure.
463 Re-authentication is based on keys derived on full authentication.
464 If the peer has maintained state information for re-authentication
465 and wants to use re-authentication, then the peer indicates this by
466 using a specific re-authentication identity instead of the permanent
467 identity or a pseudonym identity. The re-authentication procedure is
468 described in Section 4.3.
472 4.1. Version Negotiation
474 EAP/SIM includes version negotiation so as to allow future
475 developments in the protocol. The version negotiation is performed
476 on full authentication and it uses two attributes, AT_VERSION_LIST,
478 Haverinen and Salowey Expires: 27 April, 2004 [Page 8]
481 Internet Draft EAP SIM Authentication 27 October, 2003
484 which the server always includes in EAP-Request/SIM/Start, and
485 AT_SELECTED_VERSION, which the peer includes in EAP-
486 Response/SIM/Start on full authentication.
488 AT_VERSION_LIST includes the EAP/SIM versions supported by the
489 server. If AT_VERSION_LIST does not include a version that is
490 implemented by the peer and allowed in the peer's security policy,
491 then the peer MUST send the EAP-Response/SIM/Client-Error packet
492 (Section 6.7) to the server with the error code "unsupported
493 version". If a suitable version is included, then the peer includes
494 the AT_SELECTED_VERSION attribute, containing the selected version,
495 in the EAP-Response/SIM/Start packet. The peer MUST only indicate a
496 version that is included in AT_VERSION_LIST. If several versions are
497 acceptable, then the peer SHOULD choose the version that occurs
498 first in the version list.
500 The version number list of AT_VERSION_LIST and the selected version
501 of AT_SELECTED_VERSION are included in the key derivation procedure
502 (Section 4.6). If an attacker modifies either one of these
503 attributes, then the peer and the server derive different keying
504 material. Because K_aut keys are different, the server and peer
505 calculate different AT_MAC values. Hence, the peer detects that
506 AT_MAC included in EAP-Request/SIM/Challenge is incorrect and sends
507 the EAP-Response/SIM/Client-Error packet. The authentication
508 procedure terminates.
510 4.2. Identity Management
512 4.2.1 Format, Generation and Usage of Peer Identities
516 In the beginning of EAP authentication, the Authenticator or the EAP
517 server usually issues the EAP-Request/Identity packet to the peer.
518 The peer responds with EAP-Response/Identity, which contains the
519 user's identity. The formats of these packets are specified in
522 GSM subscribers are identified with the International Mobile
523 Subscriber Identity (IMSI) [GSM 03.03]. The IMSI is composed of a
524 three digit Mobile Country Code (MCC), a two or three digit Mobile
525 Network Code (MNC) and a not more than 10 digit Mobile Subscriber
526 Identification Number (MSIN). In other words, the IMSI is a string
527 of not more than 15 digits. MCC and MNC uniquely identify the GSM
528 operator and help identify the AuC from which the authentication
529 vectors need to be retrieved for this subscriber.
531 Internet AAA protocols identify users with the Network Access
532 Identifier (NAI) [RFC 2486]. When used in a roaming environment, the
533 NAI is composed of a username and a realm, separated with "@"
534 (username@realm). The username portion identifies the subscriber
538 Haverinen and Salowey Expires: 27 April, 2004 [Page 9]
541 Internet Draft EAP SIM Authentication 27 October, 2003
544 This section specifies the peer identity format used in EAP/SIM. In
545 this document, the term identity or peer identity refers to the
546 whole identity string that is used to identify the peer. The peer
547 identity may include a realm portion. "Username" refers to the
548 portion of the peer identity that identifies the user, i.e. the
549 username does not include the realm portion.
551 Identity Privacy Support
553 EAP/SIM includes optional identity privacy (anonymity) support that
554 can be used to hide the cleartext permanent identity and thereby to
555 make the subscriber's EAP exchanges untraceable to eavesdroppers.
556 Because the permanent identity never changes, revealing it would
557 help observers to track the user. The permanent identity is usually
558 based on the IMSI, which may further help the tracking, because the
559 same identifier may used in other contexts as well. Identity privacy
560 is based on temporary identities, or pseudonyms, which are
561 equivalent to but separate from the Temporary Mobile Subscriber
562 Identities (TMSI) that are used on cellular networks. Please see
563 Section 9.1 for security considerations regarding identity privacy.
565 Username Types in EAP/SIM identities
567 There are three types of usernames in EAP/SIM peer identities:
569 (1) Permanent usernames. For example,
570 1123456789098765@myoperator.com might be a valid permanent identity.
571 In this example, 1123456789098765 is the permanent username.
573 (2) Pseudonym usernames. For example, 3s7ah6n9q@myoperator.com might
574 be a valid pseudonym identity. In this example, 3s7ah6n9q is the
577 (3) Re-authentication usernames. For example,
578 53953754a@myoperator.com might be a valid re-authentication
579 identity. In this case, 53953754 is the re-authentication username.
581 The first two types of identities are only used on full
582 authentication and the last one only on re-authentication. When the
583 optional identity privacy support is not used, the non-pseudonym
584 permanent identity is used on full authentication. The re-
585 authentication exchange is specified in Section 4.3.
589 In some environments, the peer may need to decorate the identity by
590 prepending or appending the username with a string, in order to
591 indicate supplementary AAA routing information in addition to the
592 NAI realm. (The usage of a NAI realm portion is not considered to be
593 decoration.) Username decoration is out of the scope of this
594 document. However, it should be noted that username decoration might
595 prevent the server from recognizing a valid username. Hence,
596 although the peer MAY use username decoration in the identities the
598 Haverinen and Salowey Expires: 27 April, 2004 [Page 10]
601 Internet Draft EAP SIM Authentication 27 October, 2003
604 peer includes in EAP-Response/Identity, and the EAP server MAY
605 accept a decorated peer username in this message, the peer or the
606 EAP server MUST NOT decorate any other peer identities that are used
607 in various EAP/SIM attributes. Only the identity used in EAP-
608 Response/Identity may be decorated.
612 The peer MAY include a realm portion in the peer identity, as per
613 the NAI format. The use of a realm portion is not mandatory.
615 If a realm is used, the realm MAY be chosen by the operator and it
616 MAY a configurable parameter in the EAP/SIM peer implementation. In
617 this case, the peer is typically configured with the NAI realm of
618 the home operator. Operators MAY reserve a specific realm name for
619 EAP/SIM users. This convention makes it easy to recognize that the
620 NAI identifies a GSM subscriber. Such reserved NAI realm may be
621 useful as a hint as to the first authentication method to use during
622 method negotiation. When the peer is using a pseudonym username
623 instead of the permanent username, the peer selects the realm name
624 portion similarly as it select the realm portion when using the
627 If no configured realm name is available, the peer MAY derive the
628 realm name from the MCC and MNC portions of the IMSI. A recommended
629 way to derive the realm from the IMSI using the realm
630 3gppnetwork.org will be specified in [Draft 3GPP TS 23.234].
631 Alternatively, the realm name may be obtained by concatenating
632 "mnc", the MNC digits of IMSI, ".mcc", the MCC digits of IMSI and
633 ".owlan.org". For example, if the IMSI is 123456789098765, and the
634 MNC is three digits long, then the derived realm name is
635 "mnc456.mcc123.owlan.org".
637 The IMSI is a string of digits without any explicit structure, so
638 the peer may not be able to determine the length of the MNC portion.
639 If the peer is not able to determine whether the MNC is two or three
640 digits long, the peer MAY use a 3-digit MNC. If the correct length
641 of the MNC is two, then the MNC used in the realm name includes the
642 first digit of MSIN. Hence, when configuring AAA networks for
643 operators that have 2-digit MNC's, the network SHOULD also be
644 prepared for realm names with incorrect 3-digit MNC's.
646 Format of the Permanent Username
648 The non-pseudonym permanent username SHOULD be derived from the
649 IMSI. In this case, the permanent username MUST be of the format "1"
650 | IMSI, where the character "|" denotes concatenation. In other
651 words, the first character of the username is the digit one (ASCII
652 value 0x31), followed by the IMSI. The IMSI is an ASCII string that
653 consists of not more than 15 decimal digits (ASCII values between
654 0x30 and 0x39) as specified in [GSM 03.03].
658 Haverinen and Salowey Expires: 27 April, 2004 [Page 11]
661 Internet Draft EAP SIM Authentication 27 October, 2003
664 The EAP server MAY use the leading "1" as a hint to try EAP/SIM as
665 the first authentication method during method negotiation, rather
666 than for example EAP/AKA. The EAP/SIM server MAY propose EAP/SIM
667 even if the leading character was not "1".
669 Alternatively, an implementation MAY choose a permanent username
670 that is not based on the IMSI. In this case the selection of the
671 username, its format, and its processing is out of the scope of this
672 document. In this case, the peer implementation MUST NOT prepend any
673 leading characters to the username.
675 Generating Pseudonyms and Re-authentication Identities by the Server
677 Pseudonym usernames and re-authentication identities are generated
678 by the EAP server. The EAP server produces pseudonym usernames and
679 re-authentication identities in an implementation-dependent manner.
680 Only the EAP server needs to be able to map the pseudonym username
681 to the permanent identity, or to recognize a re-authentication
682 identity. Regardless of construction method, the pseudonym username
683 MUST conform to the grammar specified for the username portion of an
684 NAI. The re-authentication identity also MUST conform to the NAI
685 grammar. The EAP servers that the subscribers of an operator can use
686 MUST ensure that the pseudonym usernames and the username portions
687 used in re-authentication identities they generate are unique.
689 In any case, it is necessary that permanent usernames, pseudonym
690 usernames and re-authentication usernames are separate and
691 recognizable from each other. It is also desirable that EAP SIM and
692 EAP AKA user names be recognizable from each other as an aid for the
693 server to which method to offer.
695 In general, it is the task of the EAP server and the policies of its
696 administrator to ensure sufficient separation in the usernames.
697 Pseudonym usernames and re-authentication usernames are both
698 produced and used by the EAP server. The EAP server MUST compose
699 pseudonym usernames and re-authentication usernames so that it can
700 recognize if a NAI username is an EAP SIM pseudonym username or an
701 EAP SIM re-authentication username. For instance, when the usernames
702 have been derived from the IMSI, the server could use different
703 leading characters in the pseudonym usernames and re-authentication
704 usernames (e.g. the pseudonym could begin with a leading "3"
705 character). When mapping a re-authentication identity to a permanent
706 identity, the server SHOULD only examine the username portion of the
707 re-authentication identity and ignore the realm portion of the
710 Because the peer may fail to save a pseudonym username sent to in an
711 EAP-Request/SIM/Challenge, for example due to malfunction, the EAP
712 server SHOULD maintain at least one old pseudonym username in
713 addition to the most recent pseudonym username.
718 Haverinen and Salowey Expires: 27 April, 2004 [Page 12]
721 Internet Draft EAP SIM Authentication 27 October, 2003
724 Transmitting Pseudonyms and Re-authentication Identities to the Peer
726 The server transmits pseudonym usernames and re-authentication
727 identities to the peer in cipher, using the AT_ENCR_DATA attribute.
729 The EAP-Request/SIM/Challenge message MAY include an encrypted
730 pseudonym username and/or an encrypted re-authentication identity in
731 the value field of the AT_ENCR_DATA attribute. Because identity
732 privacy support and re-authentication are optional to implement, the
733 peer MAY ignore the AT_ENCR_DATA attribute and always use the
734 permanent identity. On re-authentication (discussed in Section 4.3),
735 the server MAY include a new encrypted re-authentication identity in
736 the EAP-Request/SIM/Re-authentication message.
738 On receipt of the EAP-Request/SIM/Challenge, the peer MAY decrypt
739 the encrypted data in AT_ENCR_DATA and if a pseudonym username is
740 included, the peer may use the obtained pseudonym username on the
741 next full authentication. If a re-authentication identity is
742 included, then the peer MAY save it and other re-authentication
743 state information, as discussed in Section 4.3, for the next re-
746 If the peer does not receive a new pseudonym username in the EAP-
747 Request/SIM/Challenge message, the peer MAY use an old pseudonym
748 username instead of the permanent username on next full
749 authentication. The username portions of re-authentication
750 identities are one-time usernames, which the peer MUST NOT re-use.
752 Usage of the Pseudonym by the Peer
754 When the optional identity privacy support is used on full
755 authentication, the peer MAY use the pseudonym username received as
756 part of the previous full authentication sequence as the username
757 portion of the NAI. The peer MUST NOT modify the pseudonym username
758 received in AT_NEXT_PSEUDONYM. However, as discussed above, the peer
759 MAY need to decorate the username in some environments by appending
760 or prepending the username with a string that indicates
761 supplementary AAA routing information.
763 When using a pseudonym username in an environment where a realm
764 portion is used, the peer concatenates the received pseudonym
765 username with the "@" character and a NAI realm portion. The
766 selection of the NAI realm is discussed above.
768 Usage of the Re-authentication Identity by the Peer
770 On re-authentication, the peer uses the re-authentication identity,
771 received as part of the previous authentication sequence. A new re-
772 authentication identity may be delivered as part of both full
773 authentication and re-authentication. The peer MUST NOT modify the
774 username part of the re-authentication identity received in
775 AT_NEXT_REAUTH_ID, except in cases when username decoration is
776 required. Even in these cases, the "root" re-authentication username
778 Haverinen and Salowey Expires: 27 April, 2004 [Page 13]
781 Internet Draft EAP SIM Authentication 27 October, 2003
784 must not be modified, but it may be appended or prepended with
787 4.2.2 Communicating the Peer Identity to the Server
791 The peer identity MAY be communicated to the server with the EAP-
792 Response/Identity message. This message MAY contain the permanent
793 identity, a pseudonym identity, or a re-authentication identity. If
794 the peer uses the permanent identity or a pseudonym identity, which
795 the server is able to map to the permanent identity, then the
796 authentication proceeds as discussed in the overview of Section 3.
797 If the peer uses a re-authentication identity, and the server
798 recognized the identity and agrees on using re-authentication, then
799 a re-authentication exchange is performed, as described in 4.3.
801 The peer identity can also be transmitted from the peer to the
802 server using EAP/SIM messages instead of EAP-Response/Identity. In
803 this case, the server includes an identity requesting attribute
804 (AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ) in the
805 EAP-Request/SIM/Start message, and the peer includes the AT_IDENTITY
806 attribute, which contains the peer's identity, in the EAP-
807 Response/SIM/Start message. The AT_ANY_ID_REQ attribute is a general
808 identity requesting attribute, which the server uses if it does not
809 specify which kind of an identity the peer should return in
810 AT_IDENTITY. The server uses the AT_FULLAUTH_ID_REQ attribute to
811 request either the permanent identity or a pseudonym identity. The
812 server uses the AT_PERMANENT_ID_REQ attribute to request the peer to
813 send its permanent identity.
815 The identity format in the AT_IDENTITY attribute is the same as in
816 the EAP-Response/Identity packet (except that identity decoration is
817 not allowed). The AT_IDENTITY attribute contains a permanent
818 identity, a pseudonym identity or a re-authentication identity.
820 Obtaining the subscriber identity via EAP/SIM messages is useful if
821 the server does not have any EAP/SIM peer identity at the beginning
822 of the EAP/SIM exchange or does not recognize the identity the peer
823 used in EAP-Response/Identity. This may happen if, for example, the
824 EAP-Response/Identity has been issued by some EAP method other than
825 EAP/SIM or if intermediate entities or software layers in the peer
826 have modified the identity string in the EAP-Response/Identity
827 packet. Also, some EAP layer implementations may cache the identity
828 string from the first EAP authentication and do not obtain a new
829 identity string from the EAP method implementation on subsequent
830 authentication exchanges.
832 As the identity string is used in key derivation, any of these cases
833 will result in failed authentication unless the EAP server uses
834 EAP/SIM attributes to obtain an unmodified copy of the identity
835 string. Therefore, unless the EAP server can be certain that no
836 intermediate element or software layer has modified the EAP-
838 Haverinen and Salowey Expires: 27 April, 2004 [Page 14]
841 Internet Draft EAP SIM Authentication 27 October, 2003
844 Response/Identity packet, the EAP server SHOULD always use the
845 EAP/SIM attributes to obtain the identity, even if the identity
846 received in EAP-Response/Identity was valid.
848 Please note that the EAP/SIM peer and the EAP/SIM server only
849 process the AT_IDENTITY attribute and entities that only pass
850 through EAP packets do not process this attribute. Hence, if the EAP
851 server is not co-located in the authenticator, then the
852 authenticator and other intermediate AAA elements (such as possible
853 AAA proxy servers) will continue to refer to the peer with the
854 original identity from the EAP-Response/Identity packet regardless
855 of whether the AT_IDENTITY attribute is used in EAP/SIM to transmit
858 Choice of Identity for the EAP-Response/Identity
860 If EAP/SIM peer is started upon receiving an EAP-Request/Identity
861 message, then the peer performs the following steps.
863 If the peer has maintained re-authentication state information and
864 if the peer wants to use re-authentication, then the peer transmits
865 the re-authentication identity in EAP-Response/Identity.
867 Else, if the peer has a pseudonym username available, then the peer
868 transmits the pseudonym identity in EAP-Response/Identity.
870 In other cases, the peer transmits the permanent identity in EAP-
873 Server Operation in the Beginning of EAP/SIM Exchange
875 If the EAP server has not received any identity (permanent identity,
876 pseudonym identity or re-authentication identity) from the peer when
877 sending the first EAP/SIM request, or if the EAP server has received
878 an EAP-Response/Identity packet but the contents do not appear to be
879 a valid permanent identity, pseudonym identity or a re-
880 authentication identity, then the server MUST request an identity
881 from the peer using one of the methods below.
883 The server sends the EAP-Request/SIM/Start message with the
884 AT_PERMANENT_ID_REQ message to indicate that the server wants the
885 peer to include the permanent identity in the AT_IDENTITY attribute
886 of the EAP-Response/SIM/Start message. This is done in the following
889 - The server does not support re-authentication or identity privacy.
891 - The server received an identity that it recognizes as a pseudonym
892 identity but the server is not able to map the pseudonym identity to
893 a permanent identity.
895 The server issues the EAP-Request/SIM/Start packet with the
896 AT_FULLAUTH_ID_REQ attribute to indicate that the server wants the
898 Haverinen and Salowey Expires: 27 April, 2004 [Page 15]
901 Internet Draft EAP SIM Authentication 27 October, 2003
904 peer to include a full authentication identity (pseudonym identity
905 or permanent identity) in the AT_IDENTITY attribute of the EAP-
906 Response/SIM/Start message. This is done in the following cases:
908 - The server does not support re-authentication and the server
909 supports identity privacy
911 - The server received an identity that it recognizes as a re-
912 authentication identity but the server is not able to map the re-
913 authentication identity to a permanent identity
915 The server issues the EAP-Request/SIM/Start packet with the
916 AT_ANY_ID_REQ attribute to indicate that the server wants the peer
917 to include an identity in the AT_IDENTITY attribute of the EAP-
918 Response/SIM/Start message, and the server does not indicate any
919 preferred type for the identity. This is done in other cases, such
920 as when the server does not have any identity, or the server does
921 not recognize the format of a received identity.
923 Processing of EAP-Request/SIM/Start by the Peer
925 Upon receipt of an EAP-Request/SIM/Start message, the peer MUST
926 perform the following steps.
928 If the EAP-Request/SIM/Start does not include any identity request
929 attribute, then the peer responds with EAP-Response/SIM/Start
930 without AT_IDENTITY. The peer includes the AT_SELECTED_VERSION and
931 AT_NONCE_MT attributes, because the exchange is a full
932 authentication exchange.
934 If the EAP-Request/SIM/Start includes AT_PERMANENT_ID_REQ the peer
935 MUST either respond with EAP-Response/SIM/Start and include the
936 permanent identity in AT_IDENTITY or respond with EAP-
937 Response/SIM/Client-Error packet with code "unable to process
940 If the EAP-Request/SIM/Start includes AT_FULL_AUTH_ID_REQ, and if
941 the peer has a pseudonym available, then the peer SHOULD respond
942 with EAP-Response/SIM/Start and includes the pseudonym identity in
943 AT_IDENTITY. If the peer does not have a pseudonym when it receives
944 this message, then the peer MUST either respond with EAP-
945 Response/SIM/Start and include the permanent identity in AT_IDENTITY
946 or respond with EAP-Response/SIM/Client-Error packet with code
947 "unable to process packet." The Peer MUST NOT use a re-
948 authentication identity in the AT_IDENTITY attribute.
950 If the EAP-Request/SIM/Start includes AT_ANY_ID_REQ, and if the peer
951 has maintained re-authentication state information and the peer
952 wants to use re-authentication, then the peer responds with EAP-
953 Response/SIM/Start and includes the re-authentication identity in
954 AT_IDENTITY. Else, if the peer has a pseudonym identity available,
955 then the peer responds with EAP-Response/SIM/Start and includes the
956 pseudonym identity in AT_IDENTITY. Else, the peer responds with EAP-
958 Haverinen and Salowey Expires: 27 April, 2004 [Page 16]
961 Internet Draft EAP SIM Authentication 27 October, 2003
964 Response/SIM/Start and includes the permanent identity in
967 An EAP/SIM exchange may include several EAP/SIM/Start rounds. The
968 server may issue a second EAP-Request/SIM/Start, if it was not able
969 to recognize the identity the peer used in the previous AT_IDENTITY
970 attribute. At most three EAP/SIM/Start rounds can be used.
971 AT_ANY_ID_REQ can only be used in the first EAP-Request/SIM/Start,
972 in other words AT_ANY_ID_REQ MUST NOT be used in the second or third
973 EAP-Request/SIM/Start. AT_FULLAUTH_ID_REQ MUST NOT be used if the
974 previous EAP-Request/SIM/Start included AT_PERMANENT_ID_REQ. The
975 peer operation in cases when it receives an unexpected attribute is
976 specified in Section 4.5.1.
978 Attacks against Identity Privacy
980 The section above specifies two possible ways the peer can operate
981 upon receipt of AT_PERMANENT_ID_REQ. This is because a received
982 AT_PERMANENT_ID_REQ does not necessarily originate from the valid
983 network, but an active attacker may transmit an EAP-
984 Request/SIM/Start packet with an AT_PERMANENT_ID_REQ attribute to
985 the peer, in an effort to find out the true identity of the user. If
986 the peer does not want to reveal its permanent identity, then the
987 peer sends the EAP-Response/SIM/Client-Error packet with the error
988 code "unable to process packet", and the authentication exchange
991 Basically, there are two different policies that the peer can employ
992 with regard to AT_PERMANENT_ID_REQ. A "conservative" peer assumes
993 that the network is able to maintain pseudonyms robustly. Therefore,
994 if a conservative peer has a pseudonym username, the peer responds
995 with EAP-Response/SIM/Client-Error to the EAP packet with
996 AT_PERMANENT_ID_REQ, because the peer believes that the valid
997 network is able to map the pseudonym identity to the peer's
998 permanent identity. (Alternatively, the conservative peer may accept
999 AT_PERMANENT_ID_REQ in certain circumstances, for example if the
1000 pseudonym was received a long time ago.) The benefit of this policy
1001 is that it protects the peer against active attacks on anonymity. On
1002 the other hand, a "liberal" peer always accepts the
1003 AT_PERMANENT_ID_REQ and responds with the permanent identity. The
1004 benefit of this policy is that it works even if the valid network
1005 sometimes loses pseudonyms and is not able to map them to the
1008 Processing of AT_IDENTITY by the Server
1010 When the server receives an EAP-Response/SIM/Start message with the
1011 AT_IDENTITY (in response to the server's identity requesting
1012 attribute), the server MUST operate as follows.
1014 If the server used AT_PERMANENT_ID_REQ, and if the AT_IDENTITY does
1015 not contain a valid permanent identity, then the server sends EAP
1016 Failure and the EAP exchange terminates. If the server recognizes
1018 Haverinen and Salowey Expires: 27 April, 2004 [Page 17]
1021 Internet Draft EAP SIM Authentication 27 October, 2003
1024 the permanent identity and is able to continue, then the server
1025 proceeds with full authentication by sending EAP-
1026 Request/SIM/Challenge.
1028 If the server used AT_FULLAUTH_ID_REQ, and if AT_IDENTITY contains a
1029 valid permanent identity or a pseudonym identity that the server can
1030 map to a valid permanent identity, then the server proceeds with
1031 full authentication by sending EAP-Request/SIM/Challenge. If
1032 AT_IDENTITY contains a pseudonym identity that the server is not
1033 able to map to a valid permanent identity, or an identity that the
1034 server is not able to recognize or classify, then the server sends
1035 EAP-Request/SIM/Start with AT_PERMANENT_ID_REQ.
1037 If the server used AT_ANY_ID_REQ, and if the AT_IDENTITY contains a
1038 valid permanent identity or a pseudonym identity that the server can
1039 map to a valid permanent identity, then the server proceeds with
1040 full authentication by sending EAP-Request/SIM/Challenge.
1042 If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a
1043 valid re-authentication identity and the server agrees on using re-
1044 authentication, then the server proceeds with re-authentication by
1045 sending EAP-Request/SIM/Re-authentication (Section 4.3).
1047 If the server used AT_ANY_ID_REQ, and if the peer sent an EAP-
1048 Response/SIM/Start with only AT_IDENTITY (indicating re-
1049 authentication), but the server is not able to map the identity to a
1050 permanent identity, then the server sends EAP-Request/SIM/Start with
1053 If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a
1054 valid re-authentication identity, which the server is able to map to
1055 a permanent identity, and if the server does not want to use re-
1056 authentication, then the server sends EAP-Request/SIM/Start without
1057 any identity requesting attributes.
1059 If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an
1060 identity that the server recognizes as a pseudonym identity but the
1061 server is not able to map the pseudonym identity to a permanent
1062 identity, then the server sends EAP-Request/SIM/Start with
1063 AT_PERMANENT_ID_REQ.
1065 If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an
1066 identity that the server is not able to recognize or classify, then
1067 the server sends EAP-Request/SIM/Start with AT_FULLAUTH_ID_REQ.
1069 4.2.3 Message Sequence Examples (Informative)
1071 This section contains non-normative message sequence examples to
1072 illustrate how the peer identity can be communicated to the server.
1078 Haverinen and Salowey Expires: 27 April, 2004 [Page 18]
1081 Internet Draft EAP SIM Authentication 27 October, 2003
1086 This case for full authentication is illustrated in the figure
1087 below. In this case, AT_IDENTITY contains either the permanent
1088 identity or a pseudonym identity. The same sequence is also used in
1089 case the server uses the AT_FULLAUTH_ID_REQ in EAP-
1094 | +------------------------------+
1095 | | Server does not have any |
1096 | | Subscriber identity available|
1097 | | When starting EAP/SIM |
1098 | +------------------------------+
1100 | EAP-Request/SIM/Start |
1101 | (AT_ANY_ID_REQ, AT_VERSION_LIST) |
1102 |<------------------------------------------------------|
1105 | EAP-Response/SIM/Start |
1106 | (AT_IDENTITY, AT_NONCE_MT, |
1107 | AT_SELECTED_VERSION) |
1108 |------------------------------------------------------>|
1112 If the peer uses its full authentication identity and the
1113 AT_IDENTITY attribute contains a valid permanent identity or a valid
1114 pseudonym identity that the EAP server is able to map to the
1115 permanent identity, then the full authentication sequence proceeds
1116 as usual with the EAP Server issuing the EAP-Request/SIM/Challenge
1121 The case when the server uses the AT_ANY_ID_REQ and the peer wants
1122 to perform re-authentication is illustrated below.
1138 Haverinen and Salowey Expires: 27 April, 2004 [Page 19]
1141 Internet Draft EAP SIM Authentication 27 October, 2003
1146 | +------------------------------+
1147 | | Server does not have any |
1148 | | Subscriber identity available|
1149 | | When starting EAP/SIM |
1150 | +------------------------------+
1152 | EAP-Request/SIM/Start |
1153 | (AT_ANY_ID_REQ, AT_VERSION_LIST) |
1154 |<------------------------------------------------------|
1157 | EAP-Response/SIM/Start |
1158 | (AT_IDENTITY containing a re-authentication identity) |
1159 |------------------------------------------------------>|
1163 On re-authentication, if the AT_IDENTITY attribute contains a valid
1164 re-authentication identity and the server agrees on using re-
1165 authentication, then the server proceeds with the re-authentication
1166 sequence and issues the EAP-Request/SIM/Re-authentication packet, as
1167 specified in Section 4.3.
1169 Fall Back to Full Authentication
1171 The case when the server does not recognize the re-authentication
1172 identity the peer used in AT_IDENTITY, and issues a second EAP-
1173 Request/SIM/Start message is illustrated below.
1198 Haverinen and Salowey Expires: 27 April, 2004 [Page 20]
1201 Internet Draft EAP SIM Authentication 27 October, 2003
1206 | +------------------------------+
1207 | | Server does not have any |
1208 | | Subscriber identity available|
1209 | | When starting EAP/SIM |
1210 | +------------------------------+
1212 | EAP-Request/SIM/Start |
1213 | (AT_ANY_ID_REQ, AT_VERSION_LIST) |
1214 |<------------------------------------------------------|
1217 | EAP-Response/SIM/Start |
1218 | (AT_IDENTITY containing a re-authentication identity) |
1219 |------------------------------------------------------>|
1221 | +------------------------------+
1222 | | Server does not recognize |
1223 | | The re-authentication |
1225 | +------------------------------+
1227 | EAP-Request/SIM/Start |
1228 | (AT_FULLAUTH_ID_REQ, AT_VERSION_LIST) |
1229 |<------------------------------------------------------|
1232 | EAP-Response/SIM/Start |
1233 | (AT_IDENTITY with a full-auth. identity, AT_NONCE_MT, |
1234 | AT_SELECTED_VERSION) |
1235 |------------------------------------------------------>|
1239 Requesting the Permanent Identity 1
1241 The figure below illustrates the case when the EAP server fails to
1242 map the pseudonym identity included in the EAP-Response/Identity
1243 packet to a valid permanent identity.
1258 Haverinen and Salowey Expires: 27 April, 2004 [Page 21]
1261 Internet Draft EAP SIM Authentication 27 October, 2003
1266 | EAP-Request/Identity |
1267 |<------------------------------------------------------|
1269 | EAP-Response/Identity |
1270 | (Includes a pseudonym) |
1271 |------------------------------------------------------>|
1273 | +------------------------------+
1274 | | Server fails to map the |
1275 | | Pseudonym to a permanent id. |
1276 | +------------------------------+
1278 | EAP-Request/SIM/Start |
1279 | (AT_PERMANENT_ID_REQ, AT_VERSION_LIST) |
1280 |<------------------------------------------------------|
1283 | EAP-Response/SIM/Start |
1284 | (AT_IDENTITY with permanent identity, AT_NONCE_MT, |
1285 | AT_SELECTED_VERSION) |
1286 |------------------------------------------------------>|
1289 If the server recognizes the permanent identity, then the
1290 authentication sequence proceeds as usual with the EAP Server
1291 issuing the EAP-Request/SIM/Challenge message.
1293 Requesting the Permanent Identity 2
1295 The figure below illustrates the case when the EAP server fails to
1296 map the pseudonym included in the AT_IDENTITY attribute to a valid
1318 Haverinen and Salowey Expires: 27 April, 2004 [Page 22]
1321 Internet Draft EAP SIM Authentication 27 October, 2003
1326 | +------------------------------+
1327 | | Server does not have any |
1328 | | Subscriber identity available|
1329 | | When starting EAP/SIM |
1330 | +------------------------------+
1332 | EAP-Request/SIM/Start |
1333 | (AT_ANY_ID_REQ, AT_VERSION_LIST) |
1334 |<------------------------------------------------------|
1337 |EAP-Response/SIM/Start |
1338 |(AT_IDENTITY with a pseudonym identity, AT_NONCE_MT, |
1339 | AT_SELECTED_VERSION) |
1340 |------------------------------------------------------>|
1343 | +-------------------------------+
1344 | | Server fails to map the |
1345 | | Pseudonym in AT_IDENTITY |
1346 | | to a valid permanent identity |
1347 | +-------------------------------+
1349 | EAP-Request/SIM/Start |
1350 | (AT_PERMANENT_ID_REQ, AT_VERSION_LIST) |
1351 |<------------------------------------------------------|
1354 | EAP-Response/SIM/Start |
1355 | (AT_IDENTITY with permanent identity, |
1356 | AT_NONCE_MT, AT_SELECTED_VERSION) |
1357 |------------------------------------------------------>|
1360 Three EAP/SIM/Start Roundtrips
1362 In the worst case, there are three EAP/SIM/Start round trips before
1363 the server has obtained an acceptable identity. This case is
1378 Haverinen and Salowey Expires: 27 April, 2004 [Page 23]
1381 Internet Draft EAP SIM Authentication 27 October, 2003
1386 | +------------------------------+
1387 | | Server does not have any |
1388 | | Subscriber identity available|
1389 | | When starting EAP/SIM |
1390 | +------------------------------+
1392 | EAP-Request/SIM/Start |
1393 | (Includes AT_ANY_ID_REQ, AT_VERSION_LIST) |
1394 |<------------------------------------------------------|
1396 | EAP-Response/SIM/Start |
1397 | (AT_IDENTITY with re-authentication identity) |
1398 |------------------------------------------------------>|
1400 | +------------------------------+
1401 | | Server does not accept |
1402 | | The re-authentication |
1404 | +------------------------------+
1406 | EAP-Request/SIM/Start |
1407 | (AT_FULLAUTH_ID_REQ, AT_VERSION_LIST) |
1408 |<------------------------------------------------------|
1410 |EAP-Response/SIM/Start |
1411 |(AT_IDENTITY with a pseudonym identity, AT_NONCE_MT, |
1412 | AT_SELECTED_VERSION) |
1413 |------------------------------------------------------>|
1415 | +-------------------------------+
1416 | | Server fails to map the |
1417 | | Pseudonym in AT_IDENTITY |
1418 | | to a valid permanent identity |
1419 | +-------------------------------+
1421 | EAP-Request/SIM/Start |
1422 | (AT_PERMANENT_ID_REQ, AT_VERSION_LIST) |
1423 |<------------------------------------------------------|
1426 | EAP-Response/SIM/Start |
1427 | (AT_IDENTITY with permanent identity, AT_NONCE_MT, |
1428 | AT_SELECTED_VERSION) |
1429 |------------------------------------------------------>|
1432 After the last EAP-Response/SIM/Start message, the full
1433 authentication sequence proceeds as usual. If the EAP Server
1434 recognizes the permanent identity and is able to proceed, the server
1435 issues the EAP-Request/SIM/Challenge message.
1438 Haverinen and Salowey Expires: 27 April, 2004 [Page 24]
1441 Internet Draft EAP SIM Authentication 27 October, 2003
1444 4.3. Re-Authentication
1448 In some environments, EAP authentication may be performed
1449 frequently. Because the EAP SIM full authentication procedure makes
1450 use of the GSM SIM A3/A8 algorithms, and it therefore requires 2 or
1451 3 fresh triplets from the Authentication Centre, the full
1452 authentication procedure is not very well suitable for frequent use.
1453 Therefore, EAP SIM includes a more inexpensive re-authentication
1454 procedure that does not make use of the SIM A3/A8 algorithms and
1455 does not need new triplets from the Authentication Centre. Re-
1456 authentication can be performed in fewer roundtrips than the full
1459 Re-authentication is optional to implement for both the EAP SIM
1460 server and peer. On each EAP authentication, either one of the
1461 entities may also fall back on full authentication if they do not
1462 want to use re-authentication.
1464 Re-authentication is based on the keys derived on the preceding full
1465 authentication. The same K_aut and K_encr keys as in full
1466 authentication are used to protect EAP SIM packets and attributes,
1467 and the original Master Key from full authentication is used to
1468 generate a fresh Master Session Key, as specified in Section 4.6.
1470 On re-authentication, the peer protects against replays with an
1471 unsigned 16-bit counter, included in the AT_COUNTER attribute. On
1472 full authentication, both the server and the peer initialize the
1473 counter to one. The counter value of at least one is used on the
1474 first re-authentication. On subsequent re-authentications, the
1475 counter MUST be greater than on any of the previous re-
1476 authentications. For example, on the second re-authentication,
1477 counter value is two or greater etc. The AT_COUNTER attribute is
1480 The server includes an encrypted server nonce (AT_NONCE_S) in the
1481 re-authentication request. The AT_MAC attribute in the peer's
1482 response is calculated over NONCE_S to provide a challenge/response
1483 authentication scheme. The NONCE_S also contributes to the new
1486 Both the peer and the server SHOULD have an upper limit for the
1487 number of subsequent re-authentications allowed before a full
1488 authentication needs to be performed. Because a 16-bit counter is
1489 used in re-authentication, the theoretical maximum number of re-
1490 authentications is reached when the counter value reaches 0xFFFF.
1492 In order to use re-authentication, the peer and the EAP server need
1493 to store the following values: Master Key, latest counter value and
1494 the next re-authentication identity. K_aut, K_encr may either be
1495 stored or derived again from MK. The server may also need to store
1496 the permanent identity of the user.
1498 Haverinen and Salowey Expires: 27 April, 2004 [Page 25]
1501 Internet Draft EAP SIM Authentication 27 October, 2003
1504 4.3.2 Re-authentication Identity
1506 The re-authentication procedure makes use of separate re-
1507 authentication user identities. Pseudonyms and the permanent
1508 identity are reserved for full authentication only. If a re-
1509 authentication identity is lost and the network does not recognize
1510 it, the EAP server can fall back on full authentication.
1512 If the EAP server supports re-authentication, it MAY include the
1513 skippable AT_NEXT_REAUTH_ID attribute in the encrypted data of EAP-
1514 Request/SIM/Challenge message (Section 6.3). This attribute contains
1515 a new re-authentication identity for the next re-authentication. The
1516 peer MAY ignore this attribute, in which case it MUST use full
1517 authentication next time. If the peer wants to use re-
1518 authentication, it uses this re-authentication identity on next
1519 authentication. Even if the peer has a re-authentication identity,
1520 the peer MAY discard the re-authentication identity and use a
1521 pseudonym or the permanent identity instead, in which case full
1522 authentication MUST be performed.
1524 In environments where a realm portion is needed in the peer
1525 identity, the re-authentication identity received in
1526 AT_NEXT_REAUTH_ID MUST contain both a username portion and a realm
1527 portion, as per the NAI format. The EAP Server can choose an
1528 appropriate realm part in order to have the AAA infrastructure route
1529 subsequent re-authentication related requests to the same AAA
1530 server. For example, the realm part MAY include a portion that is
1531 specific to the AAA server. Hence, it is sufficient to store the
1532 context required for re-authentication in the AAA server that
1533 performed the full authentication.
1535 The peer MAY use the re-authentication identity in the EAP-
1536 Response/Identity packet or, in response to server's AT_ANY_ID_REQ
1537 attribute, the peer MAY use the re-authentication identity in the
1538 AT_IDENTITY attribute of the EAP-Response/SIM/Start packet. The peer
1539 MUST NOT modify the username portion of the re-authentication
1540 identity, but the peer MAY modify the realm portion or replace it
1541 with another realm portion.
1543 Even if the peer uses a re-authentication identity, the server may
1544 want to fall back on full authentication, for example because the
1545 server does not recognize the re-authentication identity or does not
1546 want to use re-authentication. In this case, the server starts the
1547 full authentication procedure by issuing an EAP-Request/SIM/Start
1548 packet. This packet always starts a full authentication sequence if
1549 it does not include the AT_ANY_ID_REQ attribute. If the server was
1550 not able to recover the peer's identity from the re-authentication
1551 identity, the server includes either the AT_FULLAUTH_ID_REQ or the
1552 AT_PERMANENT_ID_REQ attribute in this EAP request.
1558 Haverinen and Salowey Expires: 27 April, 2004 [Page 26]
1561 Internet Draft EAP SIM Authentication 27 October, 2003
1564 4.3.3 Re-authentication Procedure
1566 The following figure illustrates the re-authentication procedure.
1567 Encrypted attributes are denoted with '*'. The peer uses its re-
1568 authentication identity in the EAP-Response/Identity packet. As
1569 discussed above, an alternative way to communicate the re-
1570 authentication identity to the server is for the peer to use the
1571 AT_IDENTITY attribute in the EAP-Response/SIM/Start message. This
1572 latter case is not illustrated in the figure below, and it is only
1573 possible when the server requests the peer to send its identity by
1574 including the AT_ANY_ID_REQ attribute in the EAP-Request/SIM/Start
1577 If the server recognizes the re-authentication identity and agrees
1578 on using re-authentication, then the server sends the EAP-
1579 Request/SIM/Re-authentication packet to the peer. This packet MUST
1580 include the encrypted AT_COUNTER attribute, with a fresh counter
1581 value, the encrypted AT_NONCE_S attribute that contains a random
1582 number chosen by the server, the AT_ENCR_DATA and the AT_IV
1583 attributes used for encryption, and the AT_MAC attribute that
1584 contains a message authentication code over the packet. The packet
1585 MAY also include an encrypted AT_NEXT_REAUTH_ID attribute that
1586 contains the next re-authentication identity.
1588 Re-authentication identities are one-time identities. If the peer
1589 does not receive a new re-authentication identity, it MUST use
1590 either the permanent identity or a pseudonym identity on the next
1591 authentication to initiate full authentication.
1593 The peer verifies that the counter value is fresh (greater than any
1594 previously used value). The peer also verifies that AT_MAC is
1595 correct. The peer MAY save the next re-authentication identity from
1596 the encrypted AT_NEXT_REAUTH_ID for next time. If all checks are
1597 successful, the peer responds with the EAP-Response/SIM/Re-
1598 authentication packet, including the AT_COUNTER attribute with the
1599 same counter value and the AT_MAC attribute.
1601 The server verifies the AT_MAC attribute and also verifies that the
1602 counter value is the same that it used in the EAP-Request/SIM/Re-
1603 authentication packet. If these checks are successful, the re-
1604 authentication has succeeded and the server sends the EAP-Success
1618 Haverinen and Salowey Expires: 27 April, 2004 [Page 27]
1621 Internet Draft EAP SIM Authentication 27 October, 2003
1626 | EAP-Request/Identity |
1627 |<------------------------------------------------------|
1629 | EAP-Response/Identity |
1630 | (Includes a re-authentication identity) |
1631 |------------------------------------------------------>|
1633 | +--------------------------------+
1634 | | Server recognizes the identity |
1635 | | and agrees on using fast |
1636 | | re-authentication |
1637 | +--------------------------------+
1639 | EAP-Request/SIM/Re-authentication |
1640 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER, |
1641 | *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) |
1642 |<------------------------------------------------------|
1645 +-----------------------------------------------+ |
1646 | Peer verifies AT_MAC and the freshness of | |
1647 | the counter. Peer MAY store the new re- | |
1648 | authentication identity for next re-auth. | |
1649 +-----------------------------------------------+ |
1651 | EAP-Response/SIM/Re-authentication |
1652 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER with same value, |
1654 |------------------------------------------------------>|
1656 | +--------------------------------+
1657 | | Server verifies AT_MAC and |
1659 | +--------------------------------+
1662 |<------------------------------------------------------|
1665 4.3.4 Re-authentication Procedure when Counter is Too Small
1667 If the peer does not accept the counter value of EAP-Request/SIM/Re-
1668 authentication, it indicates the counter synchronization problem by
1669 including the encrypted AT_COUNTER_TOO_SMALL in EAP-Response/SIM/Re-
1670 authentication. The server responds with EAP-Request/SIM/Start to
1671 initiate a normal full authentication procedure. This is illustrated
1672 in the following figure. Encrypted attributes are denoted with '*'.
1678 Haverinen and Salowey Expires: 27 April, 2004 [Page 28]
1681 Internet Draft EAP SIM Authentication 27 October, 2003
1686 | EAP-Request/Identity |
1687 |<------------------------------------------------------|
1689 | EAP-Response/Identity |
1690 | (Includes a re-authentication identity) |
1691 |------------------------------------------------------>|
1693 | EAP-Request/SIM/Re-authentication |
1694 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER, |
1695 | *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) |
1696 |<------------------------------------------------------|
1698 +-----------------------------------------------+ |
1699 | AT_MAC is valid but the counter is not fresh. | |
1700 +-----------------------------------------------+ |
1702 | EAP-Response/SIM/Re-authentication |
1703 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER_TOO_SMALL, |
1704 | *AT_COUNTER, AT_MAC) |
1705 |------------------------------------------------------>|
1707 | +----------------------------------------------+
1708 | | Server verifies AT_MAC but detects |
1709 | | That peer has included AT_COUNTER_TOO_SMALL |
1710 | +----------------------------------------------+
1712 | EAP-Request/SIM/Start |
1713 | (AT_VERSION_LIST) |
1714 |<------------------------------------------------------|
1716 +---------------------------------------------------------------+
1717 | Normal full authentication follows. |
1718 +---------------------------------------------------------------+
1722 In the figure above, the first three messages are similar to the
1723 basic re-authentication case. When the peer detects that the counter
1724 value is not fresh, it includes the AT_COUNTER_TOO_SMALL attribute
1725 in EAP-Response/SIM/Re-authentication. This attribute doesn't
1726 contain any data but it is a request for the server to initiate full
1727 authentication. In this case, the peer MUST ignore the contents of
1728 the server's AT_NEXT_REAUTH_ID attribute.
1730 On receipt of AT_COUNTER_TOO_SMALL, the server verifies AT_MAC and
1731 verifies that AT_COUNTER contains the same as in the EAP-
1732 Request/SIM/Re-authentication packet. If not, the server terminates
1733 the authentication exchange and sends the EAP Failure packet. If all
1734 checks on the packet are successful, the server transmits a new EAP-
1735 Request/SIM/Start packet and the full authentication procedure is
1736 performed as usual. Since the server already knows the subscriber
1738 Haverinen and Salowey Expires: 27 April, 2004 [Page 29]
1741 Internet Draft EAP SIM Authentication 27 October, 2003
1744 identity, it MUST NOT include AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ or
1745 AT_PERMANENT_ID_REQ in the EAP-Request/SIM/Start.
1747 4.4. EAP/SIM Notifications
1749 The EAP-Request/Notification, specified in [EAP], can be used to
1750 convey a displayable message from the EAP server to the peer.
1751 Because these messages are textual messages, it may be hard for the
1752 peer to present them in the user's preferred language. Therefore,
1753 EAP/SIM uses a separate EAP/SIM message subtype to transmit
1754 localizable notification codes instead of the EAP-
1755 Request/Notification packet.
1757 The EAP server MAY issue an EAP-Request/SIM/Notification packet to
1758 the peer. The peer MAY show a notification message to the user and
1759 the peer MUST respond to the EAP server with an EAP-
1760 Response/SIM/Notification packet, even if the peer did not recognize
1761 the notification code.
1763 The notification code is a 16-bit number. The most significant bit
1764 is called the Failure bit (F bit). The F bit specifies whether the
1765 notification implies failure. The code values with the F bit set to
1766 zero (code values 0...32767) are used on unsuccessful cases. The
1767 receipt of a notification code from this range implies failed
1768 authentication, so the peer can use the notification as a failure
1769 indication. After receiving the EAP-Response/SIM/Notification for
1770 these notification codes, the server MUST send the EAP-Failure
1773 The receipt of a notification code with the F bit set to one (values
1774 32768...65536) does not imply failure, so the peer MUST NOT change
1775 its state when it receives such a notification. (This version of the
1776 protocol does not specify any notification codes with the F bit set
1779 The second most significant bit of the notification code is called
1780 the Phase bit (P bit). It specifies at which phase of the EAP/SIM
1781 exchange the notification can be used. If the P bit is set to zero,
1782 the notification can only be used after the EAP/SIM/Challenge round
1783 in full authentication or the EAP/SIM/Re-authentication round in
1784 reautentication. For these notifications, the AT_MAC attribute MUST
1785 be included in both EAP-Request/SIM/Notification and EAP-
1786 Response/SIM/Notification.
1788 If the P bit is set to one, the notification can only by used before
1789 the EAP/SIM/Challenge round in full authentication or the
1790 EAP/SIM/Re-authentication round in reauthentication. For these
1791 notifications, the AT_MAC attribute MUST NOT be included in either
1792 EAP-Request/SIM/Notification or EAP-Response/SIM/Notification. (This
1793 version of the protocol does not specify any notification codes with
1794 the P bit set to one.)
1798 Haverinen and Salowey Expires: 27 April, 2004 [Page 30]
1801 Internet Draft EAP SIM Authentication 27 October, 2003
1804 Some of the notification codes are authorization related and hence
1805 not usually considered as part of the responsibility of an EAP
1806 method. However, they are included as part of EAP/SIM because there
1807 are currently no other ways to convey this information to the user
1808 in a localizable way, and the information is potentially useful for
1809 the user. An EAP/SIM server implementation may decide never to send
1810 these EAP/SIM notifications.
1814 This section specifies the operation of the peer and the server in
1815 error cases. The subsections below require the EAP/SIM peer and
1816 server to send an error packet (EAP-Response/SIM/Client-Error or EAP
1817 Failure) in error cases. However, implementations SHOULD NOT rely
1818 upon the correct error reporting behavior of the peer,
1819 authenticator, or the server. It is possible for error and other
1820 messages to be lost in transit or for a malicious participant to
1821 attempt to consume resources by not issuing error messages. Both
1822 the peer and the EAP server SHOULD have a mechanism to clean up
1823 state even if an error message or EAP Success is not received after
1826 4.5.1 Peer Operation
1828 In general, if an EAP/SIM peer detects an error in a received
1829 EAP/SIM packet, the EAP/SIM implementation responds with the EAP-
1830 Response/SIM/Client-Error packet. In response to the EAP-
1831 Response/SIM/Client-Error, the EAP server MUST issue the EAP Failure
1832 packet and the authentication exchange terminates.
1834 By default, the peer uses the client error code 0, "unable to
1835 process packet". This error code is used in the following cases:
1837 - the peer is not able to parse the EAP request, i.e. the EAP
1838 request is malformed
1840 - the peer encountered a malformed attribute
1842 - wrong attribute types or duplicate attributes have been included
1845 - a mandatory attribute is missing
1847 - unrecognized non-skippable attribute
1849 - unrecognized or unexpected EAP/SIM Subtype in the EAP request
1851 - A RAND challenge repeated in AT_RAND
1855 - invalid pad bytes in AT_PADDING
1858 Haverinen and Salowey Expires: 27 April, 2004 [Page 31]
1861 Internet Draft EAP SIM Authentication 27 October, 2003
1864 - the peer does not want to process AT_PERMANENT_ID_REQ
1866 Separate error codes have been defined for the following error cases
1869 As specified in Section 4.1, when processing the AT_VERSION_LIST
1870 attribute, which lists the EAP/SIM versions supported by the server,
1871 if the attribute does not include a version that is implemented by
1872 the peer and allowed in the peer's security policy, then the peer
1873 MUST send the EAP-Response/SIM/Client-Error packet with the error
1874 code "unsupported version".
1876 When processing the AT_RAND attribute, the peer MUST send the EAP-
1877 Response/SIM/Client-Error packet with the error code "insufficient
1878 number of challenges", if the number of RAND challenges is smaller
1879 than what is required by peer's local policy.
1881 If the peer believes that the RAND challenges included in AT_RAND
1882 are not fresh e.g. because it is capable of remembering some
1883 previously used RANDs, the peer MUST send the EAP-
1884 Response/SIM/Client-Error packet with the error code "RANDs are not
1887 4.5.2 Server Operation
1889 If an EAP/SIM server detects an error in a received EAP/SIM
1890 response, the server MUST issue the EAP Failure packet and the
1891 authentication exchange terminates. The errors cases when the server
1892 issues an EAP Failure include the following:
1894 - the server is not able to parse the peer's EAP response
1896 - the server encounters a malformed attribute, a non-recognized non-
1897 skippable attribute, or a duplicate attribute
1899 - a mandatory attribute is missing or an invalid attribute was
1902 - unrecognized or unexpected EAP/SIM Subtype in the EAP Response
1906 - invalid AT_COUNTER
1910 As normally in EAP, the EAP server sends the EAP-Failure packet to
1911 the peer when the authentication procedure fails on the EAP Server.
1912 In EAP/SIM, this may occur for example if the EAP server does not
1913 recognize the peer identity, or if the EAP server is not able to
1914 obtain the GSM triplets for the subscriber or the authentication
1915 exchange times out. The server may also send EAP Failure if there is
1918 Haverinen and Salowey Expires: 27 April, 2004 [Page 32]
1921 Internet Draft EAP SIM Authentication 27 October, 2003
1924 an error in the received EAP/SIM response, as discussed in Section
1927 The server can send EAP-Failure at any time in the EAP exchange. The
1928 peer MUST process EAP-Failure.
1932 On full authentication, the server can only send EAP-Success after
1933 the EAP/SIM/Challenge round. The peer MUST silently discard any EAP-
1934 Success packets if they are received before the peer has
1935 successfully authenticated the server and sent the EAP-
1936 Response/SIM/Challenge packet.
1938 On re-authentication, EAP-Success can only be sent after the
1939 EAP/SIM/Re-authentication round. The peer MUST silently discard any
1940 EAP-Success packets if they are received before the peer has
1941 successfully authenticated the server and sent the EAP-
1942 Response/SIM/Re-authentication packet.
1944 If the peer receives an EAP/SIM notification (section 4.4) that
1945 indicates failure, then the peer MUST no longer accept the EAP-
1946 Success packet even if the server authentication was successfully
1951 This section specifies how keying material is generated.
1953 On EAP SIM full authentication, a Master Key (MK) is derived from
1954 the underlying GSM authentication values (Kc keys), the NONCE_MT and
1955 other relevant context as follows.
1957 MK = SHA1(Identity|n*Kc| NONCE_MT| Version List| Selected Version)
1959 In the formula above, the "|" character denotes concatenation.
1960 Identity denotes the peer identity string without any terminating
1961 null characters. It is the identity from the AT_IDENTITY attribute
1962 from the last EAP-Response/SIM/Start packet, or, if AT_IDENTITY was
1963 not used, the identity from the EAP-Response/Identity packet. The
1964 identity string is included as-is, without any changes and including
1965 the possible identity decoration. The notation n*Kc denotes the n Kc
1966 values concatenated. The Kc keys are used in the same order as the
1967 RAND challenges in AT_RAND attribute. NONCE_MT denotes the NONCE_MT
1968 value (not the AT_NONCE_MT attribute but just the nonce value). The
1969 Version List includes the 2-byte supported version numbers from
1970 AT_VERSION_LIST, in the same order as in the attribute. The Selected
1971 Version is the 2-byte selected version from AT_SELECTED_VERSION.
1972 Network byte order is used, just as in the attributes. The hash
1973 function SHA-1 is specified in [SHA-1]. If several EAP/SIM/Start
1974 roundtrips are used in an EAP/SIM exchange, then the NONCE_MT,
1975 Version List and Selected version from the last EAP/SIM/Start round
1976 are used, and the previous EAP/SIM/Start rounds are ignored.
1978 Haverinen and Salowey Expires: 27 April, 2004 [Page 33]
1981 Internet Draft EAP SIM Authentication 27 October, 2003
1984 The Master Key is fed into a Pseudo-Random number Function (PRF)
1985 which generates separate Transient EAP Keys (TEKs) for protecting
1986 EAP SIM packets, as well as a Master Session Key (MSK) for link
1987 layer security and an Extended Master Session Key (EMSK) for other
1988 purposes. On re-authentication, the same TEKs MUST be used for
1989 protecting EAP packets, but a new MSK and a new EMSK MUST be derived
1990 from the original MK and new values exchanged in the re-
1993 EAP SIM requires two TEKs for its own purposes, the authentication
1994 key K_aut to be used with the AT_MAC attribute, and the encryption
1995 key K_encr, to be used with the AT_ENCR_DATA attribute. The same
1996 K_aut and K_encr keys are used in full authentication and subsequent
1999 Key derivation is based on the random number generation specified in
2000 NIST Federal Information Processing Standards (FIPS) Publication
2001 186-2 [PRF]. The pseudo-random number generator is specified in the
2002 change notice 1 (2001 October 5) of [PRF] (Algorithm 1). As
2003 specified in the change notice (page 74), when Algorithm 1 is used
2004 as a general-purpose pseudo-random number generator, the "mod q"
2005 term in step 3.3 is omitted. The function G used in the algorithm is
2006 constructed via Secure Hash Standard as specified in Appendix 3.3 of
2007 the standard. It should be noted that the function G is very similar
2008 to SHA-1, but the message padding is different. Please refer to
2009 [PRF] for full details. For convenience, the random number algorithm
2010 with the correct modification is cited in Annex B.
2012 160-bit XKEY and XVAL values are used, so b = 160. On each full
2013 authentication, the Master Key is used as the initial secret seed-
2014 key XKEY. The optional user input values (XSEED_j) in step 3.1 are
2017 The resulting 320-bit random numbers x_0, x_1, ..., x_m-1 are
2018 concatenated and partitioned into suitable-sized chunks and used as
2019 keys in the following order: K_encr (128 bits), K_aut (128 bits),
2020 Master Session Key (64 bytes), Extended Master Session Key (64
2023 On re-authentication, the same pseudo-random number generator can be
2024 used to generate a new Master Session Key and new Initialization
2025 Vectors. The seed value XKEY' is calculated as follows:
2027 XKEY' = SHA1(Identity|counter|NONCE_S| MK)
2029 In the formula above, the Identity denotes the re-authentication
2030 identity, without any terminating null characters, from the
2031 AT_IDENTITY attribute of the EAP-Response/SIM/Start packet, or, if
2032 EAP-Response/SIM/Start was not used on re-authentication, the
2033 identity string from the EAP-Response/Identity packet. The counter
2034 denotes the counter value from AT_COUNTER attribute used in the EAP-
2035 Response/SIM/Re-authentication packet. The counter is used in
2036 network byte order. NONCE_S denotes the 16-byte NONCE_S value from
2038 Haverinen and Salowey Expires: 27 April, 2004 [Page 34]
2041 Internet Draft EAP SIM Authentication 27 October, 2003
2044 the AT_NONCE_S attribute used in the EAP-Request/SIM/Re-
2045 authentication packet. The MK is the Master Key derived on the
2046 preceding full authentication. The pseudo-random number generator is
2047 run with the new seed value XKEY', and the resulting 320-bit random
2048 numbers x_0, x_1, ..., x_m-1 are concatenated and partitioned into
2049 64-byte chunks and used as the new 64-byte Master Session Key and
2050 the new 64-byte Extended Master Session Key.
2052 The first 32 bytes of the MSK can be used as the Pairwise Master Key
2053 (PMK) for IEEE 802.11i.
2055 When the RADIUS attributes specified in [RFC 2548] are used to
2056 transport keying material, then the first 32 bytes of the MSK
2057 correspond to MS-MPPE-RECV-KEY and the second 32 bytes to MS-MPPE-
2058 SEND-KEY. In this case, only 64 bytes of keying material (the MSK)
2061 When generating the initial Master Key, the hash function is used as
2062 a mixing function to combine several session keys (Kc's) generated
2063 by the GSM authentication procedure and the random number NONCE_MT
2064 into a single session key. There are several reasons for this. The
2065 current GSM session keys are at most 64 bits, so two or more of them
2066 are needed to generate a longer key. By using a one-way function to
2067 combine the keys, we are assured that even if an attacker managed to
2068 learn one of the EAP/SIM session keys, it wouldn't help him in
2069 learning the original GSM Kc's. In addition, since we include the
2070 random number NONCE_MT in the calculation, the peer is able to
2071 verify that the EAP SIM packets it receives from the network are
2072 fresh and not a replay. (Please see also Section 9.)
2074 5. Message Format and Protocol Extensibility
2078 As specified in [EAP], EAP packets begin with the Code, Identifiers,
2079 Length, and Type fields, which are followed by EAP method specific
2080 Type-Data. The Code field in the EAP header is set to 1 for EAP
2081 requests, and to 2 for EAP Responses. The usage of the Length and
2082 Identifier fields in the EAP header are also specified in [EAP]. In
2083 EAP/SIM, the Type field is set to 18.
2085 In EAP/SIM, the Type-Data begins with an EAP/SIM header that
2086 consists of a 1-octet Subtype field and a 2-octet reserved field.
2087 The Subtype values used in EAP/SIM are defined in Section 8. The
2088 formats of the EAP header and the EAP/SIM header are shown below.
2098 Haverinen and Salowey Expires: 27 April, 2004 [Page 35]
2101 Internet Draft EAP SIM Authentication 27 October, 2003
2105 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
2106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2107 | Code | Identifier | Length |
2108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2109 | Type | Subtype | Reserved |
2110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2113 The rest of the Type-Data, immediately following the EAP/SIM header,
2114 consists of attributes that are encoded in Type, Length, Value
2115 format. The figure below shows the generic format of an attribute.
2118 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
2119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2120 | Type | Length | Value...
2121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2127 Indicates the particular type of attribute. The attribute type
2128 values are listed in Section 8.
2132 Indicates the length of this attribute in multiples of four
2133 bytes. The maximum length of an attribute is 1024 bytes. The
2134 length includes the Attribute Type and Length bytes.
2138 The particular data associated with this attribute. This field is
2139 always included and it may be two or more bytes in length. The
2140 type and length fields determine the format and length of the
2143 Attributes numbered within the range 0 through 127 are called non-
2144 skippable attributes. When an EAP/SIM peer encounters a non-
2145 skippable attribute that the peer does not recognize, the peer MUST
2146 send the EAP-Response/SIM/Client-Error packet which terminates the
2147 authentication exchange. If an EAP/SIM server encounters a non-
2148 skippable attribute that the server does not recognize, then the
2149 server sends the EAP Failure packet which terminates the
2150 authentication exchange.
2152 Attributes within the range of 128 through 255 are called skippable
2153 attributes. When a skippable attribute is encountered that is not
2154 recognized it is ignored. The rest of the attributes and message
2155 data MUST still be processed. The Length field of the attribute is
2158 Haverinen and Salowey Expires: 27 April, 2004 [Page 36]
2161 Internet Draft EAP SIM Authentication 27 October, 2003
2164 used to skip the attribute value in searching for the next
2167 Unless otherwise specified, the order of the attributes in an
2168 EAP/SIM message is insignificant and an EAP/SIM implementation
2169 should not assume a certain order to be used.
2171 Attributes can be encapsulated within other attributes. In other
2172 words, the value field of an attribute type can be specified to
2173 contain other attributes.
2175 5.2. Protocol Extensibility
2177 EAP/SIM can be extended by specifying new attribute types. If
2178 skippable attributes are used, it is possible to extend the protocol
2179 without breaking old implementations. However, any new attributes
2180 added to the EAP-Request/SIM/Start or EAP-Response/SIM/Start packets
2181 would not be integrity protected. Therefore, these messages MUST NOT
2182 be extended in the current version of EAP/SIM.
2184 When specifying new attributes, it should be noted that EAP/SIM does
2185 not support message fragmentation. Hence, the sizes of the new
2186 extensions MUST be limited so that the maximum transfer unit (MTU)
2187 of the underlying lower layer is not exceeded. According to [EAP],
2188 lower layers must provide an EAP MTU of 1020 bytes or greater, so
2189 any extensions to EAP/SIM SHOULD NOT exceed the EAP MTU of 1020
2192 Because EAP/SIM supports version negotiation, new versions of the
2193 protocol can also be specified by using a new version number.
2197 This section specifies the messages used in EAP/SIM. It specifies
2198 when a message may be transmitted or accepted, which attributes are
2199 allowed in a message, which attributes are required in a message,
2200 and other message specific details. The general message format is
2201 specified in Section 5.1.
2203 6.1. EAP-Request/SIM/Start
2205 In full authentication the first SIM specific EAP Request is EAP-
2206 Request/SIM/Start. The EAP/SIM/Start roundtrip is used for two
2207 purposes. In full authentication this packet is used to request the
2208 peer to send the AT_NONCE_MT attribute to the server. In addition,
2209 as specified in Section 4.2, the Start round trip may be used by the
2210 server for obtaining the peer identity. As discussed in Section 4.2,
2211 several Start rounds may be required in order to obtain a valid peer
2214 The server MUST always include the AT_VERSION_LIST attribute.
2218 Haverinen and Salowey Expires: 27 April, 2004 [Page 37]
2221 Internet Draft EAP SIM Authentication 27 October, 2003
2224 The server MAY include one of the following identity requesting
2225 attributes: AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, and
2226 AT_ANY_ID_REQ. These three attributes are mutually exclusive, so the
2227 server MUST NOT include more than one of the attributes.
2229 If the server has received a response from the peer, it MUST NOT
2230 issue a new EAP-Request/SIM/Start packet if it has either previously
2231 issued an EAP-Request/SIM/Start message without any identity
2232 requesting attributes or with the AT_PERMANENT_ID_REQ attribute.
2234 If the server has received a response from the peer, it MUST NOT
2235 issue a new EAP-Request/SIM/Start packet with the AT_ANY_ID_REQ or
2236 AT_FULLAUTH_ID_REQ attributes if it has previously issued an EAP-
2237 Request/SIM/Start message with the AT_FULLAUTH_ID_REQ attribute
2239 If the server has received a response from the peer, it MUST NOT
2240 issue a new EAP-Request/SIM/Start packet with the AT_ANY_ID_REQ
2241 attribute if the server has previously issued an EAP-
2242 Request/SIM/Start message with the AT_ANY_ID_REQ attribute.
2244 This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA.
2246 6.2. EAP-Response/SIM/Start
2248 The peer sends EAP-Response/SIM/Start in response to a valid EAP-
2249 Request/SIM/Start from the server.
2251 If and only if the server's EAP-Request/SIM/Start includes one of
2252 the identity requesting attributes, then the peer MUST include the
2253 AT_IDENTITY attribute. The usage of AT_IDENITY is defined in Section
2256 The AT_NONCE_MT attribute MUST NOT be included if the AT_IDENTITY
2257 with a re-authentication identity is present for re-authentication.
2258 AT_NONCE_MT MUST be included in all other cases (full
2261 The AT_SELECTED_VERSION attribute MUST NOT be included if the
2262 AT_IDENTITY attribute with a re-authentication identity is present
2263 for re-authentication. In all other cases, AT_SELECTED_VERSION MUST
2264 be included (full authentication). This attribute is used in version
2265 negotiation, as specified in Section 4.1.
2267 This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA.
2269 6.3. EAP-Request/SIM/Challenge
2271 The server sends the EAP-Request/SIM/Challenge after receiving a
2272 valid EAP-Response/SIM/Start, containing AT_NONCE_MT and
2273 AT_SELECTED_VERSION, and after successfully obtaining the subscriber
2276 The AT_RAND attribute MUST be included.
2278 Haverinen and Salowey Expires: 27 April, 2004 [Page 38]
2281 Internet Draft EAP SIM Authentication 27 October, 2003
2284 The AT_MAC attribute MUST be included. For EAP-
2285 Request/SIM/Challenge, the MAC code is calculated over the following
2288 EAP packet| NONCE_MT
2291 The EAP packet is represented as specified in Section 5.1. It is
2292 followed by the 16-byte NONCE_MT value from the peer's AT_NONCE_MT
2295 The EAP-Request/SIM/Challenge packet MAY include encrypted
2296 attributes for identity privacy and for communicating the next re-
2297 authentication identity. In this case, the AT_IV and AT_ENCR_DATA
2298 attributes are included (Section 7.3).
2300 The plaintext of the AT_ENCR_DATA value field consists of nested
2301 attributes. The nested attributes MAY include AT_PADDING (as
2302 specified in Section 7.3). If the server supports identity privacy
2303 and wants to communicate a pseudonym to the peer for the next full
2304 authentication, then the nested encrypted attributes include the
2305 AT_NEXT_PSEUDONYM attribute. If the server supports re-
2306 authentication and wants to communicate a re-authentication identity
2307 to the peer, then the nested encrypted attributes include the
2308 AT_NEXT_REAUTH_ID attribute.
2310 6.4. EAP-Response/SIM/Challenge
2312 The peer sends EAP-Response/SIM/Challenge in response to a valid
2313 EAP-Request/SIM/Challenge.
2315 The AT_MAC attribute MUST be included. For EAP-
2316 Response/SIM/Challenge, the MAC code is calculated over the
2322 The EAP packet is represented as specified in Section 5.1. The EAP
2323 packet bytes are immediately followed by the two or three SRES
2324 values concatenated, denoted above with the notation n*SRES. The
2325 SRES values are used in the same order as the corresponding RAND
2326 challenges in server's AT_RAND attribute.
2328 Later versions of this protocol MAY make use of the AT_ENCR_DATA and
2329 AT_IV attributes in this message to include encrypted (skippable)
2330 attributes. The EAP server MUST process EAP-Response/SIM/Challenge
2331 messages that include these attributes even if the server did not
2332 implement these optional attributes.
2338 Haverinen and Salowey Expires: 27 April, 2004 [Page 39]
2341 Internet Draft EAP SIM Authentication 27 October, 2003
2344 6.5. EAP-Request/SIM/Re-authentication
2346 The server sends the EAP-Request/SIM/Re-authentication message if it
2347 wants to use re-authentication, and if it has received a valid re-
2348 authentication identity in EAP-Response/Identity or EAP-
2351 AT_MAC MUST be included. No message-specific data is included in the
2352 MAC calculation. See Section 7.2.
2354 The AT_IV and AT_ENCR_DATA attributes MUST be included. The
2355 plaintext consists of the following nested encrypted attributes,
2356 which MUST be included: AT_COUNTER and AT_NONCE_S. In addition, the
2357 nested encrypted attributes MAY include the following attributes:
2358 AT_NEXT_REAUTH_ID and AT_PADDING.
2360 6.6. EAP-Response/SIM/Re-authentication
2362 The client sends the EAP-Response/SIM/Re-authentication packet in
2363 response to a valid EAP-Request/SIM/Re-authentication.
2365 The AT_MAC attribute MUST be included. For EAP-Response/SIM/Re-
2366 authentication, the MAC code is calculated over the following data:
2370 The EAP packet is represented as specified in Section 5.1. It is
2371 followed by the 16-byte NONCE_S value from the server's AT_NONCE_S
2374 The AT_IV and AT_ENCR_DATA attributes MUST be included. The nested
2375 encrypted attributes MUST include the AT_COUNTER attribute. The
2376 AT_COUNTER_TOO_SMALL attribute MAY be included in the nested
2377 encrypted attributes, and it is included in cases specified in
2378 Section 4.3. The AT_PADDING attribute MAY be included.
2380 6.7. EAP-Response/SIM/Client-Error
2382 The peer sends EAP-Response/SIM/Client-Error in error cases, as
2383 specified in Section 4.5.1.
2385 The AT_CLIENT_ERROR_CODE attribute MUST be included.
2387 The AT_MAC, AT_IV, or AT_ENCR_DATA attributes MUST NOT be used with
2390 6.8. EAP-Request/SIM/Notification
2392 The usage of this message is specified in Section 4.4.
2394 The AT_NOTIFICATION attribute MUST be included.
2398 Haverinen and Salowey Expires: 27 April, 2004 [Page 40]
2401 Internet Draft EAP SIM Authentication 27 October, 2003
2404 The AT_MAC attribute is included in cases discussed in Section 4.4.
2405 No message-specific data is included in the MAC calculation. See
2408 Later versions of this protocol MAY make use of the AT_ENCR_DATA and
2409 AT_IV attributes in this message to include encrypted (skippable)
2410 attributes. These attributes MAY be included only if the P bit of
2411 the notification code in AT_NOTIFICATION is set to zero.
2413 6.9. EAP-Response/SIM/Notification
2415 The usage of this message is specified in Section 4.4. Because this
2416 packet is only an acknowledgement of EAP-Request/SIM/Notification,
2417 it does not contain any mandatory attributes.
2419 The AT_MAC attribute is included in cases described in Section 4.4.
2420 No message-specific data is included in the MAC calculation, see
2423 Later versions of this protocol MAY make use of the AT_ENCR_DATA and
2424 AT_IV attributes in this message to include encrypted (skippable)
2425 attributes. These attributes MAY be included only if the P bit of
2426 the notification code in the AT_NOTIFICATION attribute of the
2427 server's EAP-Request/SIM/Notification packet is set to zero.
2431 This section specifies the format of message attributes. The
2432 attribute type numbers are specified in Section 8.
2434 7.1. Table of Attributes
2436 The following table provides a guide to which attributes may be
2437 found in which kinds of messages, and in what quantity. Messages are
2438 denoted with numbers in parentheses as follows: (1) EAP-
2439 Request/SIM/Start, (2) EAP-Response/SIM/Start, (3) EAP-
2440 Request/SIM/Challenge, (4) EAP-Response/SIM/Challenge, (5) EAP-
2441 Request/SIM/Notification, (6) EAP-Response/SIM/Notification, (7)
2442 EAP-Response/SIM/Client-Error (8) EAP-Request/SIM/Re-authentication,
2443 and (9) EAP-Response/SIM/Re-authentication. The column denoted with
2444 "Encr" indicates whether the attribute is a nested attribute that
2445 MUST be included within AT_ENCR_DATA, and the column denoted with
2446 "Skip" indicates whether the attribute is a skippable attribute.
2448 "0" indicates that the attribute MUST NOT be included in the
2449 message, "1" indicates that the attribute MUST be included in the
2450 message, "0-1" indicates that the attribute is sometimes included in
2451 the message, and "0*" indicates that the attribute is not included
2452 in the message in cases specified in this document, but MAY be
2453 included in the future versions of the protocol.
2458 Haverinen and Salowey Expires: 27 April, 2004 [Page 41]
2461 Internet Draft EAP SIM Authentication 27 October, 2003
2464 Attribute (1) (2) (3) (4) (5) (6) (7) (8) (9) Encr Skip
2465 AT_MAC 0 0 1 1 0-1 0-1 0 1 1 N N
2466 AT_IV 0 0 0-1 0* 0* 0* 0 1 1 N Y
2467 AT_ENCR_DATA 0 0 0-1 0* 0* 0* 0 1 1 N Y
2468 AT_PADDING 0 0 0-1 0* 0* 0* 0 0-1 0-1 Y N
2469 AT_VERSION_LIST 1 0 0 0 0 0 0 0 0 N N
2470 AT_SELECTED_VERSION 0 0-1 0 0 0 0 0 0 0 N N
2471 AT_NONCE_MT 0 0-1 0 0 0 0 0 0 0 N N
2472 AT_PERMANENT_ID_REQ 0-1 0 0 0 0 0 0 0 0 N N
2473 AT_ANY_ID_REQ 0-1 0 0 0 0 0 0 0 0 N N
2474 AT_FULLAUTH_ID_REQ 0-1 0 0 0 0 0 0 0 0 N N
2475 AT_IDENTITY 0 0-1 0 0 0 0 0 0 0 N N
2476 AT_RAND 0 0 1 0 0 0 0 0 0 N N
2477 AT_NEXT_PSEUDONYM 0 0 0-1 0 0 0 0 0 0 Y Y
2478 AT_NEXT_REAUTH_ID 0 0 0-1 0 0 0 0 0-1 0 Y Y
2479 AT_COUNTER 0 0 0 0 0 0 0 1 1 Y N
2480 AT_COUNTER_TOO_SMALL 0 0 0 0 0 0 0 0 0-1 Y N
2481 AT_NONCE_S 0 0 0 0 0 0 0 1 0 Y N
2482 AT_NOTIFICATION 0 0 0 0 1 0 0 0 0 N N
2483 AT_CLIENT_ERROR_CODE 0 0 0 0 0 0 1 0 0 N N
2486 It should be noted that attributes AT_PERMANENT_ID_REQ,
2487 AT_ANY_ID_REQ and AT_FULLAUTH_ID_REQ are mutually exclusive, so that
2488 only one of them can be included at the same time. If one of the
2489 attributes AT_IV and AT_ENCR_DATA is included, then both of the
2490 attributes MUST be included.
2494 The AT_MAC attribute is used for EAP/SIM message authentication.
2495 Section 6 specifies which messages AT_MAC MUST be included.
2497 The value field of the AT_MAC attribute contains two reserved bytes
2498 followed by a keyed message authentication code (MAC). The MAC is
2499 calculated over the whole EAP packet concatenated with optional
2500 message-specific data, with the exception that the value field of
2501 the MAC attribute is set to zero when calculating the MAC. The EAP
2502 packet includes the EAP header that begins with the Code field, the
2503 EAP/SIM header that begins with the Subtype field, and all the
2504 attributes, as specified in Section 5.1. The reserved bytes in
2505 AT_MAC are set to zero when sending and ignored on reception. The
2506 contents of the message-specific data that may be included in the
2507 MAC calculation are specified separately for each EAP/SIM message in
2510 The format of the AT_MAC attribute is shown below.
2518 Haverinen and Salowey Expires: 27 April, 2004 [Page 42]
2521 Internet Draft EAP SIM Authentication 27 October, 2003
2525 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
2526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2527 | AT_MAC | Length = 5 | Reserved |
2528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2536 The MAC algorithm is HMAC-SHA1-128 [RFC 2104] keyed hash value. (The
2537 HMAC-SHA1-128 value is obtained from the 20-byte HMAC-SHA1 value by
2538 truncating the output to 16 bytes. Hence, the length of the MAC is
2539 16 bytes.) The derivation of the authentication key (K_aut) used in
2540 the calculation of the MAC is specified in Section 4.6.
2542 When the AT_MAC attribute is included in an EAP/SIM message, the
2543 recipient MUST process the AT_MAC attribute before looking at any
2544 other attributes. If the message authentication code is invalid,
2545 then the recipient MUST ignore all other attributes in the message
2546 and operate as specified in Section 4.5.
2548 7.3. AT_IV, AT_ENCR_DATA and AT_PADDING
2550 AT_IV and AT_ENCR_DATA attributes can be used to transmit encrypted
2551 information between the EAP/SIM peer and server.
2553 The value field of AT_IV contains two reserved bytes followed by a
2554 16-byte initialization vector required by the AT_ENCR_DATA
2555 attribute. The reserved bytes are set to zero when sending and
2556 ignored on reception. The AT_IV attribute MUST be included if and
2557 only if the AT_ENCR_DATA is included. Section 4.5 specifies the
2558 operation if a packet that does not meet this condition is
2561 The sender of the AT_IV attribute chooses the initialization vector
2562 by random. The sender MUST NOT reuse the initialization vector value
2563 from previous EAP SIM packets and the sender MUST choose it freshly
2564 for each AT_IV attribute. The sender SHOULD use a good source of
2565 randomness to generate the initialization vector. Please see [RFC
2566 1750] for more information about generating random numbers for
2567 security applications. The format of AT_IV is shown below.
2578 Haverinen and Salowey Expires: 27 April, 2004 [Page 43]
2581 Internet Draft EAP SIM Authentication 27 October, 2003
2585 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
2586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2587 | AT_IV | Length = 5 | Reserved |
2588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2590 | Initialization Vector |
2593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2596 The value field of the AT_ENCR_DATA attribute consists of two
2597 reserved bytes followed by cipher text bytes encrypted using the
2598 Advanced Encryption Standard (AES) [AES] in the Cipher Block
2599 Chaining (CBC) mode of operation using the initialization vector
2600 from the AT_IV attribute. The reserved bytes are set to zero when
2601 sending and ignored on reception. Please see [CBC] for a description
2602 of the CBC mode. The format of the AT_ENCR_DATA attribute is shown
2606 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
2607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2608 | AT_ENCR_DATA | Length | Reserved |
2609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2617 The derivation of the encryption key (K_encr) is specified in
2620 The plaintext consists of nested EAP/SIM attributes.
2622 The encryption algorithm requires the length of the plaintext to be
2623 a multiple of 16 bytes. The sender may need to include the
2624 AT_PADDING attribute as the last attribute within AT_ENCR_DATA. The
2625 AT_PADDING attribute is not included if the total length of other
2626 nested attributes within the AT_ENCR_DATA attribute is a multiple of
2627 16 bytes. As usual, the Length of the Padding attribute includes the
2628 Attribute Type and Attribute Length fields. The length of the
2629 Padding attribute is 4, 8 or 12 bytes. It is chosen so that the
2630 length of the value field of the AT_ENCR_DATA attribute becomes a
2631 multiple of 16 bytes. The actual pad bytes in the value field are
2632 set to zero (0x00) on sending. The recipient of the message MUST
2633 verify that the pad bytes are set to zero. If this verification
2634 fails on the peer, then it MUST send the EAP-Response/SIM/Client-
2635 Error packet with the error code "unable to process packet" to
2636 terminate the authentication exchange. If this verification fails on
2638 Haverinen and Salowey Expires: 27 April, 2004 [Page 44]
2641 Internet Draft EAP SIM Authentication 27 October, 2003
2644 the server, then the server sends EAP Failure to terminate the
2645 authentication exchange. The format of the AT_PADDING attribute is
2649 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
2650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2651 | AT_PADDING | Length | Padding... |
2652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
2655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2658 7.4. AT_VERSION_LIST
2660 The format of the AT_VERSION_LIST attribute is shown below.
2663 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
2664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2665 | AT_VERSION_L..| Length | Actual Version List Length |
2666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2667 | Supported Version 1 | Supported Version 2 |
2668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2672 | Supported Version N | Padding |
2673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2676 This attribute is used in version negotiation, as specified in
2677 Section 4.1. The attribute contains the version numbers supported by
2678 the EAP/SIM server. The server MUST only include versions that it
2679 implements and that are allowed in its security policy. The server
2680 SHOULD list the versions in the order of preference, most preferred
2681 versions first. At least one version number MUST be included. The
2682 version number for the protocol described in this document is one
2685 The value field of this attribute begins with 2-byte Actual Version
2686 List Length, which specifies the length of the Version List in
2687 bytes, not including the Actual Version List Length attribute
2688 length. This field is followed by the list of the versions supported
2689 by the server, which each have a length of 2 bytes. For example, if
2690 there is only one supported version, then the Actual Version List
2691 Length is 2. Because the length of the attribute must be a multiple
2692 of 4 bytes, the sender pads the value field with zero bytes when
2698 Haverinen and Salowey Expires: 27 April, 2004 [Page 45]
2701 Internet Draft EAP SIM Authentication 27 October, 2003
2704 7.5. AT_SELECTED_VERSION
2706 The format of the AT_SELECTED_VERSION attribute is shown below.
2709 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
2710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2711 | AT_SELECTED...| Length = 1 | Selected Version |
2712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2715 This attribute is used in version negotiation, as specified in
2716 Section 4.1. The value field of this attribute contains a two-byte
2717 version number, which indicates the EAP/SIM version that the peer
2722 The format of the AT_NONCE_MT attribute is shown below.
2725 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
2726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2727 |AT_NONCE_MT | Length = 5 | Reserved |
2728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2736 The value field of the NONCE_MT attribute contains two reserved
2737 bytes followed by a random number generated by the peer (16 bytes
2738 long) freshly for this EAP/SIM authentication exchange. The random
2739 number is used as a seed value for the new keying material. The
2740 reserved bytes are set to zero upon sending and ignored upon
2743 The peer MUST choose the NONCE_MT value freshly for each EAP/SIM
2744 authentication exchange. If an EAP/SIM exchange includes several
2745 EAP/SIM/Start rounds, then the peer MAY use the same NONCE_MT value
2746 in all EAP-Response/SIM/Start packets. The peer SHOULD use a good
2747 source of randomness to generate NONCE_MT. Please see [RFC 1750] for
2748 more information about generating random numbers for security
2751 7.7. AT_PERMANENT_ID_REQ
2753 The format of the AT_PERMANENT_ID_REQ attribute is shown below.
2758 Haverinen and Salowey Expires: 27 April, 2004 [Page 46]
2761 Internet Draft EAP SIM Authentication 27 October, 2003
2765 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
2766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2767 |AT_PERM..._REQ | Length = 1 | Reserved |
2768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2771 The use of the AT_PERMANENT_ID_REQ is defined in Section 4.2. The
2772 value field only contains two reserved bytes, which are set to zero
2773 on sending and ignored on reception.
2777 The format of the AT_ANY_ID_REQ attribute is shown below.
2780 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
2781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2782 |AT_ANY_ID_REQ | Length = 1 | Reserved |
2783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2786 The use of the AT_ANY_ID_REQ is defined in Section 4.2. The value
2787 field only contains two reserved bytes, which are set to zero on
2788 sending and ignored on reception.
2790 7.9. AT_FULLAUTH_ID_REQ
2792 The format of the AT_FULLAUTH_ID_REQ attribute is shown below.
2795 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
2796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2797 |AT_ANY_ID_REQ | Length = 1 | Reserved |
2798 +---------------+---------------+-------------------------------+
2800 The use of the AT_FULLAUTH_ID_REQ is defined in Section 4.2. The
2801 value field only contains two reserved bytes, which are set to zero
2802 on sending and ignored on reception.
2806 The format of the AT_IDENTITY attribute is shown below.
2818 Haverinen and Salowey Expires: 27 April, 2004 [Page 47]
2821 Internet Draft EAP SIM Authentication 27 October, 2003
2825 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
2826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2827 | AT_IDENTITY | Length | Actual Identity Length |
2828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2830 . Identity (optional) .
2833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2835 The use of the AT_IDENTITY is defined in Section 4.2. The value
2836 field of this attribute begins with 2-byte actual identity length,
2837 which specifies the length of the identity in bytes. This field is
2838 followed by the subscriber identity of the indicated actual length.
2839 The identity is the permanent identity, a pseudonym identity or a
2840 re-authentication identity. The identity format is specified in
2841 Section 4.2.1. The same identity format is used in the AT_IDENTITY
2842 attribute and the EAP-Response/Identity packet, with the exception
2843 that the peer MUST NOT decorate the identity it includes in
2844 AT_IDENTITY. The identity does not include any terminating null
2845 characters. Because the length of the attribute must be a multiple
2846 of 4 bytes, the sender pads the identity with zero bytes when
2851 The format of the AT_RAND attribute is shown below.
2854 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
2855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2856 | AT_RAND | Length | Reserved |
2857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2864 The value field of this attribute contains two reserved bytes
2865 followed by n GSM RANDs (each 16 bytes long). The reserved bytes are
2866 set to zero upon sending and ignored upon reception.
2868 The number of RAND challenges (n) MUST be two or three. The peer
2869 MUST verify that the number of RAND challenges is sufficient
2870 according to the peer's policy. The server MUST use different RAND
2871 values. In other words, a RAND value can only be included once in
2872 AT_RAND. When processing the AT_RAND attribute, the peer MUST check
2873 that the RANDs are different.
2875 The EAP server MUST obtain fresh RANDs for each EAP/SIM full
2876 authentication exchange. More specifically, the server MUST consider
2878 Haverinen and Salowey Expires: 27 April, 2004 [Page 48]
2881 Internet Draft EAP SIM Authentication 27 October, 2003
2884 RANDs it included in AT_RAND to be consumed if the server receives
2885 an EAP-Response/SIM/Challenge packet with a valid AT_MAC, or an EAP-
2886 Response/SIM/Client-Error with the code "insufficient number of
2887 challenges" or "RANDs are not fresh". However, in other cases (if
2888 the server does not receive any response to its EAP-
2889 Request/SIM/Challenge packet, or if the server receives some other
2890 kind of response than the cases listed above), the server does not
2891 need to consider the RANDs to be consumed, and the server MAY re-use
2892 the RANDs in the AT_RAND attribute of the next full authentication
2895 7.12. AT_NEXT_PSEUDONYM
2897 The format of the AT_NEXT_PSEUDONYM attribute is shown below.
2900 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
2901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2902 | AT_NEXT_PSEU..| Length | Actual Pseudonym Length |
2903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2910 The value field of this attribute begins with 2-byte actual
2911 pseudonym length, which specifies the length of the following
2912 pseudonym in bytes. This field is followed by a pseudonym username
2913 that the peer can use in the next authentication. The username MUST
2914 NOT include any realm portion. The username does not include any
2915 terminating null characters. Because the length of the attribute
2916 must be a multiple of 4 bytes, the sender pads the pseudonym with
2917 zero bytes when necessary. The username encoding MUST follow the
2918 UTF-8 transformation format [RFC2279].
2920 7.13. AT_NEXT_REAUTH_ID
2922 The format of the AT_NEXT_REAUTH_ID attribute is shown below.
2925 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
2926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2927 | AT_NEXT_REAU..| Length | Actual Re-Auth Identity Length|
2928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2930 . Next Re-authentication Username .
2933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2935 The value field of this attribute begins with 2-byte actual re-
2936 authentication identity length which specifies the length of the
2938 Haverinen and Salowey Expires: 27 April, 2004 [Page 49]
2941 Internet Draft EAP SIM Authentication 27 October, 2003
2944 following re-authentication identity in bytes. This field is
2945 followed by a re-authentication identity that the peer can use in
2946 the next re-authentication, as described in Section 4.3. In
2947 environments where a realm portion is required, the re-
2948 authentication identity includes both a username portion and a realm
2949 name portion. The re-authentication identity does not include any
2950 terminating null characters. Because the length of the attribute
2951 must be a multiple of 4 bytes, the sender pads the re-authentication
2952 identity with zero bytes when necessary. The identity encoding MUST
2953 follow the UTF-8 transformation format [RFC2279].
2957 The format of the AT_COUNTER attribute is shown below.
2960 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
2961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2962 | AT_COUNTER | Length = 1 | Counter |
2963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2965 The value field of the AT_COUNTER attribute consists of a 16-bit
2966 unsigned integer counter value, represented in network byte order.
2968 7.15. AT_COUNTER_TOO_SMALL
2970 The format of the AT_COUNTER_TOO_SMALL attribute is shown below.
2973 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
2974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2975 | AT_COUNTER...| Length = 1 | Reserved |
2976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2979 The value field of this attribute consists of two reserved bytes,
2980 which are set to zero upon sending and ignored upon reception.
2984 The format of the AT_NONCE_S attribute is shown below.
2998 Haverinen and Salowey Expires: 27 April, 2004 [Page 50]
3001 Internet Draft EAP SIM Authentication 27 October, 2003
3006 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
3007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3008 | AT_COUNTER | Length = 1 | Counter |
3009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3010 | AT_NONCE_S | Length = 5 | Reserved |
3011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3019 The value field of the AT_NONCE_S attribute contains two reserved
3020 bytes followed by a random number generated by the server (16 bytes)
3021 freshly for this EAP/SIM re-authentication. The random number is
3022 used as challenge for the peer and also a seed value for the new
3023 keying material. The reserved bytes are set to zero upon sending and
3024 ignored upon reception.
3026 The server MUST choose the NONCE_S value freshly for each EAP/SIM
3027 re-authentication exchange. The server SHOULD use a good source of
3028 randomness to generate NONCE_S. Please see [RFC 1750] for more
3029 information about generating random numbers for security
3032 7.17. AT_NOTIFICATION
3034 The format of the AT_NOTIFICATION attribute is shown below.
3037 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
3038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3039 |AT_NOTIFICATION| Length = 1 |F|P| Notification Code |
3040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3042 The value field of this attribute contains a two-byte notification
3043 code. The first and second bit (F and P) of the notification code
3044 are interpreted as described in Section 4.4.
3046 The notification code values listed below have been reserved. The
3047 descriptions below illustrate the semantics of the notifications.
3048 The peer implementation MAY use different wordings when presenting
3049 the notifications to the user. The "requested service" depends on
3050 the environment where EAP/SIM is applied.
3052 1026 - User has been temporarily denied access to the requested
3053 service. (Implies failure, used after the challenge round)
3055 1031 - User has not subscribed to the requested service (implies
3056 failure, used after the challenge round)
3058 Haverinen and Salowey Expires: 27 April, 2004 [Page 51]
3061 Internet Draft EAP SIM Authentication 27 October, 2003
3064 7.18. AT_CLIENT_ERROR_CODE
3066 The format of the AT_CLIENT_ERROR_CODE attribute is shown below.
3069 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
3070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3071 |AT_CLIENT_ERR..| Length = 1 | Client Error Code |
3072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3074 The value field of this attribute contains a two-byte client error
3075 code. The following error code values have been reserved.
3077 0 "unable to process packet": a general error code
3079 1 "unsupported version": the peer does not support any of
3080 the versions listed in AT_VERSION_LIST
3082 2 "insufficient number of challenges": the peer's policy
3083 requires more triplets than the server included in AT_RAND
3085 3 "RANDs are not fresh": the peer believes that the RAND
3086 challenges included in AT_RAND were not fresh
3090 8. IANA Considerations
3092 The realm name "owlan.org" has been reserved for NAI realm names
3093 generated from the IMSI.
3095 IANA has assigned the EAP type number 18 for this protocol.
3097 EAP/SIM messages include a Subtype field. The following Subtypes are
3100 Start..........................................10
3101 Challenge......................................11
3102 Notification...................................12
3103 Re-authentication..............................13
3104 Client-Error...................................14
3118 Haverinen and Salowey Expires: 27 April, 2004 [Page 52]
3121 Internet Draft EAP SIM Authentication 27 October, 2003
3124 The Subtype-specific data is composed of attributes, which have
3125 attribute type numbers. The following attribute types are specified:
3127 AT_RAND.........................................1
3128 AT_PADDING......................................6
3129 AT_NONCE_MT.....................................7
3130 AT_PERMANENT_ID_REQ............................10
3131 AT_MAC.........................................11
3132 AT_NOTIFICATION................................12
3133 AT_ANY_ID_REQ..................................13
3134 AT_IDENTITY....................................14
3135 AT_VERSION_LIST................................15
3136 AT_SELECTED_VERSION............................16
3137 AT_FULLAUTH_ID_REQ.............................17
3138 AT_COUNTER.....................................19
3139 AT_COUNTER_TOO_SMALL...........................20
3140 AT_NONCE_S.....................................21
3141 AT_CLIENT_ERROR_CODE...........................22
3143 AT_IV.........................................129
3144 AT_ENCR_DATA..................................130
3145 AT_NEXT_PSEUDONYM.............................132
3146 AT_NEXT_REAUTH_ID.............................133
3150 The AT_NOTIFICATION attribute contains a notification code value.
3151 Values 1024, 1026 and 1031 have been specified in Section 7.17 of
3154 The AT_VERSION_LIST and AT_SELECTED_VERSION attributes contain
3155 version numbers. Version 1 has been specified in Section 7.4 of this
3158 The AT_CLIENT_ERROR_CODE attribute contains a client error code.
3159 Values 0, 1, 2 and 3 have been specified in Section 7.18 of this
3162 All requests for value assignment from the various number spaces
3163 described in this document require proper documentation, according
3164 to the "Specification Required" policy described in [RFC 2434].
3165 Requests must be specified in sufficient detail so that
3166 interoperability between independent implementations is possible.
3167 Possible forms of documentation include, but are not limited to,
3168 RFCs, the products of another standards body (e.g. 3GPP), or
3169 permanently and readily available vendor design notes.
3171 EAP SIM and EAP AKA [EAP AKA] are "sister" protocols with similar
3172 message structure and protocol numbering spaces. Many attributes and
3173 message Subtypes have the same protocol numbers in these two
3174 protocols. Hence, it is recommended that the same protocol number
3175 value SHOULD NOT be allocated for two different purposes in EAP AKA
3178 Haverinen and Salowey Expires: 27 April, 2004 [Page 53]
3181 Internet Draft EAP SIM Authentication 27 October, 2003
3184 9. Security Considerations
3186 The EAP base protocol [EAP] highlights several attacks that are
3187 possible against the EAP protocol as there is no inherent security
3188 mechanisms provided. This section discusses the claimed security
3189 properties of EAP SIM as well as vulnerabilities and security
3192 9.1. Identity Protection
3194 EAP/SIM includes optional identity privacy support that protects the
3195 privacy of the subscriber identity against passive eavesdropping.
3196 The mechanism cannot be used on the first EAP exchange with a given
3197 server, because the permanent identity will have to be sent in the
3198 clear. The terminal SHOULD store the pseudonym in a non-volatile
3199 memory so that it can be maintained across reboots. An active
3200 attacker that impersonates the network may use the
3201 AT_PERMANENT_ID_REQ attribute to attempt to learn the subscriber's
3202 permanent identity. However, as discussed in Section 4.2.2, the
3203 terminal can refuse to send the cleartext permanent identity if it
3204 believes that the network should be able to recognize the pseudonym.
3206 If the peer and server cannot guarantee that the pseudonym will be
3207 maintained reliably and identity privacy is required then additional
3208 protection from an external security mechanism such as Protected
3209 Extensible Authentication Protocol (PEAP) [PEAP] may be used. If an
3210 external security mechanism is in use the identity privacy features
3211 of EAP-SIM may not be useful. The security considerations of using
3212 an external security mechanism with EAP-SIM are beyond the scope of
3215 9.2. Mutual Authentication and Triplet Exposure
3217 EAP/SIM provides mutual authentication. The peer believes that the
3218 network is authentic because the network can calculate a correct
3219 AT_MAC value in the EAP-Request/SIM/Challenge packet. To calculate
3220 AT_MAC it is sufficient to know the RAND and Kc values from the GSM
3221 triplets (RAND, SRES, Kc) used in the authentication. Because the
3222 network selects the RAND challenges and the triplets, an attacker
3223 that knows n (2 or 3) GSM triplets for the subscriber is able to
3224 impersonate a valid network to the peer. Given physical access to
3225 the SIM card, it is easy to obtain any number of GSM triplets.
3226 Another way to obtain triplets is to mount an attack on the peer
3227 platform via a virus or other malicious piece of software. The peer
3228 SHOULD be protected against triplet querying attacks by malicious
3231 If the same SIM credentials are also used for GSM traffic, the
3232 triplets could be revealed in the GSM network; see Section 9.5.
3234 Since the security of EAP/SIM is based on the secrecy of Kc keys
3235 care should be taken not to expose these values to attackers when
3236 they are transmitted between entities, stored or handled. Steps
3238 Haverinen and Salowey Expires: 27 April, 2004 [Page 54]
3241 Internet Draft EAP SIM Authentication 27 October, 2003
3244 should be taken to limit the transport, storage and handling of
3245 these values outside a protected environment. These considerations
3246 are important at both the peer and EAP server implementations.
3248 In GSM, the network is allowed to reuse the RAND challenge in
3249 consecutive authentication exchanges. This is not allowed in
3250 EAP/SIM. The EAP/SIM server is mandated to use fresh triplets (RAND
3251 challenges) in consecutive authentication exchanges, as specified in
3252 Section 3. However, EAP SIM does not mandate any means for the peer
3253 to check if the RANDs are fresh, so the security of the scheme leans
3254 on the secrecy of the triplets. (However, the peer MAY employ
3255 implementation-specific mechanisms to remember some of the
3256 previously used RANDs, and the peer MAY check the freshness of the
3257 server's RANDs. The operation in cases when the peer detects that
3258 the RANDs are not fresh is specified in Section 4.5.1.)
3260 Preventing the re-use of authentication vectors has been taken into
3261 account in the design of the UMTS Authentication and Key Agreement
3262 (AKA), which is used in EAP AKA [EAP AKA]. In cases when the triplet
3263 re-use considerations of EAP SIM are not considered sufficient, it
3264 is advised to use EAP AKA.
3268 EAP/SIM supports key derivation. The key hierarchy is specified in
3269 Section 4.6. EAP/SIM combines several GSM triplets in order to
3270 generate stronger keying material and stronger AT_MAC values. The
3271 actual strength of the resulting keys depends, among other things,
3272 on some operator specific parameters including authentication
3273 algorithms, the strength of the Ki key, and the quality of the RAND
3274 challenges. For example, some SIM cards generate Kc keys with 10
3275 bits set to zero. Such restrictions may prevent the concatenation
3276 technique from yielding strong session keys. Because the strength of
3277 the Ki key is 128 bits, the ultimate strength of any derived secret
3278 key material is never more than 128 bits.
3280 It should also be noted that a security policy that allows n=2 to be
3281 used may compromise the security of a future policy that requires
3282 three triplets, because adversaries may be able to exploit the
3283 messages exchanged when the weaker policy was applied.
3285 There is no known way to obtain complete GSM triplets by mounting an
3286 attack against EAP/SIM. A passive eavesdropper can learn n*RAND and
3287 AT_MAC and may be able to link this information to the subscriber
3288 identity. An active attacker that impersonates a GSM subscriber can
3289 easily obtain n*RAND and AT_MAC values from the EAP server for any
3290 given subscriber identity. However, calculating the Kc and SRES
3291 values from AT_MAC would require the attacker to reverse the keyed
3292 message authentication code function HMAC-SHA1-128.
3294 As EAP SIM does not expose any values calculated from an individual
3295 GSM Kc keys, it is not possible to mount a brute force attack on
3296 just one of the Kc keys in EAP SIM. Therefore, when considering
3298 Haverinen and Salowey Expires: 27 April, 2004 [Page 55]
3301 Internet Draft EAP SIM Authentication 27 October, 2003
3304 brute force attacks on the values exposed in EAP SIM, the effective
3305 length of EAP SIM session keys is not compromised by the fact that
3306 they are combined from several shorter keys, i.e the effective
3307 length of 128 bits may be achieved. For additional considerations
3308 see Section 9.5. The EAP Transient Keys used to protect EAP SIM
3309 packets (K_encr, K_aut) and the Master Session Key are
3310 cryptographically separate. An attacker cannot derive any non-
3311 trivial information from K_encr or K_aut based on the Master Session
3312 Key or vice versa. An attacker also cannot calculate the pre-shared
3313 secret from the GSM Kc keys used, EAP SIM K_encr, EAP SIM K_aut, or
3314 from the Master Session Key.
3316 Each EAP/SIM exchange generates fresh keying material. The EAP SIM
3317 peer contributes to the keying material with the NONCE_MT parameter,
3318 which must be chosen freshly for each exchange. Hence, even if the
3319 RAND challenges were reused from a previous session, the session
3320 keys will be different. Please see section 9.2 for more information
3323 9.4. Dictionary Attacks
3325 Because EAP/SIM is not a password protocol, it is not vulnerable to
3326 dictionary attacks. (The pre-shared symmetric secret stored on the
3327 SIM card shall not be a weak password.)
3329 9.5. Credentials Reuse
3331 EAP SIM cannot prevent attacks over the GSM or GPRS radio networks.
3332 If the same SIM credentials are also used in GSM or GPRS, it is
3333 possible to mount attacks over the cellular interface.
3335 A passive attacker can eavesdrop GSM or GPRS traffic and obtain
3336 RAND, SRES pairs. He can then use a brute force attack to obtain the
3337 64-bit Kc keys used to encrypt the GSM or GPRS data. This makes it
3338 possible to attack each 64-bit key separately. If the attacker can
3339 obtain 2-3 Kc keys, he can then impersonate a valid network to an
3342 An active attacker can mount a "rogue GSM/GPRS base station attack",
3343 replaying previously seen RAND challenges to obtain SRES values. He
3344 can then use a brute force attack to obtain the Kc keys. If
3345 successful, the attacker can impersonate a valid network or decrypt
3346 previously seen traffic, because EAP-SIM does not provide perfect
3347 forward secrecy (PFS).
3349 Because this attack requires the attacker to build a rogue GSM base
3350 station (or at least eavesdrop the GSM traffic), the cost of the
3351 attack is not negligible; it is the same cost as usually in GSM.
3352 However, due to several weaknesses in the GSM encryption algorithms,
3353 the effective key strength of the Kc keys is much less than the
3354 expected 64 bits (no more than 40 bits if the A5/1 GSM encryption
3355 algorithm is used; an active attacker can force the peer to use the
3356 weaker A5/2 algorithm that can be broken in less than a second).
3358 Haverinen and Salowey Expires: 27 April, 2004 [Page 56]
3361 Internet Draft EAP SIM Authentication 27 October, 2003
3364 Because the A5 encryption algorithm is not used in EAP SIM, and
3365 because EAP SIM does not expose any values calculated from
3366 individual Kc keys, it should be noted that these attacks are not
3367 possible if the SIM credentials used in EAP/SIM are not shared in
3370 9.6. Integrity and Replay Protection, and Confidentiality
3372 AT_MAC, AT_IV and AT_ENCR_DATA attributes are used to provide
3373 integrity, replay and confidentiality protection for EAP/SIM
3374 requests and responses. Integrity protection includes the EAP
3375 header. These attributes cannot be used during the EAP/SIM/Start
3376 roundtrip. However, the protocol values (identity, NONCE_MT and
3377 version negotiation parameters) are protected by later EAP/SIM
3380 Integrity protection (AT_MAC) is based on a keyed message
3381 authentication code. Confidentiality (AT_ENCR_DATA and AT_IV) is
3382 based on a block cipher.
3384 On full authentication, replay protection is provided by the RAND
3385 values from the underlying GSM authentication scheme and the use of
3386 the NONCE_MT value. On re-authentication, a counter and a server
3387 nonce is used to provide replay protection.
3389 Contents of the EAP-Response/Identity packet are implicitly
3390 integrity protected by including them in key derivation.
3392 Because EAP/SIM is not a tunneling method, EAP Notification, EAP
3393 Success or EAP Failure packets are not confidential, integrity
3394 protected or replay protected in EAP/SIM. On physically insecure
3395 networks, this may enable an attacker to send false notifications to
3396 the peer and to mount denial of service attacks by spoofing these
3399 An eavesdropper will see the EAP Notification, EAP Success and EAP
3400 Failure packets sent in the clear. With EAP SIM, confidential
3401 information MUST NOT be transmitted in EAP Notification packets.
3404 9.7. Negotiation Attacks
3406 EAP/SIM does not protect the EAP-Response/Nak packet. Because
3407 EAP/SIM does not protect the EAP method negotiation, EAP method
3408 downgrading attacks may be possible, especially if the user uses the
3409 same identity with EAP/SIM and other EAP methods.
3411 EAP/SIM includes a version negotiation procedure. In EAP/SIM the
3412 keying material derivation includes the version list and selected
3413 version to ensure that the protocol cannot be downgraded and that
3414 the peer and server use the same version of EAP/SIM.
3418 Haverinen and Salowey Expires: 27 April, 2004 [Page 57]
3421 Internet Draft EAP SIM Authentication 27 October, 2003
3424 As described in Section 5, EAP/SIM allows the protocol to be
3425 extended by defining new attribute types. When defining such
3426 attributes, it should noted that any extra attributes included in
3427 EAP-Request/SIM/Start or EAP-Response/SIM/Start packets are not
3428 included in the MACs later on, and thus some other precautions must
3429 be taken to avoid modifications to them.
3431 EAP/SIM does not support ciphersuite negotiation.
3435 EAP/SIM includes an optional re-authentication ("fast reconnect")
3436 procedure, as recommended in [EAP] for EAP types that are intended
3437 for physically insecure networks.
3439 9.9. Acknowledged Result Indications
3441 EAP/SIM does not provide acknowledged or integrity protected Success
3442 or Failure indications.
3444 If an EAP Success or EAP Failure packet is lost when using EAP/SIM
3445 over an unreliable medium and if the protocol over which EAP/SIM is
3446 transported does not address the possible loss of Success or
3447 Failure, then the peer and EAP server may end up having a different
3448 interpretation of the state of the authentication conversation.
3450 On physically insecure networks, an attacker may mount denial of
3451 service attacks by sending false EAP Success or EAP Failure
3452 indications. However, the attacker cannot force the peer or the EAP
3453 server to believe successful authentication has occurred when mutual
3454 authentication failed or has not happened yet.
3456 9.10. Man-in-the-middle Attacks
3458 In order to avoid man-in-the-middle attacks and session hijacking,
3459 user data SHOULD be integrity protected on physically insecure
3460 networks. The EAP/SIM Master Session Key or keys derived from it MAY
3461 be used as the integrity protection keys, or, if an external
3462 security mechanism such as PEAP is used, then the link integrity
3463 protection keys MAY be derived by the external security mechanism.
3465 There are man-in-the-middle attacks associated with the use of any
3466 EAP method within a tunneled protocol such as PEAP, or within a
3467 sequence of EAP methods followed by each other. This specification
3468 does not address these attacks. If EAP/SIM is used with a tunneling
3469 protocol or as part of a sequence of methods, there should be
3470 cryptographic binding provided between the protocols and EAP/SIM to
3471 prevent man-in-the-middle attacks through rogue authenticators being
3472 able to setup one-way authenticated tunnels. The EAP/SIM Master
3473 Session Key MAY be used to provide the cryptographic binding.
3474 However the mechanism how the binding is provided depends on the
3475 tunneling or sequencing protocol and is beyond the scope of this
3478 Haverinen and Salowey Expires: 27 April, 2004 [Page 58]
3481 Internet Draft EAP SIM Authentication 27 October, 2003
3484 9.11. Generating Random Numbers
3486 An EAP/SIM implementation SHOULD use a good source of randomness to
3487 generate the random numbers required in the protocol. Please see
3488 [RFC 1750] for more information on generating random numbers for
3489 security applications.
3493 This section provides the security claims required by [EAP].
3495 [a] Intended use. EAP SIM is intended for use over both physically
3496 insecure networks and physically or otherwise secure networks.
3497 Applicable media include but are not limited to PPP, IEEE 802 wired
3498 networks and IEEE 802.11.
3500 [b] Mechanism. EAP SIM is based on the GSM SIM mechanism, which is a
3501 challenge/response authentication and key agreement mechanism based
3502 on a symmetric 128-bit pre-shared secret. EAP SIM also makes use of
3503 a peer challenge to provide mutual authentication.
3505 [c] Security claims. The security properties of the method are
3506 discussed in Section 9.
3508 [d] Key strength. EAP SIM supports key derivation with 128-bit
3509 effective key strength. However, as discussed in Section 9, if the
3510 same credentials are used in GSM/GPRS and in EAP/SIM, then the key
3511 strength may be reduced considerably, basically to the same level as
3512 in GSM, by mounting attacks over GSM/GPRS. For example an active
3513 attack using a false GSM/GPRS base station reduces the effective key
3514 strength to almost zero.
3516 [e] Description of key hierarchy. Please see Section 4.6.
3518 [f] Indication of vulnerabilities. Vulnerabilities are discussed in
3521 11. Intellectual Property Right Notice
3523 On IPR related issues, Nokia refers to the Nokia Statement on Patent
3524 licensing, see http://www.ietf.org/ietf/IPR/NOKIA.
3526 12. Acknowledgements and Contributions
3530 In addition to the editors, Nora Dabbous, Jose Puthenkulam, and
3531 Prasanna Satarasinghe were significant contributors to this
3534 Pasi Eronen and Jukka-Pekka Honkanen contributed Annex A.
3538 Haverinen and Salowey Expires: 27 April, 2004 [Page 59]
3541 Internet Draft EAP SIM Authentication 27 October, 2003
3544 12.2. Acknowledgements
3546 Juha Ala-Laurila, N. Asokan, Jan-Erik Ekberg, Patrik Flykt, Jukka-
3547 Pekka Honkanen, Antti Kuikka, Jukka Latva, Lassi Lehtinen, Jyri
3548 Rinnemaa, Timo Takam
\84ki and Raimo Vuonnala contributed many original
3549 ideas and concepts to this protocol.
3551 N. Asokan and Jukka-Pekka Honkanen contributed and helped in
3552 innumerable ways during the whole development of the protocol.
3554 Valtteri Niemi and Kaisa Nyberg contributed substantially to the
3555 design of the key derivation and the re-authentication procedure,
3556 and have also provided their cryptographic expertise in many
3557 discussions related to this protocol.
3559 Simon Blake-Wilson provided most helpful comments on key derivation
3560 and version negotiation.
3562 Thanks to Greg Rose for his most valuable comments [S3-020125].
3564 Thanks to Bernard Aboba, Vladimir Alperovich, Jacques Caron, Gopal
3565 Dommety, Pasi Eronen, Augustin Farrugia, Mark Grayson, Max de Groot,
3566 Prakash Iyer, Nishi Kant, Victor Lortz, Sarvar Patel, Tom Porcher,
3567 Michael Richardson, Stefan Schr÷der, Jesse Walker and Thomas Wieland
3568 for their contributions and critiques. Special thanks to Max for
3569 proposing improvements to the MAC calculation.
3571 Thanks to Glen Zorn for reviewing this document and for providing
3572 most useful comments on the protocol.
3574 The identity privacy support is based on the identity privacy
3575 support of [EAP SRP]. The attribute format is based on the extension
3576 format of Mobile IPv4 [RFC 3344].
3578 This protocol has been partly developed in parallel with EAP AKA
3579 [EAP AKA], and hence this specification incorporates many ideas from
3582 Normative References
3584 [GSM 03.20] GSM Technical Specification GSM 03.20 (ETS 300 534):
3585 "Digital cellular telecommunication system (Phase 2); Security
3586 related network functions", European Telecommunications Standards
3587 Institute, August 1997.
3589 [RFC 2119] S. Bradner, "Key words for use in RFCs to indicate
3590 Requirement Levels", RFC 2119, March 1997.
3592 [GSM 03.03] GSM Technical Specification GSM 03.03 (ETS 300 523):
3593 "Digital cellular telecommunication system (Phase 2); Numbering,
3594 addressing and identification", European Telecommunications
3595 Standards Institute, April 1997.
3598 Haverinen and Salowey Expires: 27 April, 2004 [Page 60]
3601 Internet Draft EAP SIM Authentication 27 October, 2003
3604 [RFC 2486] Aboba, B. and M. Beadles, "The Network Access
3605 Identifier", RFC 2486, January 1999.
3607 [RFC 2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing
3608 for Message Authentication", RFC 2104, February 1997.
3610 [AES] Federal Information Processing Standards (FIPS) Publication
3611 197, "Advanced Encryption Standard (AES)", National Institute of
3612 Standards and Technology, November 26, 2001.
3613 http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
3615 [CBC] NIST Special Publication 800-38A, "Recommendation for Block
3616 Cipher Modes of Operation - Methods and Techniques", National
3617 Institute of Standards and Technology, December 2001.
3618 http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
3620 [SHA-1] Federal Information Processing Standard (FIPS) Publication
3621 180-1, "Secure Hash Standard," National Institute of Standards and
3622 Technology, U.S. Department of Commerce, April 17, 1995.
3624 [PRF] Federal Information Processing Standards (FIPS) Publication
3625 186-2 (with change notice), "Digital Signature Standard (DSS)",
3626 National Institute of Standards and Technology, January 27, 2000.
3627 Available on-line at:
3628 http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-
3631 [RFC 2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
3632 Considerations Section in RFCs", RFC 2434, October 1998.
3634 [RFC2279] F. Yergeau, "UTF-8, a transformation format of ISO
3635 10646", RFC 2279, January 1998.
3637 [EAP] L. Blunk et al., "Extensible Authentication Protocol
3638 (EAP)", draft-ietf-eap-rfc2284bis-05.txt, work-in-progress,
3641 Informative References
3643 [Draft 3GPP TS 23.234] Draft 3GPP Technical Specification 3GPP TS
3644 23.234 V 1.4.0: "Technical Specification Group Services and System
3645 Aspects; 3GPP system to Wireless Local Area Network (WLAN)
3646 Interworking; System Description", 3rd Generation Partnership
3647 Project, work in progress, January 2003.
3649 [PEAP] H. Andersson, S. Josefsson, G. Zorn, D. Simon, A. Palekar,
3650 "Protected EAP Protocol (PEAP)", draft-josefsson-pppext-eap-tls-eap-
3651 05.txt, work-in-progress, September 2002.
3653 [RFC 1750] D. Eastlake, 3rd, S. Crocker, J. Schiller, "Randomness
3654 Recommendations for Security", RFC 1750 (Informational), December
3659 Haverinen and Salowey Expires: 27 April, 2004 [Page 61]
3662 Internet Draft EAP SIM Authentication 27 October, 2003
3665 [S3-020125] Qualcomm, "Comments on draft EAP/SIM", 3rd Generation
3666 Partnership Project document 3GPP TSG SA WG3 Security S3#22, S3-
3667 020125, February 2002. (INFORMATIVE)
3669 [RFC 3344] C. Perkins (editor), "IP Mobility Support", RFC 3344,
3672 [EAP AKA] J. Arkko, H. Haverinen, "EAP AKA Authentication", draft-
3673 arkko-pppext-eap-aka-10.txt, June 2003 (work in progress).
3675 [RFC 2548] G. Zorn, "Microsoft Vendor-specific RADIUS Attributes",
3676 RFC 2548, March 1999
3678 [EAP SRP] J. Carlson, B. Aboba, H. Haverinen, "EAP SRP-SHA1
3679 Authentication Protocol", draft-ietf-pppext-eap-srp-03.txt, July
3680 2001 (work-in-progress).
3719 Haverinen and Salowey Expires: 27 April, 2004 [Page 62]
3722 Internet Draft EAP SIM Authentication 27 October, 2003
3734 Editors' and Contributors' Contact Information
3741 E-mail: henry.haverinen@nokia.com
3742 Phone: +358 50 594 4899
3749 E-mail: jsalowey@cisco.com
3750 Phone: +1 206 256 3380
3755 92447 Issy les Moulineaux France
3756 E-mail: nora.dabbous@gemplus.com
3757 Phone: +33 1 4648 2000
3761 2111 NE 25th Avenue, JF2-58
3764 E-mail: jose.p.puthenkulam@intel.com
3765 Phone: +1 503 264 6121
3767 Prasanna Satarasinghe
3768 Transat Technologies
3769 180 State Street, Suite 240
3772 E-mail: prasannas@transat-tech.com
3773 Phone: + 1 817 4814412
3779 Haverinen and Salowey Expires: 27 April, 2004 [Page 63]
3782 Internet Draft EAP SIM Authentication 27 October, 2003
3785 Annex A. Test Vectors
3787 Test vectors for the NIST FIPS 186-2 pseudo-random number generator
3788 [PRF] are available at the following URL:
3789 http://csrc.nist.gov/encryption/dss/Examples-1024bit.pdf
3791 The following examples show the contents of EAP/SIM packets on full
3792 authentication and re-authentication.
3795 A.1 EAP-Request/Identity
3797 The first packet is a plain Identity Request:
3801 00 05 ; Length: 5 octets
3804 A.2 EAP-Response/Identity
3806 The client's identity is "1244070100000001@eapsim.foo", so
3807 it responds with the following packet:
3811 00 20 ; Length: 32 octets
3813 31 32 34 34 ; "1244070100000001@eapsim.foo"
3821 A.3 EAP-Request/SIM/Start
3823 The server's first packet looks like this:
3827 00 10 ; Length: 16 octets
3829 0a ; EAP-SIM subtype: Start
3831 0f ; Attribute type: AT_VERSION_LIST
3832 02 ; Attribute length: 8 octets (2*4)
3833 00 02 ; Actual version list length: 2 octets
3835 00 00 ; (attribute padding)
3839 Haverinen and Salowey Expires: 27 April, 2004 [Page 64]
3842 Internet Draft EAP SIM Authentication 27 October, 2003
3845 A.4 EAP-Response/SIM/Start
3847 The client selects a nonce and responds with the following
3852 00 20 ; Length: 32 octets
3854 0a ; EAP-SIM subtype: Start
3856 07 ; Attribute type: AT_NONCE_MT
3857 05 ; Attribute length: 20 octets (5*4)
3859 01 23 45 67 ; NONCE_MT value
3863 10 ; Attribute type: AT_SELECTED_VERSION
3864 01 ; Attribute length: 4 octets (1*4)
3867 A.5 EAP-Request/SIM/Challenge
3869 Next, the server selects three authentication triplets
3871 (RAND1,SRES1,Kc1) = (10111213 14151617 18191a1b 1c1d1e1f,
3874 (RAND2,SRES2,Kc2) = (20212223 24252627 28292a2b 2c2d2e2f,
3877 (RAND3,SRES3,Kc3) = (30313233 34353637 38393a3b 3c3d3e3f,
3881 Next, the MK is calculated as specified in Section 4.6.
3883 MK = e576d5ca 332e9930 018bf1ba ee2763c7 95b3c712
3885 And the other keys are derived using the PRNG:
3887 K_encr = 536e5ebc 4465582a a6a8ec99 86ebb620
3888 K_aut = 25af1942 efcbf4bc 72b39434 21f2a974
3889 MSK = 39d45aea f4e30601 983e972b 6cfd46d1
3890 c3637733 65690d09 cd44976b 525f47d3
3891 a60a985e 955c53b0 90b2e4b7 3719196a
3892 40254296 8fd14a88 8f46b9a7 886e4488
3893 EMSK = 5949eab0 fff69d52 315c6c63 4fd14a7f
3894 0d52023d 56f79698 fa6596ab eed4f93f
3895 bb48eb53 4d985414 ceed0d9a 8ed33c38
3896 7c9dfdab 92ffbdf2 40fcecf6 5a2c93b9
3899 Haverinen and Salowey Expires: 27 April, 2004 [Page 65]
3902 Internet Draft EAP SIM Authentication 27 October, 2003
3905 Next, the server selects a pseudonym and a re-authentication
3906 identity (in this case,
3907 "w8w49PexCazWJ&xCIARmxuMKht5S1sxR
3908 DqXSEFBEg3DcZP9cIxTe5J4OyIwNGVzxeJOU1G" and
3909 "Y24fNSrz8BP274jOJaF17WfxI8YO7QX0
3910 0pMXk9XMMVOw7broaNhTczuFq53aEpOkk3L0dm@eapsim.foo", respectively).
3912 The following plaintext will be encrypted and stored in the
3913 AT_ENCR_DATA attribute:
3915 84 ; Attribute type: AT_NEXT_PSEUDONYM
3916 13 ; Attribute length: 76 octets (19*4)
3917 00 46 ; Actual pseudonym length: 70 octets
3918 77 38 77 34 39 50 65 78 43 61 7a 57 4a 26 78 43
3919 49 41 52 6d 78 75 4d 4b 68 74 35 53 31 73 78 52
3920 44 71 58 53 45 46 42 45 67 33 44 63 5a 50 39 63
3921 49 78 54 65 35 4a 34 4f 79 49 77 4e 47 56 7a 78
3923 00 00 ; (attribute padding)
3924 85 ; Attribute type: AT_NEXT_REAUTH_ID
3925 16 ; Attribute length: 88 octets (22*4)
3926 00 51 ; Actual re-auth identity length: 81 octets
3927 59 32 34 66 4e 53 72 7a 38 42 50 32 37 34 6a 4f
3928 4a 61 46 31 37 57 66 78 49 38 59 4f 37 51 58 30
3929 30 70 4d 58 6b 39 58 4d 4d 56 4f 77 37 62 72 6f
3930 61 4e 68 54 63 7a 75 46 71 35 33 61 45 70 4f 6b
3931 6b 33 4c 30 64 6d 40 65 61 70 73 69 6d 2e 66 6f
3933 00 00 00 ; (attribute padding)
3934 06 ; Attribute type: AT_PADDING
3935 03 ; Attribute length: 12 octets (3*4)
3940 The EAP packet looks like this:
3944 01 18 ; Length: 280 octets
3946 0b ; EAP-SIM subtype: Challenge
3948 01 ; Attribute type: AT_RAND
3949 0d ; Attribute length: 52 octets (13*4)
3951 10 11 12 13 ; first RAND
3955 20 21 22 23 ; second RAND
3959 Haverinen and Salowey Expires: 27 April, 2004 [Page 66]
3962 Internet Draft EAP SIM Authentication 27 October, 2003
3966 30 31 32 33 ; third RAND
3970 81 ; Attribute type: AT_IV
3971 05 ; Attribute length: 20 octets (5*4)
3973 9e 18 b0 c2 ; IV value
3977 82 ; Attribute type: AT_ENCR_DATA
3978 2d ; Attribute length: 180 octets (45*4)
3980 55 f2 93 9b bd b1 b1 9e a1 b4 7f c0 b3 e0 be 4c
3981 ab 2c f7 37 2d 98 e3 02 3c 6b b9 24 15 72 3d 58
3982 ba d6 6c e0 84 e1 01 b6 0f 53 58 35 4b d4 21 82
3983 78 ae a7 bf 2c ba ce 33 10 6a ed dc 62 5b 0c 1d
3984 5a a6 7a 41 73 9a e5 b5 79 50 97 3f c7 ff 83 01
3985 07 3c 6f 95 31 50 fc 30 3e a1 52 d1 e1 0a 2d 1f
3986 4f 52 26 da a1 ee 90 05 47 22 52 bd b3 b7 1d 6f
3987 0c 3a 34 90 31 6c 46 92 98 71 bd 45 cd fd bc a6
3988 11 2f 07 f8 be 71 79 90 d2 5f 6d d7 f2 b7 b3 20
3989 bf 4d 5a 99 2e 88 03 31 d7 29 94 5a ec 75 ae 5d
3990 43 c8 ed a5 fe 62 33 fc ac 49 4e e6 7a 0d 50 4d
3991 0b ; Attribute type: AT_MAC
3992 05 ; Attribute length: 20 octets (5*4)
3994 fe f3 24 ac ; MAC value
3999 The MAC is calculated over the EAP packet above (with MAC value
4000 set to zero), followed by the NONCE_MT value (a total of
4003 A.6 EAP-Response/SIM/Challenge
4005 The client's response looks like this:
4009 00 1c ; Length: 28 octets
4011 0b ; EAP-SIM subtype: Challenge
4013 0b ; Attribute type: AT_MAC
4014 05 ; Attribute length: 20 octets (5*4)
4016 f5 6d 64 33 ; MAC value
4019 Haverinen and Salowey Expires: 27 April, 2004 [Page 67]
4022 Internet Draft EAP SIM Authentication 27 October, 2003
4028 The MAC is calculated over the EAP packet above (with MAC
4029 value set to zero), followed by the SRES values (a total
4034 The last packet is an EAP Success:
4038 00 04 ; Length: 4 octets
4040 A.8 Re-authentication
4042 When performing re-authentication, the EAP-Request/Identity
4043 packet is the same as usual. The EAP-Response/Identity
4044 contains the re-authentication identity (from AT_ENCR_DATA
4049 00 56 ; Length: 86 octets
4051 59 32 34 66 4e 53 72 7a 38 42 50 32 37 34 6a 4f
4052 4a 61 46 31 37 57 66 78 49 38 59 4f 37 51 58 30
4053 30 70 4d 58 6b 39 58 4d 4d 56 4f 77 37 62 72 6f
4054 61 4e 68 54 63 7a 75 46 71 35 33 61 45 70 4f 6b
4055 6b 33 4c 30 64 6d 40 65 61 70 73 69 6d 2e 66 6f
4057 A.9 EAP-Request/SIM/Re-authentication
4059 The server recognizes the reauthentication identity, so
4060 it will respond with EAP-Request/SIM/Re-authentication.
4061 It retrieves the associated counter value, generates a nonce,
4062 and picks a new reauthentication identity (in this case,
4063 "uta0M0iyIsMwWp5TTdSdnOLvg2XDVf21OYt1vnfiMcs5dnIDHOIFVavIRzMR
4064 yzW6vFzdHW@eapsim.foo").
4066 The following plaintext will be encrypted and stored in the
4067 AT_ENCR_DATA attribute:
4069 13 ; Attribute type: AT_COUNTER
4070 01 ; Attribute length: 4 octets (1*4)
4071 00 01 ; Counter value
4072 15 ; Attribute type: AT_NONCE_S
4073 05 ; Attribute length: 20 octets (5*4)
4075 01 23 45 67 ; NONCE_S value
4079 Haverinen and Salowey Expires: 27 April, 2004 [Page 68]
4082 Internet Draft EAP SIM Authentication 27 October, 2003
4086 85 ; Attribute type: AT_NEXT_REAUTH_ID
4087 16 ; Attribute length: 88 octets (22*4)
4088 00 51 ; Actual re-auth identity length: 81 octets
4089 75 74 61 30 4d 30 69 79 49 73 4d 77 57 70 35 54
4090 54 64 53 64 6e 4f 4c 76 67 32 58 44 56 66 32 31
4091 4f 59 74 31 76 6e 66 69 4d 63 73 35 64 6e 49 44
4092 48 4f 49 46 56 61 76 49 52 7a 4d 52 79 7a 57 36
4093 76 46 7a 64 48 57 40 65 61 70 73 69 6d 2e 66 6f
4095 00 00 00 ; (attribute padding)
4096 06 ; Attribute type: AT_PADDING
4097 04 ; Attribute length: 16 octets (4*4)
4103 The EAP packet looks like this:
4107 00 b4 ; Length: 180 octets
4109 0d ; EAP-SIM subtype: Re-authentication
4111 81 ; Attribute type: AT_IV
4112 05 ; Attribute length: 20 octets (5*4)
4114 d5 85 ac 77 ; IV value
4118 82 ; Attribute type: AT_ENCR_DATA
4119 21 ; Attribute length: 132 octets (33*4)
4121 68 62 91 a9 d2 ab c5 8c aa 32 94 b6 e8 5b 44 84
4122 6c 44 e5 dc b2 de 8b 9e 80 d6 9d 49 85 8a 5d b8
4123 4c dc 1c 9b c9 5c 01 b9 6b 6e ca 31 34 74 ae a6
4124 d3 14 16 e1 9d aa 9d f7 0f 05 00 88 41 ca 80 14
4125 96 4d 3b 30 a4 9b cf 43 e4 d3 f1 8e 86 29 5a 4a
4126 2b 38 d9 6c 97 05 c2 bb b0 5c 4a ac e9 7d 5e af
4127 f5 64 04 6c 8b d3 0b c3 9b e5 e1 7a ce 2b 10 a6
4128 fe b9 98 e6 c5 35 3f ea ab 59 a7 4c 84 60 45 9f
4129 0b ; Attribute type: AT_MAC
4130 05 ; Attribute length: 20 octets (5*4)
4132 39 73 65 a3 ; MAC value
4137 The MAC is calculated over the EAP packet above (with MAC value
4139 Haverinen and Salowey Expires: 27 April, 2004 [Page 69]
4142 Internet Draft EAP SIM Authentication 27 October, 2003
4145 set to zero; a total of 180 bytes).
4147 Finally, the server derives new keys. The XKEY'
4148 is calculated as described in Section 17:
4150 XKEY' = 863dc120 32e08343 c1a2308d b48377f6 801f58d4
4152 The new MSK and EMSK are derived using the PRNG (note that
4153 K_encr and K_aut stay the same).
4155 MSK = 756d9e4c ed6d5ed6 40eb3fe3 8565ca07
4156 6e7fb8a8 17cfe8d9 adbce441 d47c4f5e
4157 3d8ff786 3a630b2b 06e2cf20 9684c13f
4158 6b82f992 f2b06f1b 54bf51ef 237f2a40
4159 EMSK = 1ef5e0d7 e098a34c 533eaebf 34578854
4160 b7721526 20a777f0 e0340884 a294fb73
4161 af7102ff cd27f692 fd672be9 a55f0cd1
4162 2a4a5106 78fff62a b4c76023 6ff0163d
4164 A.10 EAP-Response/SIM/Re-authentication
4166 The client's response includes the counter as well. The following
4167 plaintext will be encrypted and stored in the AT_ENCR_DATA
4170 13 ; Attribute type: AT_COUNTER
4171 01 ; Attribute length: 4 octets (1*4)
4172 00 01 ; Counter value
4173 06 ; Attribute type: AT_PADDING
4174 03 ; Attribute length: 12 octets (3*4)
4179 The EAP packet looks like this:
4183 00 44 ; Length: 68 octets
4185 0d ; EAP-SIM subtype: Re-authentication
4187 81 ; Attribute type: AT_IV
4188 05 ; Attribute length: 20 octets (5*4)
4190 cd f7 ff a6 ; IV value
4194 82 ; Attribute type: AT_ENCR_DATA
4195 05 ; Attribute length: 20 octets (5*4)
4199 Haverinen and Salowey Expires: 27 April, 2004 [Page 70]
4202 Internet Draft EAP SIM Authentication 27 October, 2003
4208 0b ; Attribute type: AT_MAC
4209 05 ; Attribute length: 20 octets (5*4)
4211 fa f7 6b 71 ; MAC value
4216 The MAC is calculated over the EAP packet above (with MAC value
4217 set to zero), followed by the NONCE_S value (a total of
4220 The next packet will be EAP Success, same as above.
4259 Haverinen and Salowey Expires: 27 April, 2004 [Page 71]
4262 Internet Draft EAP SIM Authentication 27 October, 2003
4265 Annex B. Pseudo-Random Number Generator
4267 The "|" character denotes concatenation, and "^" denotes involution.
4269 Step 1: Choose a new, secret value for the seed-key, XKEY
4271 Step 2: In hexadecimal notation let
4272 t = 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0
4273 This is the initial value for H0|H1|H2|H3|H4
4274 in the FIPS SHS [SHA-1]
4276 Step 3: For j = 0 to m - 1 do
4277 3.1 XSEED_j = 0 /* no optional user input */
4278 3.2 For i = 0 to 1 do
4279 a. XVAL = (XKEY + XSEED_j) mod 2^b
4281 c. XKEY = (1 + XKEY + w_i) mod 2^b
4319 Haverinen and Salowey Expires: 27 April, 2004 [Page 72]
projects / freeradius.git / blob