1 2 3 4 5 6 7 8

This contribution contains comments on Generic Key Exchange Protocol described in Qualcomm contributions C25-20050314-050-R1 and C2520050418-025R1. For discussion.

Recommendation:

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

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

Assume that the current values of ATNonce=100 and ANNonce=900. At this point when the network will be using ANNonce=950. while the ATNonce can be a counter. however. The ATNonce can continue to be incremented as described in the protocol. “B”). To summarize. this is not to argue that the existing method is insecure. Thus the attacker has successfully fooled the AN by simply replaying some very old query made to the AT. Instead of deriving a new MIC key every time. and lets the ANNonce incremented till ANNonce=949 has been used up by the network. the attacker pretends to be the AT and responds to the key request message sent by the AN which includes ANNonce=950. and successfully verify the message integrity code and accept the protocol as successfully completed.
The MIC key is used only to authenticate the messages in the key exchange. The attacker queries the AT by sending a key request message with ANNonce set to 950. b. etc.
Format and applicability of TRANSACTION_ID. The key response send by the attacker is just a repeat of the key response stored in step (a) above. “A”) and PMKB=PRF(PMK.
Qualcomm Proposal defines that “… The access terminal keeps track of the last value of the TransactionID that was sent from the access network. The AT not being any wiser. The AN will receive the response. Requiring only that the ANNonce always be a random number solves the above problem because the attacker does not know what ANNonce to use in pre-querying step of the attack. creates its own ATNonce=101 and sends a key response message including the message integrity code. a more efficient method would be this: First expand PMK into two keys: PMKA = PRF(PMK. c. including the ATNonce.
Format and use of MIC Key.1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
2.2
a. and the message integrity code. The key PMKB would be used to generate the Session Keys instead of the PMK as described in the Generic Key Exchange protocol.3 2. The access terminal discards the KeyRequest message if the TransactionID field of the KeyRequest message is smaller 3
. The attacker lets the AT and the AN perform many session key agreements. Thus freshness is not guaranteed by this protocol. This should be more efficient. a future value. The key PMKA would be used instead of MIC key in the Generic Key Exchange protocol for authenticating the protocol messages. the ANNonce should always be a random value and not be incremented. The attacker remembers the key response message.

and EHMAC can be used to create the MIC.1. we believe. while the 80-bits MIC field of this message is replaced with 80 zeros for MIC computation.
4
. It is not clear what the construction is from its description in sec. the protocol does not show how this SessionSeed is communicated between Access Network and Access terminal. but also unnecessary due to the use of both Nonces. then. Nevertheless. We recommend to clarify that TransactionID should be unique throughout the Generic Key Exchange transaction until its successful completion.14.6.
2.7 Construction of PRF
The document a construction of a PRF which uses the HMAC-SHA-1-xx as the core.
2. The Access Network should avoid selecting the value of TransactionID which conflicts with other currently active Generic Key Exchange transaction. if there was a need for implicit association.3 ln.1.
2. Hence maintaining the TransactionID synchronicity becomes unnecessary.20 is not only unexplained. Alternatively. Thus SessionSeed does not have to be communicated from the Access network to the Access terminal.14-17 Qualcomm proposes that the MIC is computed on the entire message. Why not just specify that MIC is computed on entire message excluding the MIC field itself?
2. both Access Network and Access Terminal could create the PairwiseMasterKeyID from the PMK itself as PairwiseMasterKeyID = PRF(PMK.4 Generation of PairwiseMasterKeyID
It is unclear what is the SessionSeed on Pg. We suggest to remove the SessionSeed from computation of the Session Key. similarly to subsection 2.4 ln.”PairwiseMasterKeyID”). In fact.5 Computation of the Session Keys
The use of SessioSeed on Pg. in particular. we suggest that existing 3GPP2 standard cryptographic functions shall be used wherever possible.4 of the contribution C25-20050418-025R1. It is also unclear why the PairwiseMasterKeyID can not just be a 128-bit random number that the Access Network associates with the PMK at the PMK creation time. the f3 can be used as the PRF to create the Session Keys.2.6 Computation of the MIC
On Pg. 2.5 ln. thus implicitly requiring the Access Network to maintain the synchronicity of the TransactionID field with that expected by the Access Terminal.1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
than that received in the last valid ANKeyResponse message…”. The replay protection property expected from this mechanism will already be achieved if the ANNonce is a random number while the ATNonce is either random number or a counter.

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