key strength may be reduced considerably, basically to the same level
as in GSM, by mounting attacks over GSM/GPRS. For example an active
attack using a false GSM/GPRS base station reduces the effective key
strength to almost zero.
Description of key hierarchy: Please see Section 7.
Dictionary attack protection: N/A (Section 12.7)
Fast reconnect: Yes
Cryptographic binding: N/A
Session independence: Yes (Section 12.6)
Fragmentation: No
Channel binding: No
Indication of vulnerabilities: Vulnerabilities are discussed in
Section 12.
14. Acknowledgements and Contributions
14.1. Contributors
In addition to the editors, Nora Dabbous, Jose Puthenkulam, and
Prasanna Satarasinghe were significant contributors to this document.
Pasi Eronen and Jukka-Pekka Honkanen contributed Appendix A.
14.2. Acknowledgements
Juha Ala-Laurila, N. Asokan, Jan-Erik Ekberg, Patrik Flykt,
Jukka-Pekka Honkanen, Antti Kuikka, Jukka Latva, Lassi Lehtinen, Jyri
Rinnemaa, Timo Takamaki, and Raimo Vuonnala contributed many original
ideas and concepts to this protocol.
N. Asokan, Pasi Eronen, and Jukka-Pekka Honkanen contributed and
helped in innumerable ways during the development of the protocol.
Valtteri Niemi and Kaisa Nyberg contributed substantially to the
design of the key derivation and the fast re-authentication
procedure, and have also provided their cryptographic expertise in
many discussions related to this protocol.
Simon Blake-Wilson provided very helpful comments on key derivation
and version negotiation.
Thanks to Greg Rose for his very valuable comments to an early
version of this specification [S3-020125], and for reviewing and
providing very useful comments on version 12.
Thanks to Bernard Aboba, Vladimir Alperovich, Florent Bersani,
Jacques Caron, Gopal Dommety, Augustin Farrugia, Mark Grayson, Max de
Groot, Prakash Iyer, Nishi Kant, Victor Lortz, Jouni Malinen, Sarvar
Patel, Tom Porcher, Michael Richardson, Stefan Schroeder, Uma
Shankar, Jesse Walker, and Thomas Wieland for their contributions and
critiques. Special thanks to Max for proposing improvements to the
MAC calculation.
Thanks to Glen Zorn for reviewing this document and for providing
very useful comments on the protocol.
Thanks to Sarvar Patel for his review of the protocol [Patel-2003].
Thanks to Bernard Aboba for reviewing this document for RFC 3748
compliance.
The identity privacy support is based on the identity privacy support
of [EAP-SRP]. The attribute format is based on the extension format
of Mobile IPv4 [RFC3344].
This protocol has been partly developed in parallel with EAP-AKA
[EAP-AKA], and hence this specification incorporates many ideas from
Jari Arkko.
14.2.1. Contributors’ Addresses
Nora Dabbous
Gemplus
34 rue Guynemer
92447 Issy les Moulineaux
France
Phone: +33 1 4648 2000
EMail: nora.dabbous@gemplus.com
Jose Puthenkulam
Intel Corporation
2111 NE 25th Avenue, JF2-58
Hillsboro, OR 97124
USA
Phone: +1 503 264 6121
EMail: jose.p.puthenkulam@intel.com
Prasanna Satarasinghe
Transat Technologies
180 State Street, Suite 240
Southlake, TX 76092
USA
Phone: + 1 817 4814412
EMail: prasannas@transat-tech.com
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: Identity
A.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