1

2
3 TSG-S WG4
4
5
6 Title: Comments on Generic Key Exchange Protocol
7
8 Source:
Sarvar Patel Simon Mizikovsky
Lucent Lucent
technologies technologies
9
10
11
12 Abstract: This contribution contains comments on Generic Key Exchange Protocol
13 described in Qualcomm contributions C25-20050314-050-R1 and C25-
14 20050418-025R1.
15
16 Recommendation: For discussion.
17
18
19
20
21
22
23
24
25
26

Lucent Technologies grants a free, irrevocable license to 3GPP2 and its Organizational Partners to
incorporate text or other copyrightable material contained in the contribution and any modifications
thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner's name
any Organizational Partner's standards publication even though it may include all or portions of this
contribution; and at the Organizational Partner's sole discretion to permit others to reproduce in
whole or in part such contribution or the resulting Organizational Partner's standards publication.
Lucent Technologies is also willing to grant licenses under such contributor copyrights to third
parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an
Organizational Partner’s standard which incorporates this contribution.

This document has been prepared by Lucent Technologies to assist the development of specifications
by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a
binding proposal on Lucent Technologies. Lucent Technologies specifically reserves the right to
amend or modify the material contained herein and to any intellectual property of Lucent
Technologies other than provided in the copyright statement above.

1
 1

2 1 INTRODUCTION
3 In contribution C25-20050514-050R1 Qualcomm proposed the mutually authenticated
4 key exchange mechanism between the 1xEV-DO access terminal and access network
5 based on symmetric key PMK. We analyzed the proposal and came up with several
6 recommendations to improve the security while maintaining efficiency of the protocol.

7 2 COMMENTS AND RECOMMENDATIONS

8 2.1 Format of Nonces

9
10 Qualcomm proposes to generate an initial (starting) Nonces at AT and AN sites as
11 follows:
12 ANNonse = PRF(Random number, “Init_Counter”, BSC’s MAC address | Time, 256)
13 and
14 ATNonce = PRF(Random number, “Init_Counter”, HardwareID | Time, 256),
15 and then subsequently increment them for each key generation transaction while
16 exchanging the values of last nonces.
17 Comment on initial nonce: Theoretically, both ANNonce and ATNonce could be
18 directly a 128 bit random numbers, rather than being created through an indirect way of
19 PRF(rand, time, etc) assuming there is a good random number generator or a
20 cryptographically strong random number generator like f0 specified in the ECA. The
21 output of a PRF is supposed to be indistinguishable from a random number, so RAND or
22 PRF(RAND) should be equivalent. Secondly, an implementation of a random number
23 should make sure that numbers are not repeated (except with a negligibly small
24 probability) and not rely on CDMA time for this purpose since a false base station can
25 fake time. Thus we propose that initial nonces for both ATNonce and ANNonce be 128
26 bit random numbers.
27 Comment on subsequent nonces: The idea of incrementing Nonces after their
28 initialization is useful in minimizing invocations to random number generation which
29 may be particularly important on the AT side due to limited access to randomness. This is
30 less needed on the AN side where more resources are available. However, incrementing
31 ANNonce at the AN side can introduce vulnerability as described next.
32 The Generic Key Exchange protocol goal is to provide both an entity authentication
33 and a session key agreement protocol, however, we will show that the security of
34 entity authentication is violated when incrementing nonces are used on both sides.
35 It should not be possible for an attacker to fool the network into thinking that the key
36 exchange was successfully completed without access to the PMK. Even if the attacker
37 is not able to get a session key, the network should not be so fooled. An attacker can
38 predict the future values of ANNonce and use it to pre-query responses from the AT
39 and then, at the future time, use it to complete a later key exchange started by the
40 network. The steps of the attack include:

2
 1 a. Assume that the current values of ATNonce=100 and ANNonce=900. The
