TOKEN-BASED DISTRIBUTED GENERATION OF SECURITY KEYING

MATERIAL

FIELD OF THE INVENTION [0001] This invention relates generally to the field of computer networks. More particularly, this invention relates to the generation and passing of security keying material in a network.

BACKGROUND

[0002] In a network with a security architecture, a mobile entity (ME) (also called a mobile node, a user or a client) gains access to computer resources on the network via an edge device (ED), such as a base station, network access server, network access point, access router, or base router. Access to the network is often controlled by an authentication, authorization, and accounting (AAA) framework that, in addition to controlling access to the network, controls policy enforcement, auditing usage, and provides the information necessary to bill for services.

[0003] Many new security architectures, such as those described in IEEE 802. IX standards (802.1 Ii and the emerging 802.16, for example), combine the initial authentication and access control with key management. IEEE standard 802. IX is an example of a network access control standard. The control, which is used predominantly in Wi-Fi wireless networks, keeps a network port disconnected until

authentication is completed. Depending on the results, the port is either made available to the user, or the user is denied access to the network.

[0004] The initial mutual authentication is a very lengthy process involving many round trips between the mobile entity and a central AAA server through the edge device. The edge device and the mobile entity do not trust each other initially. The initial authentication leads to a master key (often called AAA-key) between the mobile entity and the AAA server that is unknown by the edge device. The master key is then ported to the edge device and is later used by the mobile entity and edge device to perform a mutual authentication (during which the two prove the possession of the master key) and a new handshake to derive the traffic encryption keys (TEK' s) used to protect link traffic.

[0005] In a network that supports mobility, the mobile entity may need to handover to a new edge device, such as a new base station, to receive better coverage. The new edge device is called the target edge device. The mobile entity must first perform mutual authentication and establish a TEK with the target edge device. In order to be able to expedite the handover procedure, it is desired to eliminate the full authentication process. If the mobile entity and the network prove that they still hold the master keys, the new traffic encryption keys can be generated very quickly without going through the full authentication process. However, the target edge device would still need access to the master key to start the TEK exchange with the mobile entity. Since many handovers are possible and hence many edge devices can be involved, it is not wise to send the initial master key (AAA-key) to the edge device as this would compromise the security of both the network and the user if one edge

device is compromised (stolen or loaded with Trojan horses). Thus, instead of sending the AAA key to edge device, it has been suggested (for IEEE standard 802.16e, for example) that an edge device specific key (called a pair-wise master key, PMK or AAA-BS key) be created for the edge device. Although the PMK is a derivative of the AAA-key, the AAA key cannot be recovered from the PMK so security is not compromised. The mobile entity is familiar with the derivation process and can arrive at a PMK for the edge device it is moving to. Once the PMK is moved to the edge device, the mobile entity can start a new TEK handshake with the edge device. Since each edge device receives its own copy of the master keys, neighboring edge devices cannot derive the TEKs and thereby interpret user's traffic.

[0006] However the issue with this more secure approach is how to get the PMK to each target edge device in a timely manner either prior to or during handovers. This means, for example, that the AAA server must mediate every time the mobile entity needs to establish trust with a new edge device. This is time consuming since it involves round trips to the AAA server. It also consumes AAA CPU bandwidth, since the AAA server must be involved in every handover. Sending keys proactively to the edge device also has disadvantages, since it requires that the AAA server has a database of neighboring edge device and needs to push the keys to the target edge device proactively (which is a problem for the RADIUS protocol).

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as the preferred mode of use, and further objects and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawing(s), wherein:

[0008] FIG. 1 is a diagrammatic representation of a network consistent with certain aspects of the present invention.

[0009] FIG. 2 is a flow chart of a method for issuing authorization tokens consistent with certain embodiments of the present invention.

[0010] FIG. 3 is a flow chart of a method for distribution of keying material consistent with certain embodiments of the present invention.

[001 I] FIG. 4 is a diagrammatic representation a method for distribution of keying material consistent with certain embodiments of the present invention.

DETAILED DESCRIPTION

[0012] While this invention is susceptible of embodiment in many different forms, there is shown in the drawings and will herein be described in detail one or more specific embodiments, with the understanding that the present disclosure is to be considered as exemplary of the principles of the invention and not intended to limit the invention to the specific embodiments shown and described. In the description below, like reference numerals are used to describe the same, similar or corresponding parts in the several views of the drawings.

[0013] FIG. 1 is a diagrammatic representation of a network consistent with certain aspects of the present invention. Referring to FIG. 1, the network 100 includes a token issuing server 102, a mobile entity 104, and one or more network service functions 106, 106'.

[0014] The token issuing server 102 may be an Authentication, Authorization, and

Accounting (AAA) Server, a Key Distribution Center (which can include an authenticator), a Network Access server, a Home Location Register, an

Authentication Center, an Extensible Authentication Protocol (EAP) authenticator, a

Home Subscriber Server, or similar device.

[0015] The mobile entity 104 is also called a mobile node, a user or a client.

Examples of mobile entities include cellular telephones and mobile Internet devices. [0016] A network service function 106 is an entity such as a base station, network access point, access router, mobile IP agent, base router, Virtual Private Network

(VPN) gateway, key distribution center, Session Initiation Protocol (SIP) agent,

authenticator, edge device or second mobile entity) with which the first mobile entity communicates.

