1. IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-10-0029-00-0Sec Title: Considerations on use of TLS for MIH protection Date Submitted: January 14, 2010 Presented at IEEE 802.21 session #36 in San Diego Authors or Source(s): Subir Das (Telcordia) Abstract: Question and answer for Discussion 121-10-0029-00-0sec

2. 2 IEEE 802.21 presentation release statements This document has been prepared to assist the IEEE 802.21 Working Group. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.21. The contributor is familiar with IEEE patent policy, as stated in Section 6 of the IEEE-SA Standards Board bylaws and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/faq.pdf> Section 6 of the IEEE-SA Standards Board bylawshttp://standards.ieee.org/guides/bylaws/sect6-7.html#6http://standards.ieee.org/board/pat/faq.pdf

3. Proposal Use (D)TLS for authentication, key establishment and ciphering (D)TLS handshake can be carried out over MIH protocol (D)TLS provides cipher suites negotiation which provides crypto agility Use of existing authentication and key management protocol will greatly reduce the risk of introducing security flaws Pros: Once MIH SA is defined within MIH protocol, there is no need to have MIH transport level security 3 Source: 21-09-0066-02-0sec 21-10-0029-00-0sec

4. Use Case 1: Access Control Assumptions Access control is applied through the access controller The access control is applied through an access authentication with the MIH service provider through an Authentication Server (AS), e.g., an EAP Server or an AAA server Upon a successful authentication, the MN is authorized to access the MIH services through PoS’es The access authentication includes a key establishment procedure so that keys are established between the MN and the Authentication Server. When proactive authentication is supported, proactive authentication and authentication for MIH services use the same AS 4Source: 21-09-0066-02-0sec 21-10-0029-00-0sec

5. Use Case 2: No Access Control Assumptions Access control is not applied through any access controller The mutual authentication may be based on a pre-shared key or a trusted third party like certificate authority The authentication is MIH specific. That is, the mutual authentication will assure the MIHF identity of one party to another The MN and the PoS will conduct a mutual authentication and key establishment of MIH specific keys 5 Source: 21-09-0066-02-0sec 21-10-0029-00-0sec

6. Use Case 1: Access Control Peer (MN) AS MIA(PoS)) EAP/MIH messagesEAP/AAA messages (D)TLS Handshake Protected MIH Messages w access control MIH SA established Note: EAP may be performed in the context of proactive authentication as well 6 Source: 21-09-0066-02-0sec 21-10-0029-00-0sec

7. Use Case 2: No Access Control Peer (MN) PoS (D)TLS Handshake Protected MIH Messages w/o access control MIH SA established 7 21-09-0066-02-0sec 21-10-0029-00-0sec

8. Key Hierarchy for MIH SA MSK or rMSK PSK (dynamic) as (D)TLS credentials PSK (static) or public key as (D)TLS credentials Use Case 1 Use Case 2 8 Source: 21-09-0066-02-0sec (D)TLS handshake uses the (D)TLS credentials for authentication and establishment of (D)TLS key material for MIH SA 21-10-0029-00-0sec

9. 9 Question? Using TLS to protect MIH message require the MN to support TLS, is this requirement valid for the computing and storage limited mobile devices?

10. *Disclaimer: Data is obtained from Internet and author is not responsible for the correctness of the information 10 Some Data* OS/VersionFeatures Windows Mobile 6Encryption and certificate Management, secure protocols (SSL, TLS ) Symbian 9.4Full encryption and certificate management, secure protocols (HTTPS, SSL, TLS) Apple OSEncryption and certificate management, secure protocols (SSL, TLS) AndroidEncryption and certificate management, secure protocols (HTTPS, SSL, and TLS) Opera OS 7Encryption and certificate management, Secure protocols (SSL, TLS) 21-10-0029-00-0sec

11. 11 Some other Information “For user authentication, MS SHALL support at least one of EAP-AKA or EAP-TTLS” http://www.wimaxforum.org/resources/documents/technical/ T33 http://www.wimaxforum.org/resources/documents/technical/ T33 “Annex O (normative): Enhancements to the access security to enable TLS. Note: TLS is mandatorily supported by SIP proxies according to RFC 3261 [6], and operators may use it to provide confidentiality and integrity inside their networks instead of or on top of IPsec, as the intra- domain Za interface is optional, and TLS may also be used between IMS networks on top of IPsec” http://www.3gpp.org/ftp/Specs/html-info/33203.htm