1. 1 SAMSUNG BCMCS Security Architecture and Key Management JUNHYUK SONG SAMSUNG 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. SAMSUNG 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 SAMSUNG 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 SAMSUNG Incorporated. SAMSUNG 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 SAMSUNG Incorporated other than provided in the copyright statement above

2. 2 Contents Service Model Billing Model BCMCS Architecture BCMCS Address Management BCMCS Security BCMCS Service Establishment BCMCS Handoff Scenarios

3. 3 Service Model ASM (Any-Source Multicast) service model –This service is provided over dedicated channel –It is based on IP multicast over dedicated A8 and A10 connection –Multicast over mobile IP shall be supported Broadcast service model –This service is provided over shared channel (ex. BCMCS) –It is based on IP multicast over shared BCMCS A8 and A10 connection –The RADIO and Network path is statically provision by operator Multicast (Dynamic Broadcast) model –Has same characteristics with Broadcast service model, but the RADIO and Network path is dynamically set up based on the number of MS in the cell

4. 4 Billing Model Model 1 Free Access –MS does not need to subscribe to the service –No end-to-end encryption is required –Ex) Advertisement, Channel list Model 2 Flat Rate Accounting –MS need to subscribe the service –Monthly paid subscription –End-to-end encryption is required Model 3 Time Based Accounting –MS need to subscribe to the service –MS is billed by the time usage –End-to-end encryption is required

5. 5 BCMCS Architecture

6. 6 BCMCS Architecture Assumption BCMCS Control is logical entity, it can be physically built in the same box with Content Server or stand alone BCMCS Content Server and BCMCS Control may locate inside or outside of operator domain, however BA, SA, accounting and other service related information must be provision between operator and content provider RADIO and Network resource shall be pre-configured unless it is required by operator to dynamically setup the service with proper authentication and authorization

7. 7 BCMCS Architectural function BCMCS Control –It is optional control entity –Generate BAK for BCMCS –Encryption of BAK and other session information by TK –Provide BCMCS service subscription to subscriber –Pass BAK to MS and Content server BCMCS Content Server –May do same control function with BCMCS Control –Provide BCMCS content to MS AAA –Store BCMCS service subscription information, while it may share that information with BCMCS Control or BCMCS Content Server –Have SA with BCMCS Control or BCMCS Content Server –BCMCS Control and Content servers can be either inside or outside of operator domain

8. 8 BCMCS Address Management The IANA assigned the Class D address space for IP Multicast in the range from 224.0.0.0 through 239.255.255.255. There are several solutions available for Dynamic Multicast Address Allocation. However, those are not widely deployed. The GLOP addressing in 233/8 in RFC3180 may be used with source filtering –The IANA has allocated 233/8 as per RFC 3180. RFC 3180 describes the administration of the middle two octets of 233/8 in a manner similar to that described in RFC 1797:

9. 9 BCMCS Service Establishment Service Announcement Service Initiation with session information negotiation RADIO and Network Resource reservation with service authorization Network path setup BCMCS Content flows

10. 10 BCMCS Security BCMCS RADIO and RAN resource authorization through user profile for initial Multicast service in the cell –Service Authorization is required for BCMCS radio and network path setup the requested service is currently not available –It is only applied for the initial path setup BCMCS user service authorization through BCMCS content encryption –In case of controlled access BCMCS (model 2 and model 3), end to end encryption is required

11. 11 BCMCS Service Authorization for the first user in the cell

12. 12 Cont. Step A: The Mobile Station originates a SO33 to setup PPP session with PDSN Step B: AAA sends the multiple instances of the Multicast IP address and Source IP address of the content server in pairs, BCMCS_ID and Table Index that users are authorized to access to PDSN Step C: Session information (Multicast IP address, port number, session key, BCMCS_ID) is sent to MS in this stage through appropriate authentication Step D: In the registration message over Access Channel, MS sends BCMCS_ID and the Multicast IP address to BSC Step E: The BSC then checks if the requested BCMCS channel is currently broadcasted or not, if not the BSC sends A9-Setup- A8 message. BSC will include BCMCS_BLOB that contains BCMCS_ID, Multicast Destination IP and Source IP address pair in A9-Setup-A8 message

