Patent Application
20110320803
None
None
The invention relates generally to host-based mobility and multi-homing protocols, and more specifically to mobility protocols that efficiently and cost-effectively update changes in transport connections while providing sufficient security at a reasonable cost.
Mobile internet traffic has increased dramatically in recent years, particularly since the advent of the latest generation of smart phones. Advances in phone technology have dramatically increased internet traffic, and have forced the research community to rethink the existing concepts of IP mobility and multi-homing. One basic tenant of IP mobility is for a host to be able to change a L3 attachment point, i.e. IP address, during an ongoing transport session. A multi-homed host that needs to be able to selectively switch ongoing sessions to a different interface, such as, for example, from a 3G wireless network to WiFi, must also be able to change an IP attachment point.
Designing protocols for communication devices via public infrastructure inherently involves serious consideration of security issues, due to the public nature of, for example, the internet. In a public forum, adversaries can misuse information, and redirect transport sessions for malicious purposes. Such redirection attacks allow the adversary to hijack, for example, a communication session, and continue the session on behalf of one of the session end points.
Adversaries can also use access to the session for distributing Denial-of-Service (DoS) attacks, where the adversary steers high volume traffic toward a victim host. DoS attacks are also known as flooding.
Redirection and flooding each introduce different security problems with often very different solutions.
For example, the available mechanisms to protect against redirection attacks depend on the mobility technology. Current mobility standards, such as W-CDMA, LTE and WiMAX, use network-based mobility. These technologies employ network-side anchors to relay all traffic between a Mobile Node (MN) and its peers. All mobility-related signaling is exchanged between the MN and the network(side anchors?), which can be secured by exploiting trust relationships that exist between a subscriber and his service provider.
Alternatively, host-based mobility allows the MN to update a Correspondent Node (CN), when the MN has changed its IP address. In response, the CN can directly send data packets to the MN's new address. As a result, host-based mobility protocols are more cost-effective, versatile and scalable, since they eliminate the need for network side anchors. The advantages of host-based mobility systems have sparked a good deal of research activity attempting to establish suitable low cost host-based mobility protocols. Examples of such protocols can include, the Host-Identifier Protocol (HIP), route-optimized Mobile IPv6 (MIPv6 R/O), TCP-R and EMIPv6, to name a few of the more well known protocols to date.
Some of the known host-based protocols support multi-homing scenarios. Specifically, in the multi-homing scenarios, the host can announce multiple IP addresses to the CNs as alternative routing paths. Examples of such protocols include SCTP, HIP, multi-homed TCP (MH TCP) and SHIM6. Since both mobility and multi-homing address closely related issues, typically one refers to mobility when addressing both phenomena.
As far as security in the host-based mobility protocols is concerned, host-based mobility is confined to the end nodes sustaining traffic connections. As a result, trust relationships are usually unavailable to protect mobility-related signaling messages. Within the framework of HIP, for example, it was proposed to create trust relationships on a global level, i.e. for all hosts on the Internet, using PKI. As a result, the effort, as well as the scalability and revocation issues relating to creating trust relationships significantly impairs the principal advantages of host-based mobility. Thus, some proposals resort to mechanisms, such as IPsec, which requires a previously arranged trust relationship for a connection.
As a result, most host-mobility protocols have relied on methods of weak authentication, such as open exchange of random nonces, key arrangement through Diffie-Hellman exchanges and routability tests. Such solutions either provide insufficient protection, or put unnecessary processing burdens onto the end nodes.
A transport connection system is set forth. The system includes a first device adapted to send and receive messages. A second device, adapted to send and receive message, is also provided. A message i generated by the first device includes a secret Ri-1 to a Hash (Ri-1) sent from the first device to the second device in a prior message i-1. The message i is signed by a random key Ai-1, the random key being derived from an update of a key Ai-2 from the prior message, wherein message i-1 is signed by the key Ai-2.
A light-weight security solution to protect a host-based mobility protocol from redirection and flooding attacks is set forth. Host-mobility, as referred to herein, is the migration of transport-connection end-points from one IP address to another, and applies to mobility events and multi-homing scenarios. The solution herein combines methods of weak authentication with proof of session ownership capabilities. The solution requires additional, and sometimes substantially more effort for an adversary to successful launch an attack than equivalent attacks against existing signaling protocols on the internet. Advantageously, the solution can be used to improve Mobile IPv6 with route optimization.
In accordance with the principles herein, the requirement for a mutual trust relationship and/or network-based infrastructure, such as network-side anchors, is eliminated. The solution is light-weight, in that it requires minimal processing and state information to be held on either end of the connection. The security level is sufficient compared to existing internet security solutions. The solution is at least as secure as known protocols for protecting against redirection attacks. The solution is better than known security protocols for preventing flooding attacks.
In accordance with the principles herein, each mobility session supports mobility-related signaling and security between two hosts. Traffic connections run in parallel to the mobility session. Each mobility session defines at least one mobility association (MA). The MA establishes a simplex mobility session between a mobility node (MN) and a correspondent node(CN). Simplex MA's also reduce the risk of redirection attacks since the CN does not send IP address updates, only the MN. Host-based mobility sessions of simplex nature reduce the security-related signaling and processing efforts, as well as the amount of state needed to be held at each end of the connection.
Each MA is owned by one of the two hosts and provides the owner host with mobility support. MN provides proof of ownership of the MA to CN, and CN confirms routability to MN through a single branch RRT. MN can prove ownership of the MA by maintaining and using a symmetric authentication key. MN can regularly update the key based on CN's messages. MN can further authenticate requests, to protect against passive attackers, by relating a secret related to a prior message to create a chain of proof of the same sender. The proof of ownership protects against session hijacking and session interruption.
If both hosts are mobile, the system herein can be adapted to establish a duplex mobility session, wherein each host has to support its own MA within the same mobility session. In other words, a session would include two superimposed simplex mobility sessions, resulting in a session that appears to be duplex, but with reduced processing requirements. Each host can, via the MA it owns, change their IP addresses without breaking ongoing transport connections, and can be applied to wireless networks as well as wireless multi-homing scenarios. The MA's must be established before or during the setup of associated traffic connections in order to prohibit an attacker from overlaying an MA onto an existing traffic connection or to hijack the session after setup. Further, the system provides greater security against session hijacking than MIPv6, without requiring network support or processing overhead of DH-based key exchanges or mutual trust relationships. MN can also use the MA to determine if a peer supports host-based mobility.
As illustrated in
An MA, shown generally at 100 for Mobility and at 110 for Multi-homing is established via any suitable initial handshake, commonly known as an INIT, which can include, for example, an INIT request 112, 114 and an INIT response 116,118. The initial handshake is supported by all host-based mobility and multi-homing protocols. The initial handshake also defines the mobility session itself.
After the initial handshake, all further handshakes occur on behalf of one MA, i.e. they only affect security-parameters pertaining to the owner host, who announced the mobility event. This allows both end points of a mobility session to exercise mobility-related signaling handshakes with temporal overlap.
To protect mobility-related signaling, we assume that all mobility-related events require at least a 2-way handshake, consisting of Request 120, 122 and Reply 124,126 messages, which we refer to as a Binding Update (BU) exchange. The request 120, 122 is sent by the MA owner to announce addition, deletion or change of an IP address. The request 120, 122 is acknowledged by the peer in the reply 128, 130. Such handshakes are generally in compliance with host-based mobility protocols.
In order to protect against DoS, or flood attacks, and session hijacking, the sender of the BU request 120, 122 must assert ownership of the MA, i.e. the end point of the mobility session. This is equivalent to establishing that a host owner has generated and sent all prior MA-related requests, and received all prior MA-related replies, including the initial INIT exchange messages 112, 114.
The host owner authenticates the request by revealing a secret related to a previous request. This will create a “chain of proof” that the host owner is in fact the same sender. The secret can be a cryptographic hash over a random number R generated in every request.
The host owner signs the request with a symmetric authentication key, which is updated by the peer (i.e., CN) in every reply message. This proves that the host has received all prior replies. In this manner the messages are interlinked, which provides the security of the system. Interlinking the messages proves that the sender of the i-th message is identical to the sender of the first message of a session.
The MN 210 generates and caches an MA identifier MID at 230. The MID 230 can be a random number. The MN 210 also generates and caches a random number, or nonce R0 at 240. The MN 210 then sends the request MID, Hash(R0), 250, to the CN 220. The CN caches R0 at 260. CN then generates and caches a random key A0 at 270. The CN then sends the MID and the random key A0, openly, to the MN 210. The MN 210 then caches A0.
Both R0 and A0 must be random numbers. Since the MN only sends Hash(R0), an adversary eavesdropping on the message is not able to guess R0 itself. The corresponding hash function can be any suitable hash function, such as, for example, SHA1, SHA256, or any other suitable hash function. Note that the peer openly returns the initial key A0. In this manner, MN proves in every message that it sent the prior message.
The MID allows a node to recognize the sending peer as well as the mobility session even when the message arrives from a different IP address. In the current scenario, one MID is introduced per MA. It is also possible to simply use one common MID per mobility session. Mobility and multi-homing protocols typically include such a property.
As illustrated in
The index i-1 refers to the previous BU or to INIT for i=1. The BU handshake also contains parameters relevant to the mobility event, such as the MN's new IP address, for instance, which depend on the specific protocol implementation, as is shown below with respect to
Referring to
As illustrated generally at 300, a binding update (BU) handshake uses parameters gained by the initial handshake of
The CN 330 then caches Hash of a new random nonce, Ri at 360. This allows MN to repeat the proof in the following KU handshake. Only an active attacker can overcome the hash protection chain, since a passive attacker cannot compute nonce Ri. The CN 330 generates a random key dA at 370, and caches Ai=Ai-1+DA at 380 The CN only forwards dA in the next operation, such that MN receives the increment.
CN 330 can then send a reply, such as, for example, MID, dA, HMAC(Ai-1|MSG), shown at 390 to the MN 310. The MN 310 can then cache Ai=Ai-1+dA at 395. Since CN only forwards an increment of the random key to MN, an attacker must be present all the time during the session to get all the messages, or has to know what the key is. The index i-1 refers to the previous key update, or to the MA establishment if i=1.The Ri-1, Hash Ri sequence ensures that a linked chain in time is established, which proves MN is the sender of all prior messages.
In order to break the protection of a security mechanism or linked chain, illustrated in
MN also signs each key update sent to CN with the key Ai-1, wherein the base key A0 is sent by CN to MN during MA establishment. The key update combined with the Ri-1, hash Ri sequence provides proof to CN that MN established the MA.
As illustrated in
The chain of BU handshakes provides an even higher level of protection since the attacker has to be present for the entire session, or time frame since INIT, and, further, must wait for a legitimate BU Request issued by the MN.
The CN's reply is further singed by the updated key Ai-1. This HMAC does not provide any additional security in case an attacker has broken key A and rewritten Hash(Ri). However, it allows the MN to mitigate DoS attacks onto the MA itself. That is, without the HMAC, a transient attacker could easily break the mobility connection by sending an arbitrary key update.
In the event that one of the above BU messages fail, the BU handshake is not complete. In this case, the MN should retransmit the BU. The retransmitted message should be an exact copy of the prior message. In the event that the CN did receive the prior message but the reply was lost, the CN realizes that the Hash(R)-value contained in the retransmitted message is the same as the value it already holds. This allows the CN to distinguish between a new BU messages and a retransmitted BU message. The CN should respond to retransmissions with the same dA it sent in the prior reply. For this purpose, the CN has to cache dA for period of time after a reply was sent.
The above BU exchange is also protected against replay attacks, since every BU contains a new secret, and the solution is unknown to the adversary. In the event that the adversary replays a BU request hoping that the CN accepts it as a retransmission, the CN can detect the content mismatch between a replayed and an original BU request, and discard the replayed message.
Since the HMAC merely serves as a proof for the MN to assert its knowledge of key Ai-1 it does not have to cover the entire content of the BU request. This is important for BU requests sent from behind network address translators (NAT), where the packet's source address is changed by the NAT and the CN has to take MN's new IP address from the packet header itself. The present security solution is therefore compliant with NATs.
In the event that both hosts of the mobility session are mobile, each host can be configured to support their own MA, wherein the initial handshake can still be embedded into a 2-way message exchange as illustrated, for example, in
As illustrated generally at 500, each host can generate and cache a random nonce and a random key, such as, for example a host 1510 and a host 2520. The host 1 can generate random nonce 530 and random key 540 and send at 550 to host 2520. Host 2520 can then cache the nonce and the key from host 1 at 560 and 570, respectively. Host 2 can then generate a second random nonce 580 and second random key 590 and send to host 1510 at 595.
The respective parameters for R10 and A10 of Host 1's MA are R20 and A20 for Host 2's MA. Host 1 proactively passes A20 in the INIT request, assuming that Host 2 is mobile. In the event that Host 2 is not mobile, it simply ignores this parameter and proceeds as shown in the prior INIT exchange above. Otherwise, it exercises all operations and passes parameters, such as the parameters illustrated in
Since IP addresses do not occur symmetrically, the binding updates are individually processed for each host over their respective MA, whereas the key exchange can occur symmetrically. Further, if sequence numbers are used for the BU's, each MA must support its' respective sequence number. In addition, the two MA's can share the same MID. The resulting handshakes can be shown in an embodiment, for example, of
When an adversary uses mobility signaling to conduct flood attacks, securing BU messages provides no defense against the attack, since the adversary himself establishes the mobility session. Therefore, an additional security mechanism is needed. Preferably, the additional system uses a simple routability test, such as the binding test (BT) illustrated in
Assuming that MN is the host holding the MA, the BT handshake is initiated by the CN whenever the MN announces a new IP address. It has to involve MN's new address even if the BU request was sent from the old address. Where the CN sustains multiple IP addresses, it would be sufficient to use only one of them for the routability test, since this ensures that the MN can be reached at the new location. There may be technical reasons to conduct routability tests from all of the CN's IP addresses to the MN's new address. For example, such a procedure may determine availability of certain paths.
The routability test involves a challenge sent by the CN to the MN, shown generally at 600. The CN 610 sends the challenge which must be answered in a response by the MN 620. The CN 610 has to ensure completion of the BT handshake before it sends larger amounts of traffic to the MN's 620 new IP address.
The hosts 1 and 2 can be any suitable hosts. For example, where both hosts 1 and 2 are mobile, the hosts can be suitable mobile devices, such as, for example, a server, laptop, PC, smart phone, television, pda, gaming device, push-to-talk device, and peripheral device.
The BT handshake can be embedded into the BU handshake, as illustrated in
Additionally, the MN should embed an MA key update handshake into all data exchanges with the CN. The key update of the index i can include, for example, embedding the key update into the binding update, as illustrated in
In accordance with the principles herein, the MS can only provide host-based mobility security for connections established during or after the MA establishment. As a result, MN and CN have to hold a table for each MA that specifies connections that can be migrated underneath an MA. In the table, the connections can be specified in a suitable manner, such as via a 5-tuple including {protocol type, source IP, address, destination address, source port number, destination port number}. Connections sustained between MN and CN prior to establishing MA do not get added to the table, only new connections after MA is established.
In accordance with the principles herein, it is possible to have a one-to-one mapping between a traffic connection(s) and MA or an MA pair. In this instance, all information associated with MA or MA pair can be held in the protocol control block of the traffic connection, and therefore a connections table would not be needed.
Additionally, all non-security related messaging can be piggy-backed onto the KU and BU handshakes in the MA, such as policies or IP addresses designated for a subset of connections, or other related information.
As illustrated in
Inter-host signaling can be carried out via a suitable method, such as, for example, UDP. A new protocol type could also be introduced for this purpose, as was done for HIP, for example. Further, the messages can be multiplexed into the traffic connections via packet header as proposed, for example, with TCP migrate.
All of the embodiments set forth herein include principles achieved via a system and method adapted and constructed to operatively facilitate secure communication between communication devices, such as computers, cell phones, pda's, televisions, and the like. As such, each exemplary system or method herein contemplates the operative connection of signals to a communication, wireless, or other network over which encryptions are capable of being transmitted between communication devices.
The embodiments herein have been described and shown for purposes of illustration only, and are not to be construed as constituting any limitations of the present principles. Modifications will be obvious to those skilled in the art, and all modifications that do not depart from the spirit of the principles herein are intended to be included within the scope of the appended claims. Those skilled in the art will appreciate that the conception upon which this disclosure is based, may readily be utilized as a basis for the designing of other structures, methods and systems for carrying out the several purposes of the present principles.
Therefore, the foregoing is considered as illustrative only of the principles herein. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the principles to the exact construction and operation shown and described, and accordingly, all suitable modifications and equivalents may be resorted to, falling within the scope of the principles described herein.
