Presentation on theme: "21-07-0297-00-00001 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-07-0297-00-0000 Title: Possible MIH security approaches and issues Date Submitted: September."— Presentation transcript:
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Possible MIH security approaches and issues Date Submitted: September 12, 2007 Presented at IEEE session #22 in Hawaii Authors or Source(s): Lily Chen (NIST), Subir Das (Telcordia), Marc Meylemans (Intel), Sood Kapil (Intel), Srinivas Screemanthula (Nokia), Michael Williams (Nokia), Yoshihiro Ohba (Toshiba) Abstract: This document provides an outline for security study group to discuss possible approaches.
IEEE presentation release statements This document has been prepared to assist the IEEE 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 IEEEs name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEEs 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 The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual and in Understanding Patent Issues During IEEE Standards Development Section 6.3 of the IEEE-SA Standards Board Operations Manualhttp://standards.ieee.org/guides/opman/sect6.html#6.3 IEEE presentation release statements This document has been prepared to assist the IEEE 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 IEEEs name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEEs 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 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 Section 6 of the IEEE-SA Standards Board bylawshttp://standards.ieee.org/guides/bylaws/sect6-7.html#6
Abstract Summarize the discussions to date related to SSG. Reach common understanding about the possible approaches. Agree on terminologies used to describe each scenario. Analysis of each of the possible approaches. Identify SSG tasks.
Two Security Problems* Problem 1: Security Signaling Optimization during Handover Problem 2: MIH level security mechanism * We use the terms defined in security- proposal.ppt
Problem 1 When performming a handover, authenticate to attach to a new point of attachment (PoA); and establish a new protected link (confidentiality and integrity protection) with the new point of attachment. At the same time, all the security solutions must minimize delay. Handover to a new connection: 1.Authentication 2.New protected link Current link
Handover Scenarios Inter-domain without roaming agreement Authentication based handover*. Use different credentials for authentication. Intra-domain or inter-domain** with roaming agreement Key hierarchy based handover*. *We use the terms in security-issues-in- transition.ppt **In the following, we treat inter-domain with roaming agreement as intra-domain scenario. Note that for hierarchy based handover, it may use a key in the hierarchy to conduct a local authentication.
Inter-domain Scenarios Inter-domain scenario without roaming agreement in place, implies that access authentication must be executed for each domain separately. (Here access authentication means authentication with the long term credentials established with the domain, for example, by EAP-TLS.) It may use pre-authentication to shorten the delay for handover. However, for pre-authentication, we may also need some agreement. Two situations are under consideration. Over-the-air pre-authentication – The peer/mobile node direct request access with the target point of attachment. It must allow concurrent connections to different type of networks. Over-the-DS pre-authentication – The peer/mobile node send access request through the serving point of attachment. The serving point of attachment must be able to direct the request to the correct network entity which may belong to a different network (in a different domain). Question: Any work to be done in ?
Intra-domain Scenarios Intra-domain handovers require a Key Hierarchy based solution Handovers between different media types HOKEY key hiearchy (EMSK derived root key) Re-authentication to trigger rMSK delivery. * Possible issue: For certain media, EAP may not be the access authentication protocol. Handovers between the same media types Media-specific handover security solutions, e.g r, 3GPP. It may use the key hiearchy established in a full access authentication (use MSK as a root key). Implicit authentication; and Link layer key establishment (media specific).
Example: Key Hierarchy for r Fast Transition Peer Authenticator AS EAP MSK Peer - new location
Possible Approaches Use HOKEY key hierarchy to generate root keys for handovers between different media types HOKEY is media-independent. Use Post-EAP key hierarchy for handovers between the same media types using rMSK as MSK. Minimize changes to existing handover technologies in different technologies, e.g r. Question: Any work to be done in SSG? Work with HOKEY. Work with WGs for different media.
Possible Issues? EAP may not be used as an access authentication. Key hierarchy may not be available.
Problem 2 Main goals Authentication needed to access the Services, e.g. Information Service; and (this is also called access control.) Authorization on access to the service. Protect the Service data delivery. Main scenarios Authentication (EAP) server for network access is MIH aware. Interface with e.g. the Information Server. Access database for service subscription. Authentication (EAP) server for network access is not MIH aware No interface with e.g. the Information Server. Cannot access the database for service subscription. Further Assumption Information Server access requires network access first* * Any issues with this assumption?
Use Network Access Authentication Authentication Server accesses service database to look up; For IS Use an IS-Key, derived in access authentication/key establishment as the Information Service root key; The IS-key is delivered to IS to derive session keys for protection SSG tasks Specify key derivation algorithms; Specify message protection algorithms (encryption, integrity protection, etc). Question – Any other tasks? AS Authenticator IS Access Authentication IS-Key Protected information service ( SSG)
Independent Authentication for Service Need Service Specific Authentication Server (maybe IS, ES, CS together). (or IS will serve as an authentication server) tasks: Specify authentication methods and/or protocols. Specify key establish methods and/or protocols. Specify key derivation functions. Specify information protecting algorithms. AS IS Service Authentication Key Protected information service
Comparison and Issues? Which one is more realistic? Use network access authentication for Information Service authentication; Do not need new authentication protocol; Information Service (IS) is integrated in the network landscape. Only demand one authentication with one set of credentials. EAP server must be IS aware. May need modifications to the current EAP server. Independent authentication for Information Service? Can be added without demanding modifications to the EAP server. Independent to existing media service and can work for any domain and media. Demand two authentications with two sets of credentials.
Use IS for Security (Problem 3) Can we use the Information Service to optimize security? For mobile nodes, use information service to get information on Authentication methods supported in targeted network; Which points of attachment have received keys. For authenticators Where to distribute (push) the keys.
Other Security Issues to Work on? DoS attack mitigation mechanisms for service? (Michael Williams will elaborate)
Summary Problem 1 Inter-domain: Pre-authentication Intra-domain: Inter-media: –If EAP is used as an access authentication and HOKEY hierarchy is available HOKEY key hierarchy based handover ( SSG works with HOKEY); –Otherwise, new work. Intra-media: Media specific key hierarchy based handover ( SSG works with WGs in different media). Problem 2 Use access authentication (require interface between AS/AAA and IS); Independent authentication SSG tasks on solving problem 2 Specify authentication (if use independent authentication.) Specify information protection algorithms. Specify security information service. Problem 3 ( SSG) Use Information Service to optimize security solutions.