GB2424154A - Streamlined network logon using Host Identity Protocol (HIP) with broadcast puzzle challenges and home server certificates - Google Patents

Abstract

HIP associates with a node a public key which does not change with location on the network, unlike IP addresses. It is primarily intended for node to node authentication but made be used to authenticate a node to a visited network. Basic authentication has four steps (see Fig. 2) initiate, random number challenge, response and authentication from the initiator and responder alternately. Applied to network logon this corresponds to Fig. 3 steps 1-4 and is followed by the visited authentication server (AAA) verifying the mobile node (MN) with the MN's Home AAA, steps 5-8. The invention proposes including the (HIP) random number challenge in the access point's (AP) broadcast network advertisements (1) and sending Home AAA verification information in a signed certificate (4.5) without awaiting the final authentication message in the HIP cycle (5). These changes establish secure authentication with less network traffic and downtime experienced when migrating to a new network.

Description

Optimised Host Identity Protocol Authentication When the Internet was

originally devised, hosts were fixed in location and there was implicit trust between users despite the lack of real security or host identification protocols, and this situation continued even upon wider uptake and use of the technology. There was little need to consider techniques for dealing with host mobility since computers were relatively bulky and immobile.

With the revolution in telecommunications and computer industry in the early 1990's, smaller communication equipment and computers became more widely available and the invention of the World Wide Web, and all the services that emerged with it, finally made the Internet attractive for the average person. The combination of increasing usage of the network and mobile telecommunications created the need for secure mobility management in the Internet.

The increasing number of involved parties, and the monetary transactions that were needed for certain services, also created a need for added application level security.

Currently, the most widely used encryption protocols, for example SSL/TLS, are running within the upper network layers, for example TCP.

