1. May, 2009 C2 – Company Confidential SOURCE: Simon Mizikovsky, Ganesh Sundaram, Zhibi Wang, Jialin Zou CONTACT: smizikovsky@alcatel-lucent.com, ganneshs@alcatel-lucent.com, zhibiwang@alcatel-lucent.com,smizikovsky@alcatel-lucent.comganneshs@alcatel-lucent.comzhibiwang@alcatel-lucent.com jialinzou@alcatel-lucent.com ABSTRACT: This is a stage 2 proposal on the security layer evolution for HRPD Rev-C. TITLE: HRPD Rev-C Security Layer Evolution TSG-C RECOMMENDATION: Discuss and adopt. The source companies of this contribution grant 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. The source companies of this contribution 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 The source companies of this contribution 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 The source companies of this contribution. The source companies of this contribution specifically reserves the right to amend or modify the material contained herein and to any intellectual property of The source companies of this contribution other than provided in the copyright statement above.

2. C2 – Company Confidential 2 | Rev-C Security Layer Evolution | May, 2009 Disadvantages in the current Security Layer  Identified issues and disadvantages of current security layer in CDMA Rev B -Revision B air interface is not efficient when the security is applied. -Complexity of security with Multi-carriers -Efficient Selective Security Requires Differentiation Between Streams Current Security Layer cannot distinguish streams -Encryption cannot be implemented separately from lower layer functions -Pre-encryption is impossible  Propose to re-use security solution similar to that in UMB, i.e. define an additional security function at the Air Interface Application layer. Adapt this function to the HRPD Rev.C, while retaining the current Security Sub-layer for Strict Backwards Compatibility.

3. C2 – Company Confidential 3 | Rev-C Security Layer Evolution | May, 2009 EVDO layering and security evolution Air interface application layer Streaming layer Session layer Connection layer Security layer MAC layer Physical layer Air interface application layer (Security function, new application subtypes for SLP, RLP) Streaming Layer Session layer Connection layer Legacy Security Layer MAC layer Physical layer Revisions 0, A, BRevision C Note: This contribution makes proposal for the security function for the HRPD Rev C. Since the detail air interface structure for the Rev C is yet to be finalized, the proposal is based on air interface architecture for Rev B. It is expected that corresponding adjustments might be needed when the air interface format for Rev. C is finalized.

4. 11/12/2006 Lucent Technologies – Proprietary Use pursuant to company instruction4 EVDO Application Layer Security (ALS)  EVDO Application Layer Security (ALS) enable encryption/authentication  ALS keeps track of “byte stream” numbering –Synchronized with RLP layer (between RNC and BTS)  ALS breaks “byte stream” into 128 bit blocks (count) –Each byte is identified using block number and byte number within the block, and is reset to 0 after (2 55 -1) blocks Example: Byte 173 of byte stream is identified as 10.12 –ALS count is a virtual counter that is in “sync” with RLP sequence number all the time. For the multiple-carrier, the virtual counter is calculated based on Segmentation and Reassembly (SAR) sequence number SAR_seq, which is used to segmentation and reassembly the packet. 1-1 correspondence between RLP sequence # and ALS count WARNING: Application = Air Interface Application = RLP or SLP NOT RTP

5. 11/12/2006 Lucent Technologies – Proprietary Use pursuant to company instruction5 Link Layer Assisted ALS: Encryption  Each ALS block encrypted by AES in counter mode –No additional overhead needed. Encrypted or not is known during call set up for every RLP stream  Cryptosync at transmitter is derived from direction bit (forward vs reverse link) followed by RLP flow id followed by block number –Note that RLP sequence number will start to recycle after 2 22 -1 (or 2 6 –1 for VoIP), but ASL blocks will not until 2 55 -1  At receiver, cryptosync is derived easily from RLP sequence number –Example: Suppose RLP packet with sequence number 173 is received, then the receiver identifies the first byte of the packet as block 10.12. Therefore bytes 173, 174, 175, 176 will be decrypted using the 12 th through 15 th bytes of AES counter output using cryptosync value (direction bit, RLP flow id, block number (=10)). Bytes 177 through 192 will be decrypted using the 0 th through 15 th bytes of AES counter output using cryptosync value (direction bit, RLP flow id, block number (=11)), I.e., cryptosync has been incremented by 1, etc…

