RFC 4186
Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)
15. References
15.1. Normative References
[GSM-03.20] European Telecommunications Standards Institute, "GSM Technical Specification GSM 03.20 (ETS 300 534): "Digital cellular telecommunication system (Phase 2); Security related network functions"", August 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [GSM-03.03] European Telecommunications Standards Institute, "GSM Technical Specification GSM 03.03 (ETS 300 523): "Digital cellular telecommunication system (Phase 2); Numbering, addressing and identification"", April 1997. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. [AES] National Institute of Standards and Technology, "Federal Information Processing Standards (FIPS) Publication 197, "Advanced Encryption Standard (AES)"", November 2001. http://csrc.nist.gov/publications/fips/fips197/ fips-197.pdf [CBC] National Institute of Standards and Technology, "NIST Special Publication 800-38A, "Recommendation for Block Cipher Modes of Operation - Methods and Techniques"", December 2001. http://csrc.nist.gov/publications/nistpubs/ 800-38a/sp800-38a.pdf [SHA-1] National Institute of Standards and Technology, U.S. Department of Commerce, "Federal Information Processing Standard (FIPS) Publication 180-1, "Secure Hash Standard"", April 1995.
[PRF] National Institute of Standards and Technology, "Federal Information Processing Standards (FIPS) Publication 186-2 (with change notice); Digital Signature Standard (DSS)", January 2000. Available on-line at: http://csrc.nist.gov/publications/ fips/fips186-2/fips186-2-change1.pdf [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [EAP-AKA] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006.15.2. Informative References
[3GPP-TS-23.003] 3rd Generation Partnership Project, "3GPP Technical Specification 3GPP TS 23.003 V6.8.0: "3rd Generation Parnership Project; Technical Specification Group Core Network; Numbering, addressing and identification (Release 6)"", December 2005. [3GPP-TS-55.205] 3rd Generation Partnership Project, "3GPP Technical Specification 3GPP TS 55.205 V 6.0.0: "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Specification of the GSM-MILENAGE Algorithms: An example algorithm set for the GSM Authentication and Key Generation functions A3 and A8 (Release 6)"", December 2002. [PEAP] Palekar, A., Simon, D., Zorn, G., Salowey, J., Zhou, H., and S. Josefsson, "Protected EAP Protocol (PEAP) Version 2", Work in Progress, October 2004. [PEAP-02] Anderson, H., Josefsson, S., Zorn, G., Simon, D., and A. Palekar, "Protected EAP Protocol (PEAP)", Work in Progress, February 2002.
[EAP-Keying] Aboba, B., Simon, D., Arkko, J., Eronen, P., and H. Levkowetz, "Extensible Authentication Protocol (EAP) Key Management Framework", Work in Progress, October 2005. [Service-Identity] Arkko, J. and P. Eronen, "Authenticated Service Information for the Extensible Authentication Protocol (EAP)", Work in Progress, October 2004. [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [S3-020125] Qualcomm, "Comments on draft EAP/SIM, 3rd Generation Partnership Project document 3GPP TSG SA WG3 Security S3#22, S3-020125", February 2002. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes ", RFC 2548, March 1999. [EAP-SRP] Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-SHA1 Authentication Protocol", Work in Progress, July 2001. [GSM-Cloning] Wagner, D., "GSM Cloning". Web page about COMP-128 version 1 vulnerabilities, available at http://www.isaac.cs.berkeley.edu/isaac/gsm.html [Barkan-2003] Barkan, E., Biham, E., and N. Keller, "Instant Ciphertext-Only Cryptanalysis of GSM Encrypted Communications". available on-line at http://cryptome.org/gsm-crack-bbk.pdf [Patel-2003] Patel, S., "Analysis of EAP-SIM Session Key Agreement". Posted to the EAP mailing list 29 May,2003. http:// mail.frascone.com/pipermail/public/eap/2003-May/ 001267.html
Appendix A. Test Vectors
Test vectors for the NIST FIPS 186-2 pseudo-random number generator [PRF] are available at the following URL: http://csrc.nist.gov/encryption/dss/Examples-1024bit.pdf The following examples show the contents of EAP-SIM packets on full authentication and fast re-authentication.A.1. EAP-Request/Identity
The first packet is a plain Identity Request: 01 ; Code: Request 00 ; Identifier: 0 00 05 ; Length: 5 octets 01 ; Type: IdentityA.2. EAP-Response/Identity
The client's identity is "1244070100000001@eapsim.foo", so it responds with the following packet: 02 ; Code: Response 00 ; Identifier: 0 00 20 ; Length: 32 octets 01 ; Type: Identity 31 32 34 34 ; "1244070100000001@eapsim.foo" 30 37 30 31 30 30 30 30 30 30 30 31 40 65 61 70 73 69 6d 2e 66 6f 6f
A.3. EAP-Request/SIM/Start
The server's first packet looks like this: 01 ; Code: Request 01 ; Identifier: 1 00 10 ; Length: 16 octets 12 ; Type: EAP-SIM 0a ; EAP-SIM subtype: Start 00 00 ; (reserved) 0f ; Attribute type: AT_VERSION_LIST 02 ; Attribute length: 8 octets (2*4) 00 02 ; Actual version list length: 2 octets 00 01 ; Version: 1 00 00 ; (attribute padding)A.4. EAP-Response/SIM/Start
The client selects a nonce and responds with the following packet: 02 ; Code: Response 01 ; Identifier: 1 00 20 ; Length: 32 octets 12 ; Type: EAP-SIM 0a ; EAP-SIM subtype: Start 00 00 ; (reserved) 07 ; Attribute type: AT_NONCE_MT 05 ; Attribute length: 20 octets (5*4) 00 00 ; (reserved) 01 23 45 67 ; NONCE_MT value 89 ab cd ef fe dc ba 98 76 54 32 10 10 ; Attribute type: AT_SELECTED_VERSION 01 ; Attribute length: 4 octets (1*4) 00 01 ; Version: 1
A.5. EAP-Request/SIM/Challenge
Next, the server selects three authentication triplets (RAND1,SRES1,Kc1) = (10111213 14151617 18191a1b 1c1d1e1f, d1d2d3d4, a0a1a2a3 a4a5a6a7) (RAND2,SRES2,Kc2) = (20212223 24252627 28292a2b 2c2d2e2f, e1e2e3e4, b0b1b2b3 b4b5b6b7) (RAND3,SRES3,Kc3) = (30313233 34353637 38393a3b 3c3d3e3f, f1f2f3f4, c0c1c2c3 c4c5c6c7) Next, the MK is calculated as specified in Section 7*. MK = e576d5ca 332e9930 018bf1ba ee2763c7 95b3c712 And the other keys are derived using the PRNG: K_encr = 536e5ebc 4465582a a6a8ec99 86ebb620 K_aut = 25af1942 efcbf4bc 72b39434 21f2a974 MSK = 39d45aea f4e30601 983e972b 6cfd46d1 c3637733 65690d09 cd44976b 525f47d3 a60a985e 955c53b0 90b2e4b7 3719196a 40254296 8fd14a88 8f46b9a7 886e4488 EMSK = 5949eab0 fff69d52 315c6c63 4fd14a7f 0d52023d 56f79698 fa6596ab eed4f93f bb48eb53 4d985414 ceed0d9a 8ed33c38 7c9dfdab 92ffbdf2 40fcecf6 5a2c93b9 Next, the server selects a pseudonym and a fast re-authentication identity (in this case, "w8w49PexCazWJ&xCIARmxuMKht5S1sxR DqXSEFBEg3DcZP9cIxTe5J4OyIwNGVzxeJOU1G" and "Y24fNSrz8BP274jOJaF17WfxI8YO7QX0 0pMXk9XMMVOw7broaNhTczuFq53aEpOkk3L0dm@eapsim.foo", respectively).
The following plaintext will be encrypted and stored in the
AT_ENCR_DATA attribute:
84 ; Attribute type: AT_NEXT_PSEUDONYM
13 ; Attribute length: 76 octets (19*4)
00 46 ; Actual pseudonym length: 70 octets
77 38 77 34 39 50 65 78 43 61 7a 57 4a 26 78 43
49 41 52 6d 78 75 4d 4b 68 74 35 53 31 73 78 52
44 71 58 53 45 46 42 45 67 33 44 63 5a 50 39 63
49 78 54 65 35 4a 34 4f 79 49 77 4e 47 56 7a 78
65 4a 4f 55 31 47
00 00 ; (attribute padding)
85 ; Attribute type: AT_NEXT_REAUTH_ID
16 ; Attribute length: 88 octets (22*4)
00 51 ; Actual re-auth identity length: 81 octets
59 32 34 66 4e 53 72 7a 38 42 50 32 37 34 6a 4f
4a 61 46 31 37 57 66 78 49 38 59 4f 37 51 58 30
30 70 4d 58 6b 39 58 4d 4d 56 4f 77 37 62 72 6f
61 4e 68 54 63 7a 75 46 71 35 33 61 45 70 4f 6b
6b 33 4c 30 64 6d 40 65 61 70 73 69 6d 2e 66 6f
6f
00 00 00 ; (attribute padding)
06 ; Attribute type: AT_PADDING
03 ; Attribute length: 12 octets (3*4)
00 00 00 00
00 00 00 00
00 00
The EAP packet looks like this:
01 ; Code: Request
02 ; Identifier: 2
01 18 ; Length: 280 octets
12 ; Type: EAP-SIM
0b ; EAP-SIM subtype: Challenge
00 00 ; (reserved)
01 ; Attribute type: AT_RAND
0d ; Attribute length: 52 octets (13*4)
00 00 ; (reserved)
10 11 12 13 ; first RAND
14 15 16 17
18 19 1a 1b
1c 1d 1e 1f
20 21 22 23 ; second RAND
24 25 26 27
28 29 2a 2b
2c 2d 2e 2f
30 31 32 33 ; third RAND
34 35 36 37
38 39 3a 3b
3c 3d 3e 3f
81 ; Attribute type: AT_IV
05 ; Attribute length: 20 octets (5*4)
00 00 ; (reserved)
9e 18 b0 c2 ; IV value
9a 65 22 63
c0 6e fb 54
dd 00 a8 95
82 ; Attribute type: AT_ENCR_DATA
2d ; Attribute length: 180 octets (45*4)
00 00 ; (reserved)
55 f2 93 9b bd b1 b1 9e a1 b4 7f c0 b3 e0 be 4c
ab 2c f7 37 2d 98 e3 02 3c 6b b9 24 15 72 3d 58
ba d6 6c e0 84 e1 01 b6 0f 53 58 35 4b d4 21 82
78 ae a7 bf 2c ba ce 33 10 6a ed dc 62 5b 0c 1d
5a a6 7a 41 73 9a e5 b5 79 50 97 3f c7 ff 83 01
07 3c 6f 95 31 50 fc 30 3e a1 52 d1 e1 0a 2d 1f
4f 52 26 da a1 ee 90 05 47 22 52 bd b3 b7 1d 6f
0c 3a 34 90 31 6c 46 92 98 71 bd 45 cd fd bc a6
11 2f 07 f8 be 71 79 90 d2 5f 6d d7 f2 b7 b3 20
bf 4d 5a 99 2e 88 03 31 d7 29 94 5a ec 75 ae 5d
43 c8 ed a5 fe 62 33 fc ac 49 4e e6 7a 0d 50 4d
0b ; Attribute type: AT_MAC
05 ; Attribute length: 20 octets (5*4)
00 00 ; (reserved)
fe f3 24 ac ; MAC value
39 62 b5 9f
3b d7 82 53
ae 4d cb 6a
The MAC is calculated over the EAP packet above (with MAC value set
to zero), followed by the NONCE_MT value (a total of 296 bytes).
A.6. EAP-Response/SIM/Challenge
The client's response looks like this: 02 ; Code: Response 02 ; Identifier: 2 00 1c ; Length: 28 octets 12 ; Type: EAP-SIM 0b ; EAP-SIM subtype: Challenge 00 00 ; (reserved) 0b ; Attribute type: AT_MAC 05 ; Attribute length: 20 octets (5*4) 00 00 ; (reserved) f5 6d 64 33 ; MAC value e6 8e d2 97 6a c1 19 37 fc 3d 11 54 The MAC is calculated over the EAP packet above (with MAC value set to zero), followed by the SRES values (a total of 40 bytes).A.7. EAP-Success
The last packet is an EAP-Success: 03 ; Code: Success 02 ; Identifier: 2 00 04 ; Length: 4 octetsA.8. Fast Re-authentication
When performing fast re-authentication, the EAP-Request/Identity packet is the same as usual. The EAP-Response/Identity contains the fast re-authentication identity (from AT_ENCR_DATA attribute above): 02 ; Code: Response 00 ; Identifier: 0 00 56 ; Length: 86 octets 01 ; Type: Identity 59 32 34 66 4e 53 72 7a 38 42 50 32 37 34 6a 4f 4a 61 46 31 37 57 66 78 49 38 59 4f 37 51 58 30 30 70 4d 58 6b 39 58 4d 4d 56 4f 77 37 62 72 6f 61 4e 68 54 63 7a 75 46 71 35 33 61 45 70 4f 6b 6b 33 4c 30 64 6d 40 65 61 70 73 69 6d 2e 66 6f 6f
A.9. EAP-Request/SIM/Re-authentication
The server recognizes the reauthentication identity, so it will respond with EAP-Request/SIM/Re-authentication. It retrieves the associated counter value, generates a nonce, and picks a new reauthentication identity (in this case, "uta0M0iyIsMwWp5TTdSdnOLvg2XDVf21OYt1vnfiMcs5dnIDHOIFVavIRzMR yzW6vFzdHW@eapsim.foo"). The following plaintext will be encrypted and stored in the AT_ENCR_DATA attribute. Note that AT_PADDING is not used because the length of the plaintext is a multiple of 16 bytes. 13 ; Attribute type: AT_COUNTER 01 ; Attribute length: 4 octets (1*4) 00 01 ; Counter value 15 ; Attribute type: AT_NONCE_S 05 ; Attribute length: 20 octets (5*4) 00 00 ; (reserved) 01 23 45 67 ; NONCE_S value 89 ab cd ef fe dc ba 98 76 54 32 10 85 ; Attribute type: AT_NEXT_REAUTH_ID 16 ; Attribute length: 88 octets (22*4) 00 51 ; Actual re-auth identity length: 81 octets 75 74 61 30 4d 30 69 79 49 73 4d 77 57 70 35 54 54 64 53 64 6e 4f 4c 76 67 32 58 44 56 66 32 31 4f 59 74 31 76 6e 66 69 4d 63 73 35 64 6e 49 44 48 4f 49 46 56 61 76 49 52 7a 4d 52 79 7a 57 36 76 46 7a 64 48 57 40 65 61 70 73 69 6d 2e 66 6f 6f 00 00 00 ; (attribute padding)
The EAP packet looks like this:
01 ; Code: Request
01 ; Identifier: 1
00 a4 ; Length: 164 octets
12 ; Type: EAP-SIM
0d ; EAP-SIM subtype: Re-authentication
00 00 ; (reserved)
81 ; Attribute type: AT_IV
05 ; Attribute length: 20 octets (5*4)
00 00 ; (reserved)
d5 85 ac 77 ; IV value
86 b9 03 36
65 7c 77 b4
65 75 b9 c4
82 ; Attribute type: AT_ENCR_DATA
1d ; Attribute length: 116 octets (29*4)
00 00 ; (reserved)
68 62 91 a9 d2 ab c5 8c aa 32 94 b6 e8 5b 44 84
6c 44 e5 dc b2 de 8b 9e 80 d6 9d 49 85 8a 5d b8
4c dc 1c 9b c9 5c 01 b9 6b 6e ca 31 34 74 ae a6
d3 14 16 e1 9d aa 9d f7 0f 05 00 88 41 ca 80 14
96 4d 3b 30 a4 9b cf 43 e4 d3 f1 8e 86 29 5a 4a
2b 38 d9 6c 97 05 c2 bb b0 5c 4a ac e9 7d 5e af
f5 64 04 6c 8b d3 0b c3 9b e5 e1 7a ce 2b 10 a6
0b ; Attribute type: AT_MAC
05 ; Attribute length: 20 octets (5*4)
00 00 ; (reserved)
48 3a 17 99 ; MAC value
b8 3d 7c d3
d0 a1 e4 01
d9 ee 47 70
The MAC is calculated over the EAP packet above (with MAC value set
to zero; a total of 164 bytes).
Finally, the server derives new keys. The XKEY' is calculated as
described in Section 7*:
XKEY' = 863dc120 32e08343 c1a2308d b48377f6 801f58d4
The new MSK and EMSK are derived using the PRNG (note that K_encr and
K_aut stay the same).
MSK = 6263f614 973895e1 335f7e30 cff028ee
2176f519 002c9abe 732fe0ef 00cf167c
756d9e4c ed6d5ed6 40eb3fe3 8565ca07
6e7fb8a8 17cfe8d9 adbce441 d47c4f5e
EMSK = 3d8ff786 3a630b2b 06e2cf20 9684c13f
6b82f992 f2b06f1b 54bf51ef 237f2a40
1ef5e0d7 e098a34c 533eaebf 34578854
b7721526 20a777f0 e0340884 a294fb73
A.10. EAP-Response/SIM/Re-authentication
The client's response includes the counter as well. The following
plaintext will be encrypted and stored in the AT_ENCR_DATA attribute:
13 ; Attribute type: AT_COUNTER
01 ; Attribute length: 4 octets (1*4)
00 01 ; Counter value
06 ; Attribute type: AT_PADDING
03 ; Attribute length: 12 octets (3*4)
00 00 00 00
00 00 00 00
00 00
The EAP packet looks like this:
02 ; Code: Response
01 ; Identifier: 1
00 44 ; Length: 68 octets
12 ; Type: EAP-SIM
0d ; EAP-SIM subtype: Re-authentication
00 00 ; (reserved)
81 ; Attribute type: AT_IV
05 ; Attribute length: 20 octets (5*4)
00 00 ; (reserved)
cd f7 ff a6 ; IV value
5d e0 4c 02
6b 56 c8 6b
76 b1 02 ea
82 ; Attribute type: AT_ENCR_DATA
05 ; Attribute length: 20 octets (5*4)
00 00 ; (reserved)
b6 ed d3 82
79 e2 a1 42
3c 1a fc 5c
45 5c 7d 56
0b ; Attribute type: AT_MAC
05 ; Attribute length: 20 octets (5*4)
00 00 ; (reserved)
fa f7 6b 71 ; MAC value
fb e2 d2 55
b9 6a 35 66
c9 15 c6 17
The MAC is calculated over the EAP packet above (with MAC value set
to zero), followed by the NONCE_S value (a total of 84 bytes).
The next packet will be EAP-Success:
03 ; Code: Success
01 ; Identifier: 1
00 04 ; Length: 4 octets
Appendix B. Pseudo-Random Number Generator
The "|" character denotes concatenation, and "^" denotes
exponentiation.
Step 1: Choose a new, secret value for the seed-key, XKEY
Step 2: In hexadecimal notation let
t = 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0
This is the initial value for H0|H1|H2|H3|H4
in the FIPS SHS [SHA-1]
Step 3: For j = 0 to m - 1 do
3.1 XSEED_j = 0 /* no optional user input */
3.2 For i = 0 to 1 do
a. XVAL = (XKEY + XSEED_j) mod 2^b
b. w_i = G(t, XVAL)
c. XKEY = (1 + XKEY + w_i) mod 2^b
3.3 x_j = w_0|w_1
Authors' Addresses
Henry Haverinen (editor) Nokia Enterprise Solutions P.O. Box 12 FIN-40101 Jyvaskyla Finland EMail: henry.haverinen@nokia.com Joseph Salowey (editor) Cisco Systems 2901 Third Avenue Seattle, WA 98121 USA Phone: +1 206 256 3380 EMail: jsalowey@cisco.com
Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).