Taking into account the above mobility management and security issues, the Mobile IP standard (C. Perkins, "IP Mobility Support for IPv4", RFC 3220, IETF, 2002) and the Mobile IPv6 standard (D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", RFC3775, IETF, 2004) have been introduced. Together these specifications are planned to provide mobility support for the next generation Internet. Security work is developing in the form of IPsec, and related activities, such as various key exchange protocols, with the aim being to provide security in the IP layer. However, experience has shown that it is fairly hard to reach combined security and mobility using the current standards.

An IP address describes a topological location of a node in the network. The IP address is used to route the packet from the source node to the destination. At the same time the TP address is also used to identify the node, providing two different functions in one RL P53416GB entity. This is akin to a person responding with their home address when asked who they are. When mobility is also considered, the situation becomes even more complicated: since IP addresses act as host identifiers in this scheme, they must not be changed; however, since IP addresses also describe topological locations, they must necessarily change when a host changes its location in the network. Clearly, it is impossible to achieve both stability and dynamic changes at the same time.

In the case of Mobile IP, the solution is to use a fixed home location providing a "home address" for the node. The home address both identifies the node and provides a stable location for it when it is at home. The current location information is available in the form of a care-of address, which is used for routing purposes when the node is away from home.

Another solution to the problem is to separate the identification and location functions from each other, and this is the approach taken in the Host Identity Protocol (HIP) proposal (R. Moskowitz, P. Nikander, P. Jokela, "Host Identity Protocol", Internet Draft, work in progress, draftietf-hip-base-0l, IETF, 2004). HIP separates the location and identity roles of IP addresses by introducing a new name-space, the Host Identity (HI). In HIP, the Host Identity is basically a public cryptographic key of a public- private key-pair, and is generated from and linked to the private key. The public key identifies the party that holds the only copy of the private key. A host possessing the private key of the key-pair can directly prove that it "owns" the public key that is used to identify it in the network. The separation also provides a means to handle mobility and multi-homing in a secure way.

The I-lost Identity Protocol introduces a separation between the location and identity information at the IP layer. In addition to the separation, a protocol is defined to negotiate security associations (SAs) between HIP-enabled nodes.

With HIP, each host has one or more identities, which can be long-term or short-term, that can be used to identify it in the network. With HIP, an identifier is the public key of a public-private key pair. When the host possesses the private key, it can prove that it actually "owns" this identity that the public key represents; this is akin to showing an IDcard.

RL P53416GB Each host can generate short-term keys to be used only for a short time. These are useful when it is not necessary for the node to be identified with the same identity later.

For example, buying books from a bookstore may be a long-term relationship, while contacting a server once to collect user profiles may be considered to be a short-term action. In the latter case a short-term identity can be created to avoid more widespread dissemination of the long-term identity.

The HIP Host Identity (HI), being a public key, can be quite long and is therefore not practical in all situations. In HIP, the HI is represented with a 128-bit long Host Identity Tag (HIT) that is generated from the HI by hashing it. Thus, the HIT identifies a HI. Since the HIT is 128 bits long, it can be used for lPv6 applications directly as it is exactly the same length as IPv6 addresses.

Another representation of the Host Identities is the Local Scope Identifier (LSI), which is a 32-bit representation for the Host Identity. The purpose of the LSI is to facilitate using Host Identities in existing protocols and APIs. For example, since the LSI is the same length as an IPv4 address, it can be used for lPv4 applications directly. Although much of the remainder of this description will be based around the use of the longer HIT, it will be appreciated that the same or similar considerations apply to the alternative LSI representation.

When HIP is used, the upper layers, including the applications, no longer see the IP address. Instead, they see the HIT as the "address" of the destination host. The location information is hidden at a new layer, to be described below. The IP addresses no longer identify the nodes; they are only used for routing the packets in the network.

Applications are not typically interested in location information but do need to know the identity of their peers. The identity is represented by the HIT. This means that the IP address only has importance on lower layers where routing is concerned. The HITs, which the applications use, must be mapped to the corresponding IP addresses before any packets leave the host. This is achieved in a new Host Identity Layer as described below.

RL P53416GB Figure 1 of the accompanying drawings illustrates the various layers in HIP, comprising the standard transport layer 4, network layer 8 and link layer 10, with a process 2 communicating with the transport layer 4 below it. With HIP, a new Host Identity Layer 6 is disposed between the transport layer 4 and the network layer 8.

Locally, each HI and its associated HIT are mapped to the IP addresses of the node.

When packets are leaving the host, the correct route is chosen (by whatever means) and corresponding IP addresses are put into the packet as the source and destination addresses. Each packet arriving from the upper layer contains the HIT of the peer as the destination address. The mapping between the HIT and the location information can be found at the HI layer 6. Hence, the destination address is converted to the mapped IP address, and the source HIT is converted to source IP address.

The mapping between a peer HIT and IP address can be retrieved in several ways, one of which being from a DNS server. The location information can be updated by the peer node any time. The update procedure will be discussed in more detail in the mobility management subsection.

HIP defines a base message exchange containing four messages, a four-way handshake, and this is used to create a security association (SA) between HIP-enabled hosts.

During the message exchange, the Diffie-Heliman procedure is used to create a session key and to establish a pair of IPsec Encapsulating Security Payload (ESP) Security Associations (SAs) between the nodes.

Figure 2 of the accompanying drawings illustrates the operation of the four-way handshake. The negotiating parties are referred to as the Initiator, starting the connection, and the Responder. The Initiator begins the negotiation by sending an I 1 packet that contains the HITs of the nodes participating in the negotiation. The destination HIT may also be zeroed, if the Responder's HIT is not known by the Initiator.

When the Responder gets the 11 packet, it sends back an RI packet that contains a puzzle to be solved by the Initiator. The protocol is designed so that the Initiator must do most of the calculation during the puzzle solving. This gives some protection against RL P53416GB DoS attacks. The Ri initiates also the Diffie-Heilman procedure, containing the public key of the Responder together with the Diffie-Heliman parameters.

Once the Ri packet is received, the Initiator solves the puzzle and sends a response cookie in an 12 packet together with an IPsec SPI value and its encrypted public key to the Responder. The Responder verifies that the puzzle has been solved, authenticates the Initiator and creates the IPsec ESP SAs. The final R2 message contains the SPI value of the Responder.

HIP has been designed as an end-to-end protocol to allow, e.g. mobile terminals, to authenticate one another and to establish a secure communication channel. The existing proposals assume that some other protocol would be used to authenticate a party to an access network. E.g. In the case of a mobile terminal using a 3G access network, a party might be authenticated using the AKA protocol. More recently however, it has been proposed to use HIP as the authentication protocol between a subscriber terminal and an access network. The basic HIP authentication is not yet enough because the access network is not aware of the home operator of the mobile node. The mobile host must provide some information about the home network so that the visited network can create an accounting session.

In a typical access network, an access point or "router" may broadcast advertisement messages to listening user terminals. This is an address autoconfiguration message. A user terminal in receipt of this message can then initiate the four message sequence HIP negotiation described above (and shown in Figure 2). The router merely routes these messages between the user terminal and an authentication server of the access network.

At the end of this sequence, the authentication server knows the true identity of the user terminal. The user terminal then informs the authentication server of the identity of its home network. For a roaming subscriber, the authentication server can then contact an authentication server of the subscriber's home network. The full signalling procedure is illustrated in Figure 3, where the numbered steps are as follows: I. The MN receives address autoconfiguration message from the network (or DHCP offer) and configures the connected interface.

2. The MN sends I-HP 11 message to initialize the HIP negotiation with the access RL P53416GB network. This is required for end-host authentication. (The AP can pass HIP packets destined to itself to the local AAA server).

3. The AAA server responds with an RI 4. 12 from the MN 5. R2 finalizes the HIP negotiation and a HIP association is created between the visited AAA server and the MN. The visited AAA server now is aware of the identity of the MN.

6. The MN provides information about its home operator 7. The visited AAA server contacts the home AAA server (there must be a trust relationship between the home network and the visited network and a HIP negotiation between the visited network and home network may have to be performed. In usual case, there exists already a HIP association between the AAA servers) 8. The home AAA server gives either positive or negative answer to the authorization request and the visited AAA server can now either allow or deny the network access from the MN.

This approach is not optimal, and a user can perceive significant delays in service provision. In particular, when a mobile node changes access network, multiple messages must be sent to configure and authenticate the host before it can access the new network. This introduces a period of time during which the mobile node cannot send or receive data.

It is an object of the present invention to overcome the disadvantages of the current HIP proposals when applied to access network authentication. This is achieved by eliminating messages I and 2 of the HIP negotiation, and including the puzzle (or challenge) in the initial (broadcast) router advertisement.

According to a first aspect of the present invention there is provided a method of establishing a security context between a mobile node and an access point of an access network, each of the mobile node and the access point being identified by at least one Host Identity according to the Host Identity Protocol, the method comprising: sending from the access point to the mobile node an access advertisement or offer, this message containing at least an access network public key, Diffie- Hellmann initiation parameters, and a challenge; RL P53416GB at the mobile node, generating a response to said challenge, and sending the response, a public key of the mobile node, a Security Parameter Index identifying a Security Association of the security context, and a signed certificate, to an authentication server associated with the access point; and at said authentication server, verifying said response and authenticating the mobile node, and sending to the mobile node a Security Parameter Index identifying a Security Association of the security context.

In the case where the mobile node is roaming in a "foreign" network, the mobile node may send home operator information to the authentication server, to allow the access point to identify the home access network server.

In a preferred embodiment of the invention, home operator information may be sent to the access network at an early stage. This can be sent in a (HIP) CER packet, immediately after the sending of the 12 message from the mobile node to the authentication server.

According to a second aspect of the present invention there is provided a method of establishing a security context between a mobile node and an access point of an access network, each of the mobile node and the access point being identified by at least one Host Identity according to the Host Identity Protocol, the method comprising: sending a challenge from the access network to the mobile node; at the mobile node, generating a response to said challenge, and sending the response, a public key of the mobile node, a Security Parameter Index identifying a Security Association of the security context, and a signed certificate, to an authentication server associated with the access point; sending a certificate from the mobile node to the authentication server, the certificate identifying the mobile host's home operator; and subsequently, at said authentication server, verifying said response and authenticating the mobile node, and sending to the mobile node a Security Parameter Index identifying a Security Association of the security context.

This second aspect of the invention further reduces the time necessary to authenticate the mobile node to the access network. It may also facilitate very early service RL P53416GB provision to the mobile node.

Compared to the basic HIP solution, the optimized solutions presented here allow the mobile node to authenticate itself faster to the access network and enable faster handoff times. The visited network may allow the end-host to use the access network even though the authorization and authentication have not yet been fully accomplished with the home operator.

Other aspects of the present invention include a mobile node arranged to establish a security context with an access point of an access network according to the first and second aspects of the invention, an access point, and an authentication server.

For a better understanding of the present invention and in order to show how the same may be carried into effect reference will now be made to the accompanying drawings, in which: Figure 1, discussed hereinbefore, illustrates the various layers in the Host Identity Protocol; Figure 2, also discussed hereinbefore, illustrates the operation of the four-way handshake in the HIP protocol; Figure 3 illustrates the operation of the four-way handshake in the HIP protocol modified for use in authenticating a mobile host to an access network; Figure 4 illustrates an optimised procedure for employing the HIP protocol to authenticate a mobile host to an access network; and Figure 5 illustrates a further enhancement to the procedure of Figure 4.

A mobile host accessing a visited network must authenticate itself to the network before it can use the access network. The visited network must be able to get money for the usage of the network, and one way to do this is to let the money "flow" via the home network. Thus, the mobile host must be able to provide some information to the visited RL P53416GB network so that the visited network can authenticate the user by contacting its home network and agree with the home network about the appropriate accounting procedure.

A more optimal solution than the basic HIP procedure (illustrated in Figure 3) is to allow the address configuration message (= router advertisement or DHCP offer) to contain an embedded Rl message from the authentication server of the visited network.

The MN does not have to send an Ii (msg no. 2), but it receives the Ri already in the beginning (msg 1 containing also 3.) and it can continue directly with puzzle solving and the sending of the 12 message (msg 4). This optimised procedure is illustrated in Figure 4, where: 1. Address autoconfiguration or DHCP offer containing embedded Ri message (3) 4. 12 message 5. R2 message; end-host authentication finalized 6. Home operator information 7. & 8. Authorization req/resp as in basic scheme.

The procedure described with reference to Figure 4 can be further optimised as is illustrated in Figure 5. The requires that the mobile host send the home operator information in the form of a certificate after the 12 packet (msg 4), as a CER packet (msg 4.5), as defined in the HIP base protocol. (The CER packet is intended for transferring certificates between hosts in HIP.) There are two ways to create this certificate: 1) The certificate is created by the mobile node, containing information about the home AAA server. The visited AAA can use this certificate (signed by the MN) and the end-host's public key as the information to request the accounting and authorization from the home AAA 2) Thc certificate is created earlier by the home AAA server, containing the signature of the home AAA. The MN further delegates the certificate and signs it before sending to the visited AAA. The AAA can verify that the certificate has indeed been given by the home AAA to the MN and that the MN has itself signed it.