6. 11/12/2006 Lucent Technologies – Proprietary Use pursuant to company instruction6 VoIP with ROHC and ALS EVRC<=176PADRTP=96UDP=64 IP=160 Multiple of 32 EVRC<=176ROHC 16, 32 EVRC<=176ROHC 16,32 CRC+Tail=30 MAC 2 EVRC<=176ROHC 16,32 UP TO 516 bits UP TO 208 bits UP TO 256 bits RLPLength LinkFlowID5 Route1 First1 Last1 SEQ6 (VoIP) RLP+STR 16 EVRC<=176ROHC 16,32 RLP+STR 16 UP TO 224 bits

7. 11/12/2006 Lucent Technologies – Proprietary Use pursuant to company instruction7 PPP aware link layer assisted ALS for Explicit MAC  Forward Link: RNC receives PPP frames from PDSN –PPP frames encapsulated in GRE packets, but no PPP for VoIP  Reverse Link: IP packets sent to PPP layer prior to RLP  PPP frames are analyzed in order to perform Van-Jacobson header compression –Essentially the IP and TCP header are “compressed” Some fields are eliminated, some fields are “incremented” and some fields are maintained as is (e.g., TCP checksum)  PPP assisted ALS for TCP based best effort services –ALS packet = Output of V-J compression followed by EHMAC tag PPP frames are typically large, hence MAC is efficient Cryptosync is based on the counter maintained at ALS  Encrypt ALS packet (Link Layer Assisted ALS) following which RNC transmits encrypted ALS frame to BTS –EHMAC tag is also encrypted in the process

8. 11/12/2006 Lucent Technologies – Proprietary Use pursuant to company instruction8 TCP with V-J compression and ALS HTTP/FTP etcTCP=160 IP=160 V-J Comp RLPLength LinkFlowID5 Route1 First1 Last1 SEQ22 HTTP/FTP etc V-J CompHTTP/FTP etcPPP V-J CompHTTP/FTP etcPPP TAG V-J CompHTTP/FTP etcPPP TAG RLP+STR 32 RLP+STR 32 MAC 2 RLP+STR 32 MAC 2 RLP+STR 32 PDSN RNC RL BTS FL RNC FL BTS RL ALS

9. 11/12/2006 Lucent Technologies – Proprietary Use pursuant to company instruction9 Receiver operation  Receiver decrypts packets at ALS using RLP sequence number and RLP link-flow ID –Construct count based on sequence # and link-flow ID –Plaintext = A -1 (Ciphertext-B), where A=AES(count,0), A -1 is the inverse of A in GF(2 128 ) and B=(count,1)  For UDP based VoIP packets receiver passes decrypted ALS packets up to “ROHC routine” to reconstruct headers –No explicit message authentication  For TCP based best effort packets receiver constructs ALS frame and verifies MAC –Transmit verified packets to “V-J routine” to reconstruct headers –In order to verify MAC, the entire ALS packet has to be received This may introduce some delays at the receiver, but for TCP based services this is needed regardless of security at ALS

10. 11/12/2006 Lucent Technologies – Proprietary Use pursuant to company instruction10  Security part embedded in the packet application and signaling application –It was proposed that the Air Interface Application security be part of the HRPD supplemental service. This will be considered. Security function will include new application subtypes for SLP and RLP  New subtypes for packet/sig apps –If the ALS is part of the air interface application layer, new subtypes for the packet/sig apps will be needed.  Document structure. –The document structure will be consistent with that of C.S0063 or a new document  Clarifications on the header for encryption, how often encryption keys are to be changed etc., if it is changed in an active data call etc. –The session key is not expected to be changed during the session. For an inactive mobile that is re-activate, the new keys can be used with an signaling, therefore, there is no need to carry the keyindex for every packet. Additional Consideration

11. 11/12/2006 Lucent Technologies – Proprietary Use pursuant to company instruction11 Benefits of Proposed Security Function in the Air Interface Application Layer  The security function is applied before the fragmentation, and the lower layers receive the data after it has already being processed by the security function. Therefore, the identified inefficiency is eliminated.  The security function is in the air interface application layer, traffic flows can be selectively processed by security function.  There is no need to wait for final delivery scheduling, the data can be pre-processed by the security function ahead of time.  For the multiple carrier, because security function is applied to the packet before segmentation, corresponding key management is simplified.

12. 11/12/2006 Lucent Technologies – Proprietary Use pursuant to company instruction12 Summary  This contribution introduces Application Layer Security (ALS) option which overcomes all the disadvantages –ALS operates between RLP and header compression layer –ALS includes two new concepts Link Layer Assisted Encrypted and optionally Implied Message Authentication PPP Assisted Explicit Message Authentication –ALS options configured for each EVDO application stream during “call” set up by adding a three bit field to QoS Blob