JSP电信通讯计费系统设计(含英文文献翻译)
The UMTS AKA challenge-response procedure is largely network-independent, and it is possible to run the AKA procedure over other transport mechanisms. Of particular interest here is the Internet Engineering Task Force’s (IETF’s) EAP framework.The IEEE 802.1 WLAN already supports EAP through the EAP-over-LAN specification.
3GPP does not assume any specific type of WLAN system, but for the purpose of this article we assume that the WLAN is type 802.11.We note that interworking with other WLAN systems, including the European HIPERLAN/2 and the Japanese HiSWANa, mainly depend on the ability to run EAP methods and to support an AAA interface.
In the 3GPP-WLAN architecture the home network will always be the home environment of the 3GPP system. The requirement on the serving network is for it to support the EAP-AKA authentication method. This implies support for an AAA node that can handle transport of EAP.
The UMTS AKA procedure relies on the availability of a tamper-resistant smartcard at the terminal. The smartcard, called a UICC, in UMTS, will run an application called USIM. It is the USIM application that runs the cryptographic algorithms during the execution of the UMTS AKA. This is an important point since it requires the WLAN mobile station (MS) to be able to access a UICC/USIM. This does not imply that the MS must itself contain a smart-card reader, since it could get access via its host system. We note that this access must be protected.
In order to execute the UMTS AKA procedures over EAP, we needs to define a separate EAP method.The EAP-AKA Internet draft provides exactly this functionality. Note that a similar EAP method exists for GSM/GPRS authentication (EAP-SIM). This EAPmethod is the basis for 3GPP-WLAN legacy interworking with GSM-only capable smartcards.It will not be discussed further in this article.
OVERVIEW OF THE ENTITIES AND DOMAINS
The following domains and entities are of interest when examining the 3GPP-WLAN security architecture. More information is found in TS33.234.Home Environment (HE) -- The central network elements in the HE when considering the 3GPP-WLAN architecture is:
Home subscriber server (HSS): The HSS is the entity containing authentication and subscription data required for the 3GPP subscriber to access service.
3GPP AAA server: The 3GPP AAA server is the entity that executes the AKA procedure toward the WLAN subscriber entity (UICC/USIM). The authentication information is retrieved from the HSS.
Serving Network (SN): In the 3GPP-WLAN context the SN will be the network responsible for the WLAN domain. The WLAN SN may or may not be operated by the HE operator.
3GPP AAA proxy: A 3GPP AAA proxy has logical proxying functionality and may reside in any network between the WLAN and the 3GPP AAA server.
Network access server (NAS): The NAS willbe the controller of a set of access points.
Access point (AP): The APs are the WLAN base stations. They will terminate the radio connection with the mobile station (MS).
User Equipment -- The user equipment consists of several entities. Note that the computing device may well have an internal WLAN card (MS), so the units may be inseparable.
UICC/USIM (smart card): The UICC/USIM is the entity that terminates the UMTS AKA sequence. It is presumed to be tamper-resistant. The UICC/USIM is normally owned by the HE operator.
MS: The MS is the
www.youerw.com Computing device: The computing device is the entity on which the IP stack is located.Typically this is a laptop PC or PDA. The computing device is assumed to be controlled by the user and owned by the user or some other non-operator organization/entity. No assumption regarding the system integrity of this device can be made.
TRUST ISSUES
In order to assess and evaluate the possible solutions for 3GPP-WLAN security it is necessary to have a clear picture of the threats the 3GPP-WLAN architecture will face. To address this issue we need to take a closer look at the proposed architecture. The following questions aim to make the picture clearer.
Which entities do we trust? A trust model is needed. Such a trust model would be based onentity ownership control and legally binding contractual agreements such as the roaming agreements between the mobile operators.
On what basis do we trust these domains/entities? The world is not black and white, and one needs to find a balance between risk and opportunity. So on what do we base our trust? Is the foundation solid, or tentative and loose?
What type of security features are needed to “enforce” the trust? Without sufficient protection mechanisms our trust could easily bebetrayed, by both our “trusted” partners as well as adversaries falsifying and misusing data.
What would be the goal of an adversary? Is the adversary content with eavesdropping, or would she also want to engage in active attacks? How resourceful is the adversary? Do we foreseetargeted and determined attacks, or do we merely want to offset opportunistic attackers. Can the attacks be automated, or would they be unique events?
A threat analysis is found in TS 33.234.We also have to consider the nature and basis of the trust relationships. The following provides a brief description. Assumed trust relationships:
User<->HE: The user and HE will have sufficient trust in each other that the HE is trusted to provide network access, and the user is trusted to pay for attained services. The trust is (often) captured in a legally binding contract that normally has a defined credit limit.
HE<->UICC/USIM: The UICC/USIM is normally the property of the HE operator. We shall therefore assert that the HE and UICC/USIM can trust each other. However, the HE may cancel and replace the UICC/USIM at any time.The opposite is not true.
HE<->SN: The trust relationship between the HE and the SN is governed by a legally binding roaming agreement. We shall assume that the trust is mutual.
SN<->WLAN access network: The exact nature of the trust relationship between the SN and the WLAN access network may vary. We assume that there is a binding agreement on service provisioning and charging issues between them.
User<->user equipment: We shall generally assume that user equipment is controlled by the user. One cannot assume that the user is capable of maintaining the integrity of user equipment.That is, user equipment cannot be trusted with respect to security functionality.
USER IDENTITY PRIVACY
Privacy has many aspects; one of them is location privacy. Location privacy is problematic since there is often a strong connection between the logical identity of the user and the routable address associated with the user device. The primary problem with many access networks is that the link layer (medium access control, MAC) address is visible to anyone by listening to the over-the-air signals. The association between the MAC address and the higher layer user identity is at times also visible or can be forced to be visible. The resourceful adversary could then be able to determine the position of a user with relatively high precision. To mitigate this problem, one often turns to protected temporary identities.
上一页 [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] ... 下一页 >>
JSP电信电话计费系统设计(含英文文献翻译) 第2页下载如图片无法显示或论文不完整，请联系qq752018766