(Note: the visited AAA has the public key of the home AAA because they must have a trust relation between them.) RI. P53416GB Alternative 2) allows the visited AAA server to open the data access already when the CER packet is received (before messages 7, 5 and 8), thus shortening the end-host's break in data transmission (changing the location would still create an additional delay for existing connections because the peer host must also be signalled about the changed [P address). This, naturally, introduces a small risk for the visited operator if the home AAA does not accept the access. The risk may be acceptable, because the visited AAA knows that there is a business relation between the MN and the home AAA.

Claims (2)

1. RL P53416GB ii Claims 1. A method of establishing a security context

   between a mobile node and an access point of an access network, each of the mobile node and the access point being identified by at least one Host Identity according to the Host Identity Protocol, the method comprising: sending from the access point to the mobile node an access advertisement or offer, this message containing at least an access network public key, Diffie- Hellmann initiation parameters, and a challenge; at the mobile node, generating a response to said challenge, and sending the response, a public key of the mobile node, a Security Parameter Index identifying a Security Association of the security context, and a signature, to an authentication server associated with the access point; and at said authentication server, verifying said response and authenticating the mobile node, and sending to the mobile node a Security Parameter Index identifying a Security Association of the security context.
2. 2. A method of establishing a security context between a mobile node and an access point of an access network, each of the mobile node and the access point being identified by at least one Host Identity according to the Host Identity Protocol, the method comprising: sending a challenge from the access network to the mobile node; at the mobile node, generating a response to said challenge, and sending the response, a public key of the mobile node, a Security Parameter Index identifying a Security Association of the security context, and a signature, to an authentication server associated with the access point; sending a certificate from the mobile node to the authentication server, the certificate identifying the mobile host's home operator; and subsequently, at said authentication server, verifying said response and authenticating the mobile node, and sending to the mobile node a Security Parameter Index identifying a Security Association of the security context.