[0017] In previous networks, the process of security key material generation is performed by a centralized resource such as an AAA server or a Key Distribution Center. This can result in slow response as a network increases in size.

[0018] In accordance with certain embodiments of the invention, the key material generation is delegated to a mobile entity 104 of the network. This reduces the processing burden on the centralized resource and speeds the response of the network.

[0019] The mobile entity 104 generates keying material for use by a network service function 106. In order to enable the mobile entity to prove that it is authenticated and authorized to generate this material, the mobile entity is issued with an authorization token. This token 108 is issued by the token issuing server 102.

[0020] In one embodiment, the one or more network service functions 106, 106' may also be issued with authorization token 110, 110' to enable the network service functions to prove that they are trusted by the token issuing server.

[0021] When the mobile entity 104 exchanges messages with the network service function, the mobile entity 104 also sends its authorization token 114 to the network service function 106. The network service function 106 checks the authorization token, and, if it is found that the token authorizes the mobile entity to generate the keying material, the keying material is accepted. Otherwise, the keying material is rejected. An error message may be sent if the keying material is rejected.

[0022] In this embodiment, the network service function and the mobile entity exchange tokens. The mobile entity 104 examines the authorization token of the network service function to determine if the network service function is to be trusted.

[0023] It will be apparent to those of ordinary skill in the art that the structure of the authorization token may take many forms and may include various information fields. Example information fields include:

[0024] Issuee Identifier (ME_ID or NSF_ID): An identification string of the entity to which the token is issued. This may be the mobile entity (ME) or network service function (NSF). [0025] Issuer Identifier: An identification string of the token issuing server. This may be, for example, the identifier of the AAA server that issued the token. The issuer identifier allows for multi-operator authentication, by providing routing information for authentication and accounting data.

[0026] Policy Identifier: An identifier of what functions the mobile entity is authorized to perform and any associated rules. In one embodiment, the policy may define the type of the communication path and network service function that the authorization token can be applied to. For example, the link may be a cellular link, such as a 3G wireless link, an 802.11 link, or an 802.16 link. In a further embodiment the policy may define the type of network service function, such as a Mobile EP agent, a session initiation protocol (SIP) proxy or server, or an extensible authentication protocol (EAP) authenticator.

[0027] Token Validity Indicator: An indication of the conditions under which the mobile entity's authority to perform the delegated function will remain valid. This may be provided in the form of a time stamp and lifetime, for example.

[0028] Signature: A digital signature of the issuing entity. This may be, for example, an encrypted version of the other fields or an encryption of hash of other fields. The encryption may be performed using the private encryption key of the token issuing server or a key shared between the entity issuing the token and the entity verifying the token.

[0029] In one embodiment, in which the token issuing server is an AAA server, the authorization token for a mobile entity is described by the formula: token = <ME_ID , token_time_stamp , token_lifetime , Policy_ID,

E(AAA_private_key, ME_ID | token_time_stamp | tokenjifetime | Policy_ID)> where E(K,...) denotes encryption using the key 'K', or the signature of the AAA server.

[0030] In another embodiment the token issuer could be a certificate Authority and the token can use the standard X.509 format.

[0031] In yet another embodiments the token may be signed using a group key where in the group key is known only to a set of NSFs and the AAA server. The group key can be located by using the AAA ID and the SPI that is known to the NSFs. token = <A AAJOD, SPI, nonce, Hash(Group Key, AAA ID | SPI j nonce) [0032] In many embodiments the token may be signed using the private key of the token issuing server. The authorization token for a network service function may take