13. 13 Cont. Step F: Upon receiving the A9-Setup-A8 message from the BSC, the PCF realizes that the BSC wants to setup A10 connection for an IP multicast. If so, A11-Registration Request message to the PDSN sent. It is sent among other fields the GRE A10-Key, the PCF IP address, and BCMCS_BLOB NVSE (including the association of the multicast IP address pairs and BCMCS_ID) Step G: When PDSN receives A11-Registration Request, it realizes that the PCF wants to join a multicast group. The PDSN shall determine whether to connect A10 connection by looking up the authorized BCMCS index table for MS with Multicast Destination IP, Source IP address and BCMCS_ID from BCMCS_BLOB. If the requested BCMCS session is not currently authorized for the user, PDSN may send optional authorization request message to AAA.

14. 14 Cont. Step H: And then PDSN sends the A11-Registration Reply message to the PCF with success indication. Step I: PCF in turn sends the A-9Connect-A8 message including BCMCS_BLOB back to the BSC. The PCF achieves binding of GRE A8-Key, BSC IP address and GRE A10-Key to properly tunnels IP multicast packets to a BSC.

15. 15 BCMCS Security Keys There could be up to five keys, such as AUK key, RK, BAK, TK, and SK RK is “ root key ” that is only known to MS and AAA (Ex. MN-AAA key) BAK is a session key and it is only known to MS and BCMCS Control Manager TK is used for BAK distribution, and it is used to encrypt the BAK, Multicast Session information (Multicast IP address, Port and BCMCS_ID), and optional SK_RAND. It is only known to MS, BCMCS Control Manager, and AAA SK is optional session key and it is only known to MS and BCMCS Control Manager

16. 16 BCMCS SECURITY KEY MANAGEMENT RK Establishment –RK is “ root key ” that is only known to MS and AAA (Ex. MN-AAA key) –It is set when user sign up for the service –RK distribution is outside scope of this document

17. 17 Cont. BAK Establishment and Distribution –It is generated by the BCMCS Control –Occurs when MS request the session information –BAK is only valid during BAK_lifetime –Each BCMCS contents has its own BAK TK Establishment and Distribution –TK is only used for secure the BAK distribution from BCMCS Control to MS –TK = f(NAI, RK, Challenge, timestamp)

18. 18 Session Information (BAK, etc) Distribution call flow

19. 19 Cont. Step A: MS learn about the BCMCS service through Service Discovery. Step B: MS sends the request message to BCMCS Control Manager or BCMCS Content server for the BCMCS session information Step C: MS received the challenge for the request message authentication Step D: MS sends the second request message with user identifier (ex. NAI), Content_ID and message authenticator Step E: BCMCS Control or Content Server shall request the TK with NAI, challenge, timestamp and authenticator to AAA

20. 20 Cont Step F: Upon completion of user authentication, AAA shall generate TK = f(NAI, RK, Challenge, timestamp) Step G: BCMCS Control or Content Server shall encrypt whole message(BCMCS session information, BAK, BAK_lifetime and optional SK_RAND) with TK and send it to MS

21. 21 Cont. SK (Short Term Key) Establishment –SK can be used as optional session key over BAK so as to encrypt/decrypt the BCMCS contents –It has relatively short-term period than BAK –SK = f(SK_RAND, BAK)

22. 22 BCMCS Handoff Scenarios TBA

23. 23 Reference - QUALCOMM CDMA2000 Broadcast/Multicast Services Stage 2; Higher Layer Design, Version 0.05, Qualcomm - P00-20020924 SAMSUNG-CDMA2000_IP_ Multicast_Service Frameworkv0.02.doc