The present invention relates to a method, network element, and system for providing security of a user session. In particular, the present invention relates to an AAA user session associated with authentication, authorization, and accounting functions in a domain-based network such as the Internet or a 3G mobile communication network.
In recent years, communication technology has widely spread in terms of number of users and amount of use of the telecommunication services by the users. This also led to an increase in the number of different technologies and technological concepts in use.
Many existing and future networks like the Internet are organized in a domain-based manner. This means that the whole network is constituted of a plurality of individual administrative areas, which are known as domains or realms. Each such domain covers a relatively small region, but by an inter-connection of many of such domains, the whole network can achieve an enormous coverage in terms of area and users. Additionally, each such domain itself can again be organized in a domain-based manner being constituted of so-called sub-domains. Such a network configuration represents a hierarchical structure and is advantageous for administration and operation of a large amount of users.
The individual domains are built up or established, organized and managed by a respective service provider, and they are organizationally confined and independent but inter-connected with each other.
A popular example for such a domain-based network is the Internet with the Internet service providers (ISP) providing individual inter-connected networks representing the domains. In this context, the term of a user's or user terminal's ‘home domain’ means the particular domain of the ISP with which a user or user terminal is registered. The well-known address format for Internet communications therefore is username@homedomain.
In a domain-based network arrangement as described above, each service provider basically provides for communication or information services for the users registered with him. Today, however, there exist many security relevant and/or user-related services which makes the provision of security aspects such as authentication and authorization mandatory in communication networks. Many future Internet services or mobile communication services will also require such functions. The rules and directives to be followed by users having access to databases, systems and resources can be summarized by the term “security policy”. If a user, for example, wants to use a security-relevant service of another service provider, the user has to authenticate and/or authorize himself. For this purpose, he needs a password, a security key or the like. Such information can be managed in a centralized way or by a specialized network or part of a network providing such user-related services.
Additionally, the aforementioned inter-connection of domains enables a user to utilize services of service providers different from his own service provider and also within domains different from his home domain. This feature is often referred to as roaming and makes an additional accounting functionality necessary, for example, in order to gather billing, auditing and reporting information about the “visiting” user.
Conventionally, a specialized network for performing such functions as described above is built up “on top of” the communication network, and is often referred to as AAA (authorization, authentication and accounting) network. The thus realized functions like system access and database look-ups can take place in specific and separate AAA nodes, but in practice, these nodes are often implemented within the nodes of the underlying communication network which has the advantage of a joint use of hardware and thus reduced costs. Notwithstanding the hardware location, the AAA nodes offer a functionality which is distinct from other functionalities. Therefore, in the following specification a node is individually addressed as long as it provides a distinct functionality irrespective of its physical location or implementation.
For the sake of clarity and simplicity, it will hereinafter only be referred to AAA nodes. The structure of the AAA network is also in line with the underlying communication network like the Internet or a 3GPP network. More specifically, an AAA network servicing a domain-based communication network is also organized in a domain-based manner.
As stated above, various kinds of network access technologies are evolving very fast. As a result, a common AAA framework is needed to help those network access vendors to administer different kinds of local customers or foreign customers.
The use of AAA techniques provides as benefits an increased flexibility and control, scalability, and the usage of standardized authentication methods. However, specialized security and routing protocols are also needed for performing AAA functions properly and for routing respective messages related to AAA functions. Examples for such standardized AAA protocols, which are known to a skilled person, include RADIUS (Remote Access Dial-In User Services) which is standardized by the IETF (Internet Engineering Task Force), TACACS+ (Terminal Access Controller Access System) implemented by Cisco®, and Kerberos. These protocols are used for dial-in and terminal server access to the AAA network mainly from outside the domain. As an example, a user roaming in a domain of another service provider than his own provider has to authenticate himself within this domain. Therefore, he sends a request, possibly together with or like a password, to an AAA node within his home domain for providing him with the required services.
Recently, the AAA Working Group of the Internet Engineering Task Force (IETF) is under way of standardizing a new RADIUS-based AAA protocol called Diameter. Diameter is, hence, proposed by the IETF to solve the above mentioned problems and tasks. Then, different kinds of access technologies can utilize the capability of the Diameter Base Protocol, and send/receive their specific AAA messages within Diameter user sessions for each designated user.
A session can be understood as a service provisioning over time, but may also be a mere concatenation of transactions. Start and stop of a session is determined by a service definition. A session is linked to one or more users and relates to one or more service providers or operators which support the session with resources of some kind. Consequently, an active session can be considered as logical connection between a user or a corresponding user equipment and a service node of a provider's domain. A session has three phases: establishment, service, and teardown. The following description will, however, focus on readily established sessions, i.e. during their service phase, since the establishment and teardown of sessions lie outside the scope of the present invention.
Each session should have a session identifier (session-Id) which allows each provider and user in the session to audit session activity. A session-Id is normally generated as part of an authentication process by the device initiating the session, which in most cases is done by a client node (cf.
The Diameter Base protocol provides a session-oriented and policy-based framework for the functionality of Diameter routing of AAA messages being associated with a specific session. It is based on the nowadays commonly used challenge-response-type RADIUS protocol which is located at the network layer of the Open Systems Interconnection (OSI) network model. Diameter dial-up services are, for example, further on based on PPP (Point-to-Point Protocol) connections, but roaming support is enhanced, and the Mobile IP model is integrated, making Diameter the AAA protocol for the future. The terminology defined by the IETF in the version of the RFC3588 (Diameter Base Protocol) which was found on their website at “http://www.ietf.org/rfc/rfc3588.txt” on Apr. 13, 2004 will form the basis for the terms used in the further specification.
Hitherto, when large amounts of users are administered by a service provider, i.e. within an individual domain, it is reasonable to deploy the AAA network in a hierarchical way.
As can be seen in
Domains can be expected to have the same basic constitution. Hence, only domain A is described and a similar description of domains B and C is omitted.
Further, the hierarchical structure of an AAA network within a domain of Operator_A is shown in detail in
Each user registered with Operator A, i.e. in domain Dom_A, is fixedly associated with one of the plurality of service nodes, e.g. AAA Server 1. The respective service node (also known as ‘home server’ of this user) manages method lists containing user and service information needed for the operation of the AAA functions related to this user. For example, policy information for authorization like passwords and security keys of a user for a special service is stored in these methods lists.
The above structure also applies to AAA networks in other domains Dom_B, Dom_C, which is indicated by displaying the respective entry nodes.
A transmitting and processing of AAA messages will not be further examined in the following description. For the purpose of illustrating the present invention, it can be assumed that AAA messages being associated to a specific session are transmitted and processed “within” this session according to respective functions.
As regards security of user sessions and particularly user sessions in connection with AAA, there exist problems and drawbacks in practice.
In this connection, Bernard Aboba mentioned a mechanism of Reverse Path Forwarding (RPF) Check in the mailing list of the IETF AAA working group in order to authenticate the Diameter application messages. This method was found in section 4.3 on the website “http://www.ietf.org/internet-drafts/draft-irtf-aaaarch-handoff-04.txt” on Mar. 15, 2004. However, this is a method to protect RADIUS messages.
The Diameter Cryptographic Message Syntax (CMS) application provides a similar type of protection by encrypting payload of AAA messages. However, such an approach just protects the contents of the messages against eavesdropping, but a processing of messages would not be improved in terms of making a session more secure against attacks from outside.
However, the above mentioned work has now been stopped in the IETF and, thus, there still do not exist any practical measures for protecting AAA user sessions.
Until now, no measures concerning the security of AAA user sessions, and in particular of Diameter user sessions, have been developed. However, there are some attacks conceivable that would cause a legal (Diameter) user session to be interfered by some misbehaved or unfriendly (Diameter) server not being involved in this session. Such an attack may be e.g. a forging or spoofing of the session-Id for hacking a valid session.
Below, here are some examples of the threats which may occur to a user session. First, as regards shared access points for different ISPs, customers accessing a network via or being registered with a certain ISP may experience security deficiencies in their transactions, if no robust/secure user session is provided by this certain ISP. Second, problems regarding roaming users are likewise possible. A roaming user, i.e. a user being located in a domain different of the one where he/she is registered, has to build up a user session from the foreign domain to his/her home domain. Such a session has possibly to be established via networks of third party ISPs like 3G or wireless local area network (WLAN) operators. Without further protection of his/her session, the established user session may rather easily be broken, which would endanger the security and/or integrity of the user's transactions.
However, a use of vendor-specific message fields such as attribute-value-pairs (AVPs) to implement a proprietary end-to-end security mechanism would cause interoperability (IOP) problems and more software implementation and/or maintenance efforts.
Thus, a solution to the above problems and drawbacks is needed for providing more secure user sessions.
Consequently, it is an object of the present invention to remove the above drawbacks inherent to the prior art and to provide an accordingly improved method, network element, and system.
According to a first aspect of the invention, this object is for example achieved by a method for providing security of a session between a client of a domain of a network and a service node of said network is provided, which network consists of a plurality of domains, from which domain a user connected to said network via said client requests a service; said method comprising the steps of: receiving a message in a network element of said domain, which message is associated with said session and destined for said client; analyzing said message in said network element in terms of routing information contained therein; determining in said network element, whether said routing information admits said message to be forwarded to said client; and discarding of said message in said network element, if said step of determining yields that said message is not admitted to be forwarded to said client; wherein said routing information comprises an origin domain information of said message, which indicates a domain from which said message is expected to originate, and comprises a route information of said message, which indicates from which domain said message actually originates.
According to further advantageous developments:
According to a second aspect of the invention, this object is for example achieved by a method for providing security of a session between a client of a domain of a network and a service node of said network is provided, which network consists of a plurality of domains, from which domain a user connected to said network via said client requests a service; said method comprising the steps of: receiving a message in a network element of said domain, which message is associated with said session and destined for said client; analyzing said message in said network element in terms of routing information contained therein; determining in said network element, whether said routing information admits said message to be forwarded to said client; and discarding of said message in said network element, if said step of determining yields that said message is not admitted to be forwarded to said client; wherein said routing information comprises an origin domain information of said message, which indicates a domain from which said message originates.
According to further advantageous developments:
According to a third aspect of the invention, this object is for example achieved by a network element within a domain of a network consisting of a plurality of domains is provided, which provides security of a session between a client of said domain of said network and a service node of said network, from which domain a user connected to said network via said client requests a service; comprising: a receiver which receives a message which is associated with said session and destined for said client; an analyzer which analyzes said message in terms of routing information contained therein; a determinator which determines, whether said routing information admits said message to be forwarded to said client; and a message processor which discards said message, if said determinator yields that said message is not admitted to be forwarded to said client; wherein said routing information comprises an origin domain information of said message, which indicates a domain from which said message is expected to originate, and comprises a route information of said message, which indicates from which domain said message actually originates.
According to further advantageous developments:
According to a fourth aspect of the invention, this object is for example achieved by a network element within a domain of a network consisting of a plurality of domains is provided, which provides security of a session between a client of said domain of said network and a service node of said network, from which domain a user-connected to said network via said client requests a service; comprising: a receiver which receives a message which is associated with said session and destined for said client; an analyzer which analyzes said message in terms of routing information contained therein; a determinator which determines, whether said routing information admits said message to be forwarded to said client; and a message processor which discards said message, if said determinator yields that said message is not admitted to be forwarded to said client; wherein said routing information comprises an origin domain information of said message, which indicates a domain from which said message originates.
According to further advantageous developments:
According to a fifth aspect of the invention, this object is for example achieved by a system within a domain of a network consisting of a plurality of domains is provided, which provides security of a session between a client of said domain of said network and a service node of said network, from which domain a user connected to said network via said client requests a service; comprising: a receiver which receives a message which is associated with said session and destined for said client; an analyzer which analyzes said message in terms of routing information contained therein; a determinator which determines, whether said routing information admits said message to be forwarded to said client; and a message processor which discards said message, if said determinator yields that said message is not admitted to be forwarded to said client.
According to further advantageous developments:
It is an advantage of the present invention that an end-to-end security for user sessions, and particularly to Diameter user sessions, is provided. This also includes an increased security for users and service providers.
With the embodiments of the present invention, a higher security for a Diameter user session is provided, but also slightly slow down the processing of incoming messages in an AAA proxy and/or an AAA server and, therewith, the messages themselves.
It is another advantage of the present invention that valid user sessions can be protected against misbehaved AAA servers.
It is a further advantage of the embodiments of the present invention that two different measures to protect a legal user session against two different kinds of attacks are provided. Additionally, both measures can also be combined in accordance with an embodiment of the present invention.
Further, it is an advantage of the present invention that it can be used in any Diameter based AAA client and AAA server/proxy, or even in similar network nodes which are not necessarily based on Diameter.
Further, it is an advantage of the embodiments of the present invention that several problems according to other conceivable solutions of the problem such as interoperability problems with use of vendor-specific message fields do not occur.
In the following, the present invention will be described in greater detail with reference to the accompanying drawings, in which
It is to be noted that the present invention will be described with a specific focus on the usage of an AAA session and the Diameter Base protocol specified by the IETF AAA Working Group as the underlying AAA protocol. Nevertheless, the present invention is not limited to either of both but is also applicable to other types of sessions to be protected and protocols therefor, e.g. RADIUS, as long as these other protocols are similar to the Diameter Base protocol and support or are compatible to at least the routing functionality offered by Diameter.
A domain-based communication network underneath the AAA deployment concerned can exemplarily be the Internet. However, any other domain-based communication network is also conceivable, such as a 3G mobile communication system.
In
In the exemplified scenario, a user registered with Operator_A, i.e. the domain of Operator_A is the user's home domain, is denoted by his address “Someone@Operator_A.com”. The user is assumed to be located in the Helsinki airport chain store of “Coffee Shop” for drinking coffee. Since he requests a service of his home domain for which authentication, authorization and/or accounting functions are needed, he connects to the network via Coffee Shop's AAA client in order to establish a user session with an appropriate service node, i.e. the AAA home server, of his home domain. Accordingly, the session is established between “Coffee Shop Airport AAA client” and “Operator_A AAA Home Server” via the intermediate nodes, namely “Coffee Shop Helsinki AAA server”, “Coffee Shop AAA proxy”, and “Operator_A AAA proxy”, as can be seen in
In Diameter message format, an attribute-value-pair (AVP) which can be understood as an information field of a Diameter message has been defined for the session-Id. The session-Id is used to identify a specific session. The format of a Diameter session-Id may be the following: <sender's host>: <sender's port>; <increasing 32 bit value>; <optional values>. In the shown example, the session-Id for this (Diameter) user session is “CoffeeShop.helsinki.fi:84781;0;0;128”.
The first attack is that a misbehaved/unfriendly AAA server can pretend that it forwards a message on the actual AAA server's behalf. In the shown example, Operator_B's AAA home server initiates such an attack by sending, for example, a forged Abort-Session-Request (ASR) message, as if it relays or forwards a legal ASR message from Operator_A's AAA home server to the AAA client, i.e. “Coffee Shop Airport” AAA client, via which the user is connected to the network. The corresponding route is indicated by an arrow line in
In detail, a valid ASR message for the active session is exemplarily but not exhaustively composed of the following AVP fields:
In order to perform an attack as it is mentioned above, Operator_B has to find out specific data related to the active session, i.e. the contents of the AVP fields of the valid message. However, since the present invention is not immediately directed to aspects of how to find out about such session-specific data, such aspects are not dealt with herein. In the following, it is to be assumed that Operator_B has previously found out about these data howsoever, possibly by previously eavesdropping of messages associated with that session or the like. It is also conceivable that a misbehaved AAA server would initiate attacks towards a valid existing Diameter user session by simply “guessing” the Diameter session-Id, e.g. by randomly generating Id's of which one might match incidentally with an existing Id.
Then, Operator_B's home server can generate a forged message on the basis of the session-related data it found out, and sends it via its own AAA proxy in direction of the client node in question.
The forged ASR message from Operator_B is exemplarily but not exhaustively composed of the following AVP fields:
It can be seen that the forged ASR message differs from the valid/actual ASR message shown above only in comprising an additional Route-Record AVP entry. Such a route information indicates from which domain the message effectively originates. In this case, that the message originates at or was routed via the AAA server of Operator_B.
According to the prior art, such a route information would not raise suspicion in any of the network elements of Coffee Shop's domain, which process and forward this message. Therefore, the forged ASR message finally reaches the Coffee Shop Airport AAA client and the session will be stopped without the user's help or approval.
In
This first defense measure according to a first embodiment of the present invention can be understood as a patch on the routing implementation of the Diameter Base protocol and is, thus, called Patch-Routing. The idea of Patch-Routing is to check the incoming messages such as incoming Diameter messages within a Diameter user session, which should be sent on a certain Diameter peer connection, i.e. from a peer indicated in a routing table of the proxy, or on a lower layer security association. This check defends against the first attack by making good use of a Diameter routing table of a network element e.g. a proxy node, in which this patch is implemented. Such a routing table may according to the depicted example contain the following entries:
According to
On the basis of the origin realm of the message, i.e. Operator_A.com, the proxy node detects the respective peer information, i.e. proxy.Operator_A.com. Then, it compares the route information, i.e. aaaServer.Operator_B.com, with the retrieved peer information. If these compared information are equal, it is determined that the message is admitted to be forwarded to the client for which it is destined. If these compared information are unequal, it is determined that the message is not admitted to be forwarded. Thus, only the messages received from the domain “Operator_A.com” and which are actually retrieved from the peer connections to “proxy.Operator_A.com” or “trusted-AAA-relay.helsinki.fi” (not shown) are processed further.
In the forged ASR message according to
In other words, the method according to the first embodiment for providing security of a session between a client and a service node of a domain-based network comprises a receiving of a message, which message is associated with said session and destined for said client, an analyzing of the received message in terms of routing information contained therein, a determining, whether the routing information admits said message to be forwarded to said client. If the determining yields that said message is not admitted to be forwarded to said client, a discarding of said message is performed. And if the determining yields that the message is admitted to be forwarded, a forwarding to the client is performed. The above-mentioned routing information may comprise an origin domain information of said message, which indicates a domain from which said message is expected to originate, and may comprise a route information of said message, which indicates from which domain said message actually originates.
Additionally, the method can be supplemented by a further comparison operation in case the “first” determining yielded that the message is admitted to be forwarded. In such a case, said origin domain information may further be compared with a local domain, i.e. the domain of the network element performing the processing of the message, e.g. a proxy node of the domain of the client, and/or with a home domain of the user requesting a service, e.g. the domain of Operator_A in this example. Such a “second” processing may then be performed in an AAA server of the respective domain.
In
After determining the incoming message in the preceding step to be a valid message, it is routed according to the action defined in the routing table, e.g. relay or redirect, and forwarded to the Diameter Session FSM layer, where the session-Id is checked. If the session-Id is recognized, i.e. if the current session-Id matches with a session-Id of an active session being known at the respective network element, a predetermined callback function is evoked. If the session-Id is not recognized, an Abort-Session-Answer (ASA) message according to the Diameter Base protocol is sent accordingly. Thereafter, the message can be passed on to the Diameter XXX Application layer with XXX denoting a specific application to be carried out.
As to the above-mentioned callback functions, such callbacks implement an application profile processing for incoming messages, which may extend the basic attribute-value-pair data format of the Diameter protocol, for example. An application profile customizability is reflected into the application programming interface (API) as callback functions. A callback function, or message processor, comprises implementation details about how to handle the incoming AAA message. The processing logics specified to certain AAA messages are registered first, and when certain AAA messages arrive, the respective: callback function will take care of the messages and invoke the specified processing logics according to the registration information. Details on implementation may be found in the Diameter API Internet draft, i.e. “draft-kempf-diameter-api-04.txt” of March 2001.
In order that a network element such as an AAA proxy is able to perform the steps of the aforementioned method, the network element comprises: a receiver which receives the message, an analyzer which analyzes said received message in terms of routing information contained therein, a determinator which determines, whether said routing information admits said message to be forwarded to said client, and a message processor which discards or forwards said message, if said determinator yields that said message is not admitted or is admitted to be forwarded to said client.
It is to be noted that the mentioned receiver, analyzer, determinator, and message processor can be implemented by any known means, either in hardware and/or software, respectively, if it is only adapted to perform the described functions of the respective parts. For example, the analyzer can be implemented by any data processing unit, e.g. a microprocessor, being adapted to analyze the contents of messages in terms of a given information format or specification. The mentioned parts can also be realized in individual functional blocks or by individual means, or one or more of the mentioned parts can be realized in a single functional block or by a single means.
The second attack is that a misbehaved/unfriendly AAA server can pretend that it owns the Diameter user session, and tries to interfere the state of the existing Diameter user session. In the shown example, Operator_B's AAA home server initiates such an attack by sending, for example, a forged Abort-Session-Request (ASR) message, as it can guess the session-ID as mentioned beforehand, and then pretends that it owns the session. Such a pretending is effected in that Operator_B creates a forged ASR message with “aaaServer.Operator_B.com” as origin host and “Operator_B.com” as origin realm or domain. In detail, a forged ASR message according to the second attack is composed of the following AVP fields:
The necessary session-related information for performing such an attack is again assumed to be already known to Operator_B.
Operator_B then sends this message via its own AAA proxy to the AAA client via which the user is connected to the network along the route indicated by the arrow line in
It can be seen that the forged ASR message differs from the valid/actual ASR message, which is equivalent to the actual ASR message according to
According to the prior art, such a message would finally reach the “Coffee Shop Airport” AAA client and the session would be terminated without the user's help or approval.
In
This second defense measure according to a second embodiment of the present invention does not directly relate to routing functionalities. It can rather be understood as a patch on the Diameter Base protocol itself and is, thus, called Patch-Session. However, it also utilizes available routing information, but the processing can be performed differently and even in a different functional entity and/or network element. In this measure, it is not required to utilize a routing table, for example. The idea of Patch-Session is to check the incoming Diameter messages within a Diameter user session, which must be sent from either the local domain or the user's home domain. This check defends against the second attack according to
According to
In the forged ASR message according to
In other words, the method according to the second embodiment for providing security of a session between a client and a service node of a domain-based network comprises a receiving of a message, which message is associated with said session and destined for said client, an analyzing of the received message in terms of routing information contained therein, a determining, whether the routing information admits said message to be forwarded to said client. If the determining yields that said message is not admitted to be forwarded to said client, a discarding of said message is performed. And if the determining yields that the message is admitted to be forwarded, a forwarding to the client is performed. The above-mentioned routing information may comprise an origin domain information of said message, which indicates a domain from which the message originates.
As described above, the determining may comprise a step of comparing the origin domain information with a local domain and/or a home domain of the user requesting a service.
In
If the session-Id is recognized, i.e. if it matches with a session-Id of an active session being known at the respective network element, a predetermined callback function is evoked, for the function of which reference is made to the description of
In order that a network element such as an AAA server is able to perform the steps of the aforementioned method, the network element comprises: a receiver which receives the message, an analyzer which analyzes said received message in terms of routing information contained therein, a determinator which determines, whether said routing information admits said message to be forwarded to said client, and a message processor which discards or forwards said message, if said determinator yields that said message is not admitted or is admitted to be forwarded to said client.
It is to be noted that the mentioned receiver, analyzer, determinator, and message processor can be implemented by any known means, either in hardware and/or software, respectively, if it is only adapted to perform the described functions of the respective parts. For example, the analyzer can be implemented by any data processing unit, e.g. a microprocessor, being adapted to analyze the contents of messages in terms of a given information format or specification. The mentioned parts can also be realized in individual functional blocks or by individual means, or one or more of the mentioned parts can be realized in a single functional block or by a single means.
According to a third embodiment, the two above described patches can also be used together and/or consecutively. Thereby, the functionalities and advantages of both measures can be combined in that Patch-Routing according to the first embodiment and Patch-Session according to the second embodiment are combined to operate cooperatively.
The underlying scenario is the same as presented according to
More specifically, a Patch-Routing measure to check the incoming Diameter messages within a Diameter user session, which must be sent upon a certain Diameter peer connection or a lower layer security association, is exemplarily implemented in Coffee Shop's AAA proxy. Additionally, a Patch-Session measure to check the incoming Diameter messages within a Diameter user session, which must be sent from either the local domain or the user's home domain, is exemplarily implemented in Coffee Shop's Helsinki AAA server. Both measures work independently from each other and, together, provide for an increased end-to-end security for AAA user sessions.
Since the functions of the measures are the same as according to the first and second embodiments of the present invention, their description is omitted herein.
A system embodying the third embodiment of the present application may comprise a proxy node, e.g. a proxy node according to the first embodiment, and a server node, e.g. a server node according to the second embodiment, of the domain of the client, via which a user requesting a service is connected to the domain-based network. In such a system, the proxy node is advantageously arranged upstream of the server node as regards the direction of the message associated to the active session and destined for the client.
As is to be understood from the above, the present invention relates generally to the security of a user session, and particularly to the security of a Diameter user session.
The present invention is also relevant to 3GPP, namely the Ws interface. But it also applies to the Wr interface since a WLAN access network (AN) can have connections to multiple 3GPP visited networks.
To protect the Diameter user sessions against the above attacks, two new patches are introduced herein. Both are patches on the Diameter Base Protocol.
In order to protect against the attacks among the peer realms, the peer AAA proxies at the boundary are advised to adopt the security measures of the embodiments of the present invention, so that neither would be “hijacked” by a third party.
Methods, network elements, and a system for providing security of a session between a client of a domain of a network and a service node of said network are provided, which network consists of a plurality of domains, from which domain a user connected to said network via said client requests a service. The providing of security is based on analyzing a message, which is associated with said session and destined for said client, in terms of routing information. Such routing information may comprise an origin domain information of said message and a route information of said message, or an origin domain information of said message, which indicates a domain from which said message originates. The present invention is particularly advantageous for AAA sessions associated with authentication, authorization, and accounting functions and for usage of Diameter Base protocol.
Even though the invention is described above with reference to the examples according to the accompanying drawings, it is clear that the invention is not restricted thereto. Rather, it is apparent to those skilled in the art that the present invention can be modified in many ways without departing from the scope of the inventive idea as disclosed in the appended claims.
Number | Date | Country | Kind |
---|---|---|---|
04008979.9 | Apr 2004 | EP | regional |