a similar form, with the network service function's device identifier (NSF_ED) taking the place of the mobile entity identifier (MELJD). More generally, the identifier will be the identifier of the token issuee, that it, the identifier of the entity to which the token is issued. [0033] The policy identifier may indicate if the holder of the token is authorized to generate or to receive key material.

[0034] In the network shown in FIG. 1 the token issuing server issues the mobile entity 104 with an authorization token 108 following an initial authentication process. In an alternate embodiment the token may be pre-provisioned in the mobile entity. In any case the mobile will be issued with an authorization token 108.

[0035] A similar process may be followed for the issuance of authorization tokens (110 and 110') to other network service functions (106 and 106', respectively). The network service functions may receive the ME authorization token 108 as part of a message sent by the mobile entity or they may receive the token as part of a fetch procedure with a network server.

[0036] FIG. 2 is a flow chart of a method for authorization token issuance consistent with certain embodiments of the present invention. Following start block 202 in FIG. 2, a mobile entity is authenticated at block 204. At block 206, the token issuing server generates an authorization token for the mobile entity. The authorization token is used by the mobile entity to prove that is has the authority to generate keying material. The authorization token is issued to the mobile entity at block 208. At least some part of the token may be encrypted using the key issuing server's private encryption key. This enables the mobile entity to verify the source of

the authorization token. The network service function (which is assumed to be part of the trusted network) may be, for example, a base station or a network access point in a wireless network. A token for the network service function is generated at block 210 and issued to the network service function at block 212. The authorization token allows the network service function to prove to other devices in the network that it is trusted. The process terminates at block 214 when all authorization tokens have been issued and delivered to their intended recipient.

[0037] FIG. 3 is a flow chart of a method for authorization token use consistent with certain embodiments of the preset invention. Following start block 302 in FlG. 3, at block 304 a mobile entity sends its authorization token to a target network service function. The target network service function processes the authorization token to determine if the mobile entity is authorized to provide keying material. The authorization may consist of the NSF verifying the signature in the token using the public key of token issuing server. In another embodiment this process may consist of the NSF determining the group key, using an AAA identifier and a connection identifier contained in the token, and verifying the signature using the embedded key. If the mobile entity is not authorized to provide keying material, as indicated by the negative branch from decision block 306, the process terminates at block 308 (an error message may be sent). If the mobile entity is authorized to provide keying material (that is, if the token is accepted), as indicated by the positive branch from decision block 306, the network service function accepts the keying material at block 310. The key provided by the ME may be fully or in part generated by the ME itself or obtained from a network server such as AAA server or pre-provisioned in the

mobile. The keying material is used to secure the communication path from the network service function. At block 312, the network service function sends its authorization token to the mobile entity. At decision block 314, the mobile entity processes the token and determines if the network service function is to be trusted. If not, as indicated by the negative branch from decision block 314, the process terminates at block 316. If the network service function is to be trusted, as indicated by the positive branch from decision block 314, the mobile entity and the network service function exchange traffic encryption keys at block 318. Finally the process terminates at block 320. [0038] One application of the present invention relates a method for decentralized and distributed generation of keying material for the handover between base stations (BS 's) in a mobile network. However, keying material may be generated for other applications, such as for communication between a mobile entity and other network service functions (such as an access router, Mobile IP Agent, authenticator, key distribution center, SIP agent, VPN gateway or another mobile entity). Previously, the handover process required the new base station (the target base station) to obtain a master key from the AAA server or from a neighborhood key distributed center. However, the handover procedure is expedited if the mobile entity and the NSF can establish a secure communication path with each other without contacting the AAA server. This avoids having to perform the full authentication process with the AAA server at each handover. As part of the handover process, new traffic encryption keys (TEK' s) are generated quickly.

[0039] As long as the AAA key that the mobile entity created during the initial full authentication with the AAA server is still valid, the mobile entity can create the AAA-BSt key before a handover to the target base station (BSt). Since no base station except the target base station should have access to the AAA-BSt key, the mobile entity encrypts this key with the public key of the target base station. The target base station decrypts the AAA-BSt key with its own private key. Now that both mobile entity and the target base station have the AAA-BSt key, they can start a TEK handshake to build the session keys.

