1. Dec. 20033GPP2 TSG-X PDS 1 BCMCS Higher-Layer Encryption Raymond Hsu, Jun Wang Qualcomm Inc. Dec. 2003 Notice QUALCOMM Incorporated grants a free, irrevocable license to 3GPP2 and its Organization 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 portions of the contribution; and at the Organization Partner’s sole discretion to permit others to reproduce in whole or in part such contributions or the resulting Organizational Partner’s standards publication. QUALCOMM Incorporated 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 QUALCOMM Incorporated 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 QUALCOMM Incorporated. QUALCOMM Incorporated specifically reserves the right to amend or modify the material contained herein and nothing herein shall be construed as conferring or offering licenses or rights with respect to any intellectual property of QUALCOMM Incorporated other than provided in the copyright statement above.

2. Dec. 20033GPP2 TSG-X PDS 2 Outline BCMCS higher-layer encryption methods –End-to-end IPSec –Last-hop IPSec –Secure RTP (SRTP) Recommendation Annex – Some SRTP detail for BCMCS

3. Dec. 20033GPP2 TSG-X PDS 3 End-to-End IPSec CS generates SK from BAK and Security Parameter Index (SPI). CS uses SK to encrypt the ESP payload & trailer. –ESP transport mode is used. –ESP authentication feature is not used. If MS doesn’t have the SK associated with the received SPI, the MS generates the SK from BAK and the received SPI. Concerns: –Some companies have concerns of using SPI as a parameter to generate SK. –Transport overhead concern (see next page).

4. Dec. 20033GPP2 TSG-X PDS 4 Transport & IPSec Overhead The total overhead per packet ranges from 66 to 81 bytes with the average of 74 bytes. Blue header fields are encrypted and cannot be compressed. IV cannot be compressed because it changes randomly for every packet. If ROHC’s ESP/IP profile is used, red header fields can be compressed from 28 to about 2 bytes. This reduces the average overhead per packet to 48 bytes.

5. Dec. 20033GPP2 TSG-X PDS 5 Last-Hop IPSec PDSN receives from CS the BCMCS content in clear-text or protected by a CS-PDSN IPSec tunnel. PDSN uses SK to encrypt the BCMCS content. Issues & concerns: –Does PDSN generate SK? How? –How the SK is distributed to MS? –Transport overhead concern

6. Dec. 20033GPP2 TSG-X PDS 6 SRTP SRTP provides a framework for encryption and message authentication of RTP and RTCP streams. –For BCMCS, we can leverage the RTP encryption aspect of SRTP to protect BCMCS content from CS to MS. SRTP provides key hierarchy. –SRTP master key corresponds to the BCMCS BAK. –SRTP session key corresponds to the BCMCS SK. Total overhead per packet is 41 bytes (see next page). –RTP/UDP/IP header is 40 bytes. –MKI is optional and is minimum 1 byte. »If the SRTP master key is BAK, then MKI is BAK_ID. SRTP has better transport efficiency than IPSec –If ROHC’s RTP profile is used, the RTP/UDP/IP header can be compressed to about 2 bytes. –This reduces the total overhead to 3 bytes per packet. SRTP is in the RFC-editor queue since 2003/11/18. –draft-ietf-avt-srtp-09.txt

7. Dec. 20033GPP2 TSG-X PDS 7 SRTP Packet Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | payload... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SRTP MKI (OPTIONAL) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The RTP payload (in red) is encrypted.

8. Dec. 20033GPP2 TSG-X PDS 8 Recommendation If BCMCS higher-layer encryption is desired, we recommend using SRTP. We can request for expedited processing to get an RFC number for SRTP before the BCMCS spec deadline.

9. Dec. 20033GPP2 TSG-X PDS 9 Annex – Some SRTP Detail for BCMCS

10. Dec. 20033GPP2 TSG-X PDS 10 SRTP Initialization CS is configured with the SRTP parameters for a particular BCMCS content. MS obtains the SRTP parameters from BCMCS Controller during Information Acquisition. SRTP parameters: –Master key (e.g., BAK), –Master salt (may be a public value), –Master Key Index (MKI), –Hashing algorithm for key derivation, –Key derivation rate, –encryption algorithm, –Initial RTP sequence number, –etc.

11. Dec. 20033GPP2 TSG-X PDS 11 SRTP Session Keys Generation Session Encryption Key (Required) –Used in generating a keystream to encrypt the RTP payload. –Default encryption algorithm is AES in Counter Mode (AES-CM). –Default key length is 128 bits. –This corresponds to the BCMCS SK Session Salt Key (Required) –Used in generating an Initialization Vector (IV) for encryption. –Default key length is 112 bits. Session Authentication Key is not required for BCMCS.

12. Dec. 20033GPP2 TSG-X PDS 12 SRTP Session Keys Generation Session keys are generated from the master key, master salt, packet index, and key label. –Master key is the BAK. –Packet index = 2 16 * ROC + SEQ »SEQ is the RTP sequence number (2 bytes) of the packet where the session keys need to be refreshed according to the key derivation rate. »ROC is the roll-over-counter that tracks the number of time SEQ rolls over from the start of an RTP session. –Key label is a 1-byte constant value identifying the session key type. –Default key derivation algorithm is AES-CM. Initial session keys are derived using the initial packet index value computed with –ROC = 0, and –SEQ = Initial RTP sequence number. Session keys are refreshed according to the key derivation rate.