2 attacker queries the AT by sending a key request message with ANNonce
3 set to 950, a future value. The AT not being any wiser, creates its own
4 ATNonce=101 and sends a key response message including the message
5 integrity code. The attacker remembers the key response message,
6 including the ATNonce, and the message integrity code, etc.
7 b. The attacker lets the AT and the AN perform many session key
8 agreements, and lets the ANNonce incremented till ANNonce=949 has
9 been used up by the network.
10 c. At this point when the network will be using ANNonce=950, the attacker
11 pretends to be the AT and responds to the key request message sent by the
12 AN which includes ANNonce=950. The key response send by the attacker
13 is just a repeat of the key response stored in step (a) above. The AN will
14 receive the response, and successfully verify the message integrity code
15 and accept the protocol as successfully completed.
16 Thus the attacker has successfully fooled the AN by simply replaying some very old
17 query made to the AT. Thus freshness is not guaranteed by this protocol.
18 Requiring only that the ANNonce always be a random number solves the above
19 problem because the attacker does not know what ANNonce to use in pre-querying
20 step of the attack. The ATNonce can continue to be incremented as described in
21 the protocol.
22 To summarize, the ANNonce should always be a random value and not be
23 incremented, while the ATNonce can be a counter.

24 2.2 Format and use of MIC Key.

25
26 The MIC key is used only to authenticate the messages in the key exchange. Instead
27 of deriving a new MIC key every time, a more efficient method would be this: First
28 expand PMK into two keys:
29 PMKA = PRF(PMK, “A”) and
30 PMKB=PRF(PMK, “B”).
31 The key PMKA would be used instead of MIC key in the Generic Key Exchange
32 protocol for authenticating the protocol messages.
33 The key PMKB would be used to generate the Session Keys instead of the PMK as
34 described in the Generic Key Exchange protocol.
35 This should be more efficient, however, this is not to argue that the existing method is
36 insecure.

37 2.3 Format and applicability of TRANSACTION_ID.

38 Qualcomm Proposal defines that “… The access terminal keeps track of the last value of
39 the TransactionID that was sent from the access network. The access terminal discards
40 the KeyRequest message if the TransactionID field of the KeyRequest message is smaller

3
 1 than that received in the last valid ANKeyResponse message…”, thus implicitly requiring
2 the Access Network to maintain the synchronicity of the TransactionID field with that
3 expected by the Access Terminal.
4 The replay protection property expected from this mechanism will already be achieved if
5 the ANNonce is a random number while the ATNonce is either random number or a
6 counter. Hence maintaining the TransactionID synchronicity becomes unnecessary.
7 We recommend to clarify that TransactionID should be unique throughout the
8 Generic Key Exchange transaction until its successful completion. The Access
9 Network should avoid selecting the value of TransactionID which conflicts with
10 other currently active Generic Key Exchange transaction.

11 2.4 Generation of PairwiseMasterKeyID

12 It is unclear what is the SessionSeed on Pg.3 ln.14.
13 It is also unclear why the PairwiseMasterKeyID can not just be a 128-bit random
14 number that the Access Network associates with the PMK at the PMK creation
15 time.
16 Alternatively, if there was a need for implicit association, then, similarly to subsection
17 2.2, both Access Network and Access Terminal could create the PairwiseMasterKeyID
18 from the PMK itself as PairwiseMasterKeyID = PRF(PMK,”PairwiseMasterKeyID”).
19 Thus SessionSeed does not have to be communicated from the Access network to the
20 Access terminal.

21 2.5 Computation of the Session Keys

22 The use of SessioSeed on Pg.5 ln.20 is not only unexplained, but also unnecessary due to
23 the use of both Nonces. In fact, the protocol does not show how this SessionSeed is
24 communicated between Access Network and Access terminal. We suggest to remove the
25 SessionSeed from computation of the Session Key.

26 2.6 Computation of the MIC

27 On Pg.4 ln.14-17 Qualcomm proposes that the MIC is computed on the entire message,
28 while the 80-bits MIC field of this message is replaced with 80 zeros for MIC
29 computation. Why not just specify that MIC is computed on entire message excluding
30 the MIC field itself?

31 2.7 Construction of PRF

32 The document a construction of a PRF which uses the HMAC-SHA-1-xx as the core. It is
33 not clear what the construction is from its description in sec. 2.1.6.1.4 of the contribution
34 C25-20050418-025R1. Nevertheless, we suggest that existing 3GPP2 standard
35 cryptographic functions shall be used wherever possible, in particular, we believe, the f3
36 can be used as the PRF to create the Session Keys, and EHMAC can be used to create the
37 MIC.

4
1 3 CONCLUSION
2 In general, we agree that mutually authenticated session key agreement protocol based on
3 symmetric keys is beneficial for evolution of 1xEV-DO. We also agree that protocol
4 proposed by Qualcomm is the good one, subject to modifications proposed by this
5 contribution.