[0040] However, it is important that the target base station be able to ensure that the mobile entity is a trusted mobile entity that has authenticated with the AAA server and is authorized to access the network. This problem is solved by the signed authorization token issued for the mobile entity by the AAA server. The authorization token shows that the owner that it is fully authenticated by the AAA server and is authorized by the AAA server to generate the AAA-BS key for any base station or other keys for other network authorities (specified by a policy). The key can be generated when needed by the mobile entity without the need for the AAA server to confirm the token. An example formulation of an authorization token is as follows: token = <MSED, AAAID , token time stamp , token lifetime , Policy ID ,

E(AAA private key, MSID J AAAID | token time stamp | token lifetime I Policy ID)>, where E(K,...) denotes encryption using the key 'K' or a signature of the AAA server. [0041] The encryption may be performed using an RSA algorithm, for example.

The AAAID (an identifier of the AAA server) is included to allow the base station to

determine whether it should trust the AAA server or the certificate authority (CA) that has generated the certificate for the AAA server. The AAAID is also useful for the base station to know where to send any accounting information relating the services the mobile has used. [0042] In this embodiment, the token does not include the actual AAA key, since the AAA key should not be known to any entity other than mobile entity and AAA server. Instead, the AAA server may include hints such as AAA life time and time stamp (mentioned as token life time and time stamp) in the token. This timing information is also useful to avoid the security and network management issues related to token expiration. In an alternate embodiment, the AAA server can create a derived key from AAA key and include that in encryption. In that case the token would be: token = <MSH>, AAABD, token time stamp , token lifetime , Policy ID,

Freshness value E(AAA private key, Hash(derived key, MSID | AAAID J token time stamp | token lifetime | Policy HD)>, where derived key= Hash(AAA key, MN_ID | Freshness value | "Derived Key"). The hash is a one way function such as SHAl. The freshness value is optional and may be a for instance a time stamp or a random number. If included the freshness value may already be known to the ME or provided to it by the AAA server. Note that in this embodiment, the AAA key is also part of process or deriving the token, but is not provided to the ME as part of the token itself. In one instance, the ME will need to provide the derived key also to the NSF thereby proving that it has the AAA

key. In another instance the AAA server can encrypt the derived key using a key it shares with NSFs and include it in the token. When the mobile sends a message it must use the derived key to obtain a keyed hash of the message. The NSF will then verify the hash by first obtaining the derived key and then verifying the hash there by confirming that the mobile entity has the AAA key.

[0043] The policy ID is an optional field that allows the AAA server to enforce a policy (understandable by the base station or other receiving entity) that indicates what sort of keys the mobile entity is allowed to generate and the scheme used to generate the token. Examples are technology-specific key material (as described in IEEE standards 802.16 or 802.11, for example), and application specific key material

(for Mobile Internet Protocol or Virtual Private Networks, for example). When sending the encrypted AAA-BS key to the target base station, the mobile entity includes its token, other information such as its identifier and timing information. If a derived key is needed then that is also sent to the target BS. It then signs this information (by encrypting it) with its private key or a key that can be generated from the AAA key (such as the AAA-BS key itself).

[0044] The keying material sent from the mobile entity to network service function, such as a base station, may be sent securely using the public key of the network service function or a shared key created through a Diffe-Hellman exchange with the network service function. The derived key may also be similarly protected. In some embodiments the key and the token are both sent encrypted.

[0045] Whenever an entity passes a token to another entity (mobile entity to NSF or vice versa), the sending entity needs to sign the message including the token to

avoid other mobile entities or NSFs misuse the token. The mobile entity signature on its token can prevent other mobile entities from stealing the token related to a mobile entity. Note that if another node replays the message, it will not have access to the keying material. Furthermore, the mobile entity can include a freshness value such as a timestamp or 'nonce' (a randomly chosen value, different from previous choices), to protect against replays.

[0046] Alternatively, the mobile entity can send any randomly generated key instead of the AAA-BS key to the base station (since the token allows the mobile entity to generate any key). [0047] It is desirable for the mobile entity to be able to determine if the base station is also an entity that is trusted by the AAA server. To facilitate this, in one embodiment the AAA server issues a token for each base station (at the time of base station initialization, for example) so that the base station can present the token to any mobile entity that arrives at the base station. In one embodiment, the base station token is calculated as:

TBS_token=BSID|AAAID| token time stamp| token lifetime| Policy ID|

E(AAA private key, BSID | A AAID | token time stamp | token lifetime! Policy ID).

In another embodiment, the BS may have a certificate issued by a trusted CA which is used to authenticate the BS to the ME.

[0048] The life time for the base station token can be different, typically much longer, than that for the mobile entity token. The base station may sign any sort of anti-replay data including the base station nonce that can be used for TEK generation

later. The token time stamp and token lifetime indicate the period of validity of the token.

[0049] The keying material distribution process described above is a completely distributed and decentralized approach controlled by the mobile entity. As long as both the base station and the mobile entity trust the AAA server, the mobile entity can provide handover keying materials that are trusted by the base station without the need for any reference to the AAA server. In certain embodiments at least part of key may be provided by the AAA to the MSS. The process preserves the integrity of each base station, while it does not assume that base stations share any keying material related to the mobile entity. It does not assume any trust relationship between base stations.

[0050] Other benefits of the approach are that it aids with network administration, such as accounting and reduces load on the AAA server while, at the same time, allowing for roaming to foreign AAA domains as long as AAAF (the AAA foreign agent) and AAAH (the AAA home agent) have trust and business relationships.

[0051] Keying material for multiple access technologies can be generated by the mobile entity (rather than from the AAA server) as long as the operator trust agreements exist.

[0052] The keying material available at the mobile entity may be used to create further keying material. For the example, the mobile entity may create child keys that are derived from the initial key or create fresh keys when a previous key expires. If the network service function is itself a key distribution center, the keying material generated by the mobile entity may also be used as a master key.

[0053] The keying material generated by the mobile entity may be used in the initial authentication process that is required for key exchange mechanisms such as those used for establishing an Internet Protocol Security (IPSec) VPN connection.

[0054] It will be apparent to those of ordinary skill in the art that keying material for many network applications, such as Mobile IP, VPN gateways and SEP proxies, can be created this way.

[0055] FIG. 4 is a diagrammatic representation a method for delegating the creation and distribution of keying material consistent with certain embodiments of the present invention. In this embodiment the token issuing server is an AAA server. Referring to FIG. 4, following authentication 402 of the network service function by the AAA server, the AAA server generates a token for the network service function and passes this token to the network service function at 404. Similarly, following authentication 406 of the mobile entity by the AAA server, the AAA server and the mobile entity both generate an AAA key at 408. The AAA server also generates an authorization token for the mobile entity and passes this token to the mobile entity at

410. The mobile entity is now authorized to create security keying material for the communication path between the mobile entity, a network service function and the network.

[0056] In one embodiment of the invention, the mobile entity and the network service function exchange tokens before security keying material is passed to the network service function. For example, the mobile entity may pass its authorization token to the network service function together with a request for the token of the network service function at 412. The network service function verifies the token and,

if the token is accepted, responds with its own token 414. If the mobile entity accepts the token, the creation and distribution of security keying material continues. In a different embodiment, the NSF may authenticate itself to the ME before the ME sends the token and in yet another they may happen in parallel. [0057] In a further embodiment of the invention, this exchange of token occurs with the passing of the keying material. The key and the mobile entity's token are sent to the network service function at 416. The mobile entity may use keys generated as part of authentication of the mobile entity to create the security keying material sent to the network service function. [0058] The ME-NSF MK key may be sent from the mobile entity to the network service function securely, using public key of the network service function or a shared key created through a Diffe-Hellman exchange with the network service function. The network service function verifies the authorization token and installs the received keying material for use in securing the communication path. The network service function responds with it own token at 418, allowing the mobile to verify that the network service function is trusted by the AAA server (if this was not done during a previous token exchange). At 420 the mobile network and the network service function exchange traffic encryption keys. Finally, at 422 and 424, the mobile entity can communicate with the AAA-server along a secure communication path using the keying material generated and distributed by the mobile entity.

[0059] It will be apparent to those of ordinary skill in the art that the methods described above, or variants thereof, can be used in other applications. For example, they may be used to provide peer to peer security in ah-hoc networks.

[0060] The methods described in embodiments herein, may be implemented using programmed processors executing programming instructions that can be stored on any suitable electronic storage medium. However, those skilled in the art will appreciate that the processes described above can be implemented in any number of variations and in many suitable programming languages without departing from the present invention. For example, the order of certain operations carried out can often be varied, additional operations can be added or operations can be deleted without departing from the invention. Such variations are contemplated and considered equivalent. [0061] While the invention has been described in conjunction with specific embodiments, it is evident that many alternatives, modifications, permutations and variations will become apparent to those of ordinary skill in the art in light of the foregoing description. Accordingly, it is intended that the present invention embrace all such alternatives, modifications and variations as fall within the scope of the appended claims.

What is claimed is: