GB2382281A

GB2382281A - Authentication or network users

Info

Publication number: GB2382281A
Application number: GB0126617A
Authority: GB
Inventors: Andrea Soppera; Robert John Briscoe
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 2001-11-06
Filing date: 2001-11-06
Publication date: 2003-05-21
Anticipated expiration: 2021-11-06
Also published as: GB0126617D0; GB2382281B

Abstract

A network includes a server 1 and a number of clients 2, some of which will in operation of the network require authentication by the server 1. The server 1 distributes authentication information to the clients 2 when a session is initialised. When the server 1 needs to authenticate a client 2, it hands out a server request to the client which asks the client for authentication information which it must obtain from other clients. The client being authenticated then sends these requests to the clients 3 specified in the authentication request to obtain the authentication information from those clients. Once the client to be authenticated has received the relevant authentication information from the other clients, it returns it to the server 1 and is authenticated or not accordingly.

Description

Authentication of Network Users The present invention relates to a method of and an apparatus for the authentication of users of a network.

It has particular application for IP (Internet Protocol) networks, but is equally applicable to other networks where a given network entity may wish to authenticate a second network entity (e. g. with which it is communicating).

It is common in networks for one user or entity on the network to wish to be able to authenticate another user or entity on the network. For example, two network users wishing to communicate with each other may first wish to authenticate the other user to confirm that they are communicating with a legitimate network user (and/or with who they think they are communicating with). A network server may wish to authenticate a client computer before, for example, granting the client computer communications access or resources on the network.

Any such authentication process must be able to confirm a legitimate user, but not be susceptible to a malicious user masquerading as a legitimate user ("spoofing").

Existing authentication procedures therefore typically involve encryption and the passing of passwords and/or encryption keys, etc, that should only be known to, or derivable by, legitimate users of the network.

However, the Applicants have recognised that in some cases it may not always be desirable to have to use cryptographic algorithms, passwords and stored cryptographic keys for authentication procedures. There therefore remains a need for an authentication process

that does not have to rely on, for example, encryption for its security.

According to a first aspect of the present invention, there is provided a method of authenticating an entity on a network used by plural network entities, the method comprising: a first network entity instructing the entity to be authenticated to obtain authentication information from one or more other network entities; the entity to be authenticated obtaining the authentication information from the other network entity or entities and sending that information to the first network entity; and the first network entity authenticating or not the entity to be authenticated on the basis of the authentication information it is sent.

According to a second aspect of the present invention, there is provided a network comprising: a first network entity comprising means for authenticating other network entities, including means for instructing a network entity to be authenticated to obtain and send to it authentication information from one or more other network entities and for authenticating or not the network entity to be authenticated on the basis of the authentication information it sends; and one or more other network entities each comprising means for storing authentication information and for sending that information to a requesting network entity.

The authentication procedure of the present invention involves the network entity being authenticated seeking authentication information from one or more further network entities. In other words, the authenticating network entity in effect uses one or more"third party"

network entities in the process to authenticate the entity to be authenticated. The authentication procedure is therefore a distributed one and involves more than just the authenticating network entity and entity being authenticated. It is therefore effectively "multi-end"-to-end, rather than the more usual "end-to-end"authentication processes where only the authenticating entity and the entity being authenticated are involved.

The advantage of using a distributed authentication process in the manner of the present invention is that the authentication process requires information from plural network entities, which information can therefore be requested and sent over many different paths in the network. This makes it more difficult for an attacker to be able to intercept ("sniff") all of the relevant authentication traffic to allow them to masquerade successfully as a legitimate user of the network. This makes the authentication process relatively secure, without the need to use, for example, further security measures such as encryption of authentication traffic or information and the use of passwords (which can therefore be avoided altogether, if desired). The invention in effect exploits the fact that the complex topology of typical networks will mean that authentication messages from different sources will follow diversified paths on the network, thereby making the interception of all the authentication messages difficult.

The invention also extends to appropriate apparatus for allowing network entities to operate the authentication procedure, and to network entities incorporating such apparatus. Thus, according to a third aspect of the present invention, there is provided an apparatus for a network entity comprising means for authenticating other

network entities, including means for instructing a network entity to be authenticated to obtain and send to the instructing network entity authentication information from one or more other network entities; and means for authenticating or not the network entity to be authenticated on the basis of the authentication information it sends.

According to a fourth aspect of the present invention, there is provided a method of operating a network entity, comprising the network entity instructing a network entity to be authenticated to obtain and send to the instructing network entity authentication information from one or more other network entities; and the instructing network entity authenticating or not the network entity to be authenticated on the basis of the authentication information it is sent.

According to a fifth aspect of the present invention, there is provided an apparatus for network entity comprising: means for receiving a request from another network entity for authentication information stored by another network entity or entities; means for, in response to such a request, seeking the authentication information from the indicated network entity or entities; and means for returning the authentication information to the requesting network entity.

According to a sixth aspect of the present invention, there is provided a method of operating a network entity comprising: the network entity receiving a request from another network entity for authentication information stored by another network entity or entities; the network entity in response to such a request seeking the authentication information from the indicated network entity or entities; and the network entity returning the authentication information to the requesting network

entity.

The network entities involved in the authentication process can be any suitable such entities. Typically, the entity doing the authenticating will be a controller entity of the network whose function it is desired to preserve and which, inter alia, monitors the network for malicious users. This entity could therefore, for example, be a server of the network. There may be a single such authenticating entity on the network or plural such entities, as desired.

The entity being authenticated (and the other entities from which authentication information is sought) can again be any suitable entities. They could for example, be clients or servers on the network. They would typically be client computers on the network.

The authentication information that is sought by the entity to be authenticated and is to be returned to authenticating network entity can be selected as desired. It should be such that the authenticating network entity can readily recognise valid authentication information. The authentication information therefore preferably comprises particular, preferably predetermined,"secret"information that is stored by the network entity from which it is sought (and which secret information is known to or can be derived or determined by the authenticating network entity). In a particularly preferred such embodiment, the secret authentication information comprises a random number of an appropriate length, e. g. 64 bits.

Preferably each network entity that stores secret information for use as authentication information stores different information to all of the remaining such network entities.

In a particularly preferred embodiment each piece of authentication information (e. g. stored predetermined secret information) is only valid for a limited, preferably predetermined, period of time, after which it can no longer be used for authentication (and therefore should be replaced with new, valid authentication information). This helps to enhance the security of the process.

Thus, preferably, the authentication information, e. g. stored secret information, is changed periodically, e. g. at regular, preferably predetermined, intervals. It could also or instead be changed on the occurrence of particular, e. g. predetermined, events. In a particularly preferred such embodiment, the rate of change of the authentication information can be varied, e. g. in accordance with predetermined criteria such as the current status or security of the network.

Preferably the rate of change (updating) of the authentication information is increased (i. e. such that the information is only valid for a shorter time period) if a threat to the network is perceived.

The authentication information, particularly where it comprises secret information stored by the network entities, must be distributed to those network entities at the appropriate time, e. g. at regular intervals, before the authentication procedure can take place.

The authentication information could be distributed by a single network entity (e. g. server) or by plural network entities, as desired. It is preferably distributed by a or the network entity or entities that will act as authenticating network entities, although this is not essential and there could, for example, be separate distribution and authentication entities if desired.

Thus a server could, for example, act only to distribute

authentication information, or act only to authenticate other network entities, or do both.

In a particularly preferred embodiment, the authentication information is distributed by plural network entities (e. g. servers). This helps, for example, to reduce the threat of an attacker being able to place a"sniffer"directly in front of a distributing network entity and thereby intercept all of the authentication information distributed in the network.

The authentication information can and preferably is distributed in plain text (i. e. without being encrypted). This is possible because as discussed above the present invention provides sufficient security that encryption can be unnecessary. Not using encryption simplifies the authentication procedure. However, it would be possible to distribute the authentication information in encrypted form (to hinder, e. g. , an attacker attempting to steal that information as it is distributed) and this can be used to further enhance security if desired. Where encryption is used, preferably an asymmetric encryption algorithm is used.

Although it is not necessary to distribute the authentication information in an encrypted form, it is preferred that the distributing network entity at least verifies the network entity that it is distributing the authentication information to. This again helps the security of the process. The authentication information distribution is preferably therefore a two-stage process, with the distributing network entity first verifying the recipient entity, and then, once it has verified the recipient entity, transmitting the authentication information (e. g. secret information) to the network entity.

The verification can be carried out as desired. It preferably is a process that requires a trust relationship between the two entities, and could, for example, therefore include an exchange of encryption keys or passwords off-line or via a secure channel.

In a particularly preferred embodiment, the verification is done using a token exchange, preferably a cookie-exchange, technique. This provides a relatively simple to execute verification process. In such an arrangement, each party (e. g. the server and other network entity) passes a token, preferably a"cookie", to the other party which token is then used to verify the message exchanges. Preferably, each entity generates a token (cookie) and passes it to the other entity, which then returns it. The returned token (cookie) is compared to the original and the network entity verified if there is a match. The token (cookie) is preferably returned in a modified, e. g. hashed, form.

Such an exchange acts as an"anti-clogging"technique and can help to, for example, guard against flooding attacks sent using bogus network sources.

The token (cookie) exchange is preferably stateless (i. e. does not require the storage of tokens) as far as possible, particularly for the distributing network entity (e. g. server). This helps to avoid, for example, resource allocation at the distributing network entity, etc. Thus, the distributing network entity (e. g. server) at least preferably regenerates its token (cookie) for comparison purposes when receiving the response from the other entity, rather than storing the token when it is first generated.

Once the token exchange is completed and the network entities verified, the authentication information can be distributed to the network entity. As discussed above

that information is preferably sent in plain text.

However, this message is still preferably sent in such a way that it can be verified, e. g. by modifying or masking it in some way. In a particularly preferred embodiment this is done by using one or more of the tokens (cookies) exchanged in the initial verification process.

The authentication information to be distributed is preferably generated using other secret information known only to the information generator (e. g. distributing server) and the current value of a time parameter at the time the information is generated.

A given authentication information distributing network entity will typically repeat the above process with many network entities so as to distribute authentication information to each such network entity.

Each authentication information receiving network entity stores the authentication information it receives.

Preferably, where the token exchange technique is used, these entities also store the token (cookie) sent to them during the authentication information distribution process by the distributing network entity for future use for, for example, verification of further authentication messages (this will be discussed further below).

It is also necessary for the authenticating network entities to know or be able to derive the currently valid authentication information for each network entity, and where appropriate, the verifying token or cookie, etc. , used for and/or sent to each entity. Thus preferably the relevant information, e. g. authentication information, tokens, etc. , or the information used to derive it (e. g. local secret information, network

addresses, time parameter when the information was derived, etc. ) is stored in the network where it can be accessed appropriately by the authenticating network entities. It is preferably stored by the or each authenticating network entity.

It will be appreciated that this means that the process cannot be entirely stateless for, e. g. , distributing and/or authenticating network entities, as parameters such as connection parameters and time parameters have to be stored for each piece of distributed authentication information. Preferably therefore, the information that has to be stored is stored using resources already allocated for a connection as far as possible. Thus, for example, where the entities already have a statefull connection open between them, the authentication parameters are preferably stored with the parameters regarding the existing statefull connection.

Once the authentication information has been distributed, it is then possible to use it to authenticate network entities in accordance with the method of the present invention.

The authentication procedure can be initiated as and when desired. It is preferably initiated when one or more particular predetermined situations or events occur, such as under the conditions that authentication procedures would normally be initiated. Thus, for example, it could be initiated whenever an entity connects to the network or requests new resources on the network. Alternatively or additionally, it could be initiated when a relevant network entity, e. g. server, suspects a problem or malicious user (and therefore wishes to verify one or more existing network users).

Preferably the rate of authentication requests is variable, and depends on, for example, the detected

state of the network. Thus, for example, the rate of authentication requests could be increased if a threat to the network is perceived.

When the authentication procedure is initiated, the authenticating network entity sends a message to the entity to be authenticated requesting that it obtain authentication information from one or more other network entities and return that information to the authenticating network entity. This message should therefore include the request and the identity (e. g. network address) of the other network entity or entities from which the authentication information is to be sought.

The number of other network entities from which authentication information is sought can be selected as desired. The authentication process will be more secure and reliable if more network entities are involved, but equally the more network entities involved, the longer and more complex the authentication process will be.

The number of network entities from which authentication information is sought could depend on, for example, the size and/or structure of the network, the number of network entities using this method, and/or the permitted traffic overload. Preferably authentication information is sought from at least two other network entities, and, most preferably, authentication information from not more than five network entities is required (so as not to increase too much the traffic load in the network and the complexity of the process). In a particularly preferred embodiment, authentication information from three network entities is required.

The actual network entities from which authentication information is to be sought for a given authentication

can also be selected as desired. They are preferably selected randomly from the available appropriate network entities. This effectively means that the entity to be authenticated has to obtain a random combination of the available authentication information.

In a preferred embodiment, authentication information is not sought from network entities known or thought to be (e. g. based on their previous actions)"malicious" (i. e. liable to return incorrect authentication information).

This helps to avoid such"malicious"entities causing a breakdown of the authentication process. Thus preferably only network entities known or believed to be reliable and/or secure are chosen to be in the group of network entities from which those network entities from which authentication information is to be sought are selected.

It is preferred for the authentication request message to be verifiable by the receiving network entity to be authenticated, as this can, for example, help to prevent an attacker from being able to flood a network entity with forged such requests. This can be achieved as desired. Most preferably it is done by the authentication request message being signed in an appropriate form by the authenticating network entity.

Where, as in the preferred embodiment discussed above, each network entity stores secret authentication information and exchanges a token (cookie) when it receives that authentication information, the authentication request message is preferably verified using the secret authentication information stored by the entity and/or the token (cookie) sent to the entity during the authentication information distribution process by the distributing network entity. Most preferably, the message is signed using one or

preferably both of these pieces of information, preferably using a hash function. The receiving network entity can retrieve this information from the authentication request message and check it to confirm the validity and source of that message.

To further enhance the security of authentication request message operation, especially against flooding of the network, it is further preferred that a given network entity cannot resolve more than one authentication request in a particular time period, e. g. each k-seconds. Preferably this time period depends on the bandwidth of the network.

The authentication request message preferably also includes information or a parameter that the entity being authenticated can return to the authenticating entity with its response to allow the authenticating entity to verify that response as being in answer to the relevant authentication request. This parameter is preferably derived from, e. g. is a hash function over, a local authenticating entity secret parameter and the current value of a time parameter.

Once it has received and verified the authentication request, the entity to be authenticated should then send appropriate messages to the indicated other network entity or entities asking them for the relevant authentication information.

In a particularly preferred embodiment, this authentication information request message is such as to allow the receiving network entity to verify the authentication information request (and e. g. to identify the requesting entity as being a legitimate network user). This again helps to prevent attackers from obtaining authentication information with false

requests. Thus, the authentication information request message is preferably signed in an appropriate manner, for example, by adding to it verification information known to the receiving network entity, or a hash of that information.

In a particularly preferred such embodiment, the authentication information request message is verified by including in it information that is known to and can be identified by the network entity receiving the authentication information request. Most preferably this information for inclusion in the authentication information request by the entity being authenticated is provided to that entity in the original authentication request message from the authenticating network entity.

The entity being authenticated can then remove that information from the authentication request and add it to its authentication information request.

In a particularly preferred such embodiment, this "verification" information comprises information sent to the network entity receiving the authentication information request by the authentication information distributing entity when the network entity is provided with the authentication information. Where a token exchange technique is used, this "verification" information therefore preferably comprises the token (e. g. cookie) sent to the network entity receiving the authentication information request by the authentication information distributing entity during the token exchange when the network entity is provided with the authentication information. In this case, the authentication request message will include the relevant information (e. g. token or cookie) in an appropriate form, e. g. hashed, which information (token) is then passed on to the network entity from which the authentication information is being sought to allow that

entity to verify that the authentication information request is genuine.

It can be seen that in such an arrangement, verification information (e. g. the token or cookie) used when the authentication information is distributed is also used to"sign"and verify subsequent authentication messages, and in particular messages between the entity to be authenticated and the network entities storing the authentication information.

Upon receipt (and verification) of the entity to be authenticated's request, the network entity should return the authentication information to the entity to be authenticated. The network entity could return its authentication information in its original, as-distributed form (e. g. as the distributed random number). However, it preferably returns its authentication information in a modified form, such as a hash of that information.

It is again preferred for the entity being authenticated to be able to verify the message returning the authentication information. That message is therefore preferably"signed"or includes some information to allow the entity being authenticated to verify it.

In a particularly preferred such embodiment, the authentication information message is verified by checking for the presence in it of particular information known to the network entity being authenticated. Most preferably, that verifying information is included in the authentication information request message in a disguised form, and the network entity receiving that message must obtain the verifying information from it and return it in an appropriate form (e. g. undisguised) together with the

authentication information to the requesting network entity, which will then check the verifying information to verify the message.

In a preferred such arrangement the verifying information is provided to the entity being authenticated in the authentication request message.

Preferably that information (which could, e. g., simply be a random number) is provided twice in the authentication request message, in one disguised form that can only be deciphered by the entity being authenticated and in another disguised form that can only be deciphered by the entity from which the authentication information is being requested (in which form it is passed directly to the network entity by the entity being authenticated in the authentication information request message). Both entities can then decipher the verifying information and the entity being authenticated can thereby verify the authentication information message. This could be done, by, e. g., signing or hashing the verifying information with information known only to that entity, e. g. information, such as the token or cookie, it received when the authentication information was distributed.

It will be appreciated that while the above describes one preferred way of requesting and returning the authentication information, this could be done in a different manner and using a different exchange of messages. This could depend, for example, on which application and/or protocol is being used for the authentication scheme.

Once the entity to be authenticated has received all the requested authentication information, it should then return that information to the authenticating entity in some appropriate form. This information could be sent,

e. g. simply as it stands, or in some modified form derived from the original received authentication information. Preferably the information returned to the authentication network entity comprises the ex-or of the individual authentication information that is received.

The message returning the authentication information to the authenticating network entity is also preferably in a form such that the authenticating network can verify the message as coming from a legitimate, and the correct, network entity, and/or as coming in response to a previous authentication request from the authenticating network entity.

Thus, the message returning the authentication information to the authenticating network entity is preferably signed or modified in some way by the sending network entity. Where a token exchange technique is used to distribute authentication information, the sending entity preferably includes the token (e. g. cookie) it received in the message in some way, e. g. by hashing the authentication information with it. This allows the authenticating network entity to verify the message as coming from a legitimate and/or the correct network entity.

The fact that the message is in response to a previous authentication request can be verified as desired. It is preferably done by the network entity returning to the authenticating network entity information sent, as discussed above, in the authenticating network entity's authentication request that allows the authenticating network entity to confirm that the message is in response to its previous request.

In a particularly preferred embodiment, an authentication information response to an authentication

request is only considered valid if the response is returned within a predetermined period of time from the original request. In other words, responses, even if otherwise valid, that take too long are timed out and rejected (considered invalid). This further enhances the security of the process. This time-out rejection is preferably based on the time delay of the response only.

The time-out period could be selected based on e. g. the network protocol used, network congestion and/or the number of network entities involved in the authentication process. A suitable time-out period (for normal network conditions) is believed to be 20-30 seconds.

Upon receipt of an (verified and in-time) authentication information message from the network entity being authenticated, the authenticating network entity should check if the received authentication information is correct and proceed accordingly to authenticate or not the network entity being authenticated. For example, if the authentication information is incorrect, that could mean that the network entity being authenticated is malicious, and/or that there is a problem in the network.

As for the authentication information distribution, it is not necessary for any of the authentication messages discussed above to be sent in an encrypted form, although, of course, encryption can be used to enhance security if desired (and in that case an asymmetric encryption is preferably used). Indeed, it is generally preferred for the messages to be sent in plain text, as that simplifies the procedure.

In another preferred embodiment, authentication takes place via an intermediate network entity (which could, e. g. be a router, firewall or another server) which

intermediate network entity introduces an additional "modification" step into the authentication process.

This arrangement further enhances the security of the process, since, for example, an attacker intercepting the initial authentication request message or the network entity's response, may still not know which intermediate network entity to send its messages via for the necessary modification and/or be able to ascertain what the necessary modification for correct authentication is.

Preferably the modification is so as to effectively send a different authentication request to the entity to be authenticated.

In an IP network, for example, the intermediate network entity could change the IP address of the destination (although this could be a complex method that would require a network filter or a firewall to intercept packets) and/or modify a field in the IP Header (such as a Time to Live Field, which could be easily modified by a router). Other modifications might be to provide a secure channel between the intermediate network entity and the authenticity network entity, although that would increase the complexity of the system.

Preferably, the authentication request message from the authenticating network entity is sent to the entity to be authenticated via the intermediate network entity which then modifies that message, with the entity being authenticated then answering this modified request and returning its answer. The intermediate network entity should then intercept the answer and modify it appropriately before returning it to the original authenticating network entity.

It would be possible to send other messages in the

authentication process via an intermediate network entity for modification. However, that would increase the number of trusted third party intermediate network entities required, and so it is generally preferred that only the messages between the authenticating network entity and the entity being authenticated are sent via a modifying intermediate network entity.

It can be seen that in its preferred embodiments at least, the present invention involves a network entity such as a server distributing authentication information to respective other network entities and then authenticating a network entity by asking it to retrieve the authentication information sent to one or more other network entities. Thus, according to a further aspect of the present invention, there is provided an apparatus for a network entity, comprising: means for distributing authentication information to one or more other network entities; means for requesting a network entity to obtain and return to the instructing network entity authentication information distributed to one or more other network entities; and means for authenticating the network entity to which the request is sent on the basis of the authentication information it returns in response to the request.

According to a yet further aspect of the present invention, there is provided a method of operating an entity in a network, comprising: the entity distributing authentication information to one or more other network entities; the entity requesting a network entity to obtain and return to it authentication information distributed to one or more other network entities; and the entity authenticating the network entity to

which the request is sent on the basis of the authentication information it returns in response to the request.

The methods in accordance with the present invention may be implemented at least partially using software e. g. computer programs. It will thus be seen that when viewed from further aspects the present invention provides computer software specifically adapted to carry out the methods hereinabove described when installed on data processing means, and a computer program element comprising computer software code portions for performing the methods hereinabove described when the program element is run on data processing means. The invention also extends to a computer software carrier comprising such software which when used to operate a network, network entity, server or client computer comprising data processing means causes in conjunction with said data processing means said entity, etc, to carry out the steps of the method of the present invention. Such a computer software carrier could be a physical storage medium such as a ROM chip, CD ROM or disk, or could be a signal such as an electronic signal over wires, an optical signal or a radio signal such as to a satellite or the like.

It will further be appreciated that not all steps of the method of the invention need be carried out by computer software and thus from a further broad aspect the present invention provides computer software and such software installed on a computer software carrier for carrying out at least one of the steps of the methods set out hereinabove.

A number of preferred embodiments of the present invention will now be described by way of example only and with reference to the accompanying drawings, in

which: Figure 1 shows schematically a network to which the present invention can be applied; Figure 2 shows schematically the exchange of messages as authentication information is distributed in a preferred embodiment of the present invention; Figure 3 shows a preferred embodiment of an authentication request message; Figure 4 shows schematically the exchange of messages between the authenticating server and client to be authenticated in a preferred embodiment of the present invention; Figure 5 shows schematically the exchange of messages when the client being authenticated requests authentication information from another network client in one preferred embodiment of the present invention; Figures 6A, 6B and 6C show schematically the exchange of messages in a preferred embodiment of the present invention; Figures 7 and 8 illustrate the effect of malicious users on the authentication process of a preferred embodiment of the present invention; and Figure 9 illustrates the sending of authentication messages via an intermediate network entity.

A preferred embodiment of the present invention in which it is implemented in an IP (Internet Protocol) network will now be described. However, as will be appreciated by those skilled in the art, the present invention is applicable to all networks, and not just IP networks.

Figure 1 shows schematically an IP network. The network includes a server 1 which is the core of the system and the network entity whose security and function it is important to preserve. The server 1 acts to monitor the network in order to discover if there are malicious users.

The network includes a number of clients 2, some of which will in operation of the network require authentication by the server 1. In the present invention this authentication is effected by the server 1 asking the client to be authenticated to seek authentication information from other clients of the network. The operation of this process will now be described.

Before the authentication procedure can take place, it is necessary to distribute authentication information in the form of an appropriate client"secret"to each client of the network. This distribution is done by the server 1, and uses a"cookie"exchange technique to allow the server and client to first verify each other as legitimate and the intended message recipient. This helps to, for example, guard against flooding attacks sent with bogus IP sources or UDP ports. After the cookie exchange and verification, the server sends the authentication information (client secret) to the client.

In the present embodiment, the authentication information takes the form of a"client secret"that is stored by each client of the network and is known only to that client and the authenticating server. Each client stores a different such secret. Each client secret comprises a random number of 64 bits (although any form of authentication information could be used).

The client secrets are limited in time, i. e. they have a predetermined lifetime after which they expire and are replaced by a new secret. This enhances the security of the arrangement.

Figure 2 shows in more detail the exchange of messages as the authentication information is distributed. It is assumed that the exchange of messages takes place

between a server having the network (IP) address B and storing a unique local secret Kb, and a client having a network (IP) address A and storing a unique local secret Ka.

It is also assumed in Figure 2 that this exchange of messages for distributing the authentication information takes place upon initialisation of communication between the server and the client, with the client initiating the communication. (However, as will be appreciated by those skilled in the art, the exchange of messages could take place generally speaking as and when desired).

The initial part of exchange of messages is a cookieexchange, to allow the server and client to verify each other. Thus, as shown in Figure 2, the client first creates a cookie, Cookie Al, which it sends to the server. This cookie, Cookie-Al comprises a hash of the network addresses A, B of the client and server and the local secret, Ka, of the client. This ensures that the cookies depends on the specific parties involved in the message exchange and can only be generated by the particular, issuing network entity, i. e. client (since it uses that client's local secret, Ka). It should also be noted that this message is not verified and only requires a small processing overhead of the hash function. Furthermore, the client does not store the cookie and so there is no resource allocation and the operation is stateless to this stage.

Upon receipt of this message, the server sends the client a cookie of its own, Cookie~Bl. The server's cookie, Cookie~Bl, comprises the hash of the server's IP address B, the client's IP address A, the time t and the server's local secret, Kb. This again means that the server's cookie depends on the specific parties involved in the message exchange and can only be generated by the

server itself. The use of the time parameter also helps to ensure the unrepeatability of the cookie. The cookie will also be different for each client, as it depends on the client's network address and the time parameter.

The server's message also includes the current time

parameter t, and is signed with a cookie, comprising a hash of the client's cookie, Cookie Al (which allows the client to verify that the message is from the server by regenerating its cookie, Cookie-Al, and comparing it with the server's"signature").

The server's cookie, Cookie~Bl, sent to the client serves as a secret client identity or ID, which can be used in the future to verify and sign messages, particular authentication procedure messages, to and from that client.

This verification information (cookie) therefore has to be stored by the client. It also has to be stored for each client by the server. This is done in the present embodiment by the server storing the time parameter t used to generate the cookie against the relevant client (e. g. its network address) to allow it to recreate the cookie when necessary. This means that in the present embodiment for each new connection the server (only) additionally stores the time parameter t to allow it to recover the verification information sent to a given client.

It should be noted that although in the present embodiment the verification information corresponds to the first server cookie that initiates the communication, this is not necessary, and other verification information, for example comprising a further cookie, could be sent and used if desired.

If the client verifies the server's message, it then acknowledges it, by returning a message that includes

the server's signature (the cookie, Cookie~A), the time parameter t, and is signed with a cookie, Cookie~B comprising a hash of the server's cookie, Cookie~Bl.

The server verifies this message by regenerating its cookie, Cookie~Bl, and then creating its own version of the signature cookie, Cookie~B.

The server can then send the authentication information (client secret, Secret Client A sec) to the client. The client secret (authentication information) is generated using appropriate secret information stored by the server and the current time parameter t. In the present embodiment it comprises a 64-bit number generated from this information, although it can take other forms, if desired. This distribution message is again signed with the appropriate cookies, Cookie~A and Cookie~B, for verification purposes.

The client stores the transmitted client secret (i. e. its authentication information).

The server caches the connection parameter (network address, port number) of the relevant client, and the time parameter used to create the first cookie (i. e. client identity secret identity) and the client's secret information, so as to allow it to recreate that information as necessary. So as to keep this process stateless as far as possible, this information is preferably stored using a resource already allocated for a statefull connection. This will often be possible, since normally if a server asks the client for authentication information, it will have a general statefull connection (e. g. a TCP connection) open with the client. In that case, the time information can be stored with the parameters regarding that statefull

connection.

This process is repeated to distribute appropriate client secrets (authentication information) to all the relevant clients in the network.

Each piece of authentication information (client secret) and verification information (secret client ID) and token (cookie) only has a limited period of validity and so is replaced by new such information in a further message exchange at appropriate intervals. This further enhances the security of the system. The validity period and changing of the secret information is varied according to one or more predetermined criteria relating to the state of the network. For example, if a predetermined alert situation is detected, the rate of renewal of the secret information is increased. The rate of authentication requests from the server could also be varied along similar lines, if desired.

It will be seen from the above that the authentication information and message exchange is unencrypted.

However, encryption could be used if desired to further enhance security. If encryption is used, then preferably an asymmetric encryption algorithm is employed. For example, the authentication information distribution could be done using a secure digital signature method if enhanced security was desired.

Although the present embodiment shows a single server distributing the authentication information, it would be possible for more than one server to do so, and indeed that may be preferable. An advantage of using more than one server to distribute the authentication information is that an attacker who manages to place a sniffer in front of a distributing server may not be able to intercept all the authentication information distributed

in the network.

Once the authentication information has been distributed, authentication can take place.

The authentication process can be initiated as desired, for example when the server detects a particular situation. When it is desired to authenticate a client, the server requests from the client authentication information which is stored by other clients of the network.

Figure 3 shows schematically one preferred embodiment of the server authentication request message. Figure 4 shows schematically the sending of that message and the response of the client being authenticated.

As shown in Figure 3, the authentication request message from the server identifies itself as an authentication request and is signed with an appropriate secret signature of the server for verification purposes. The authentication request message also includes the IP addresses and secret client IDs (which, particularly for communication between the clients to enhance security, will serve as verification information) for each client from which the client being authenticated is to seek authentication information.

In the present embodiment, the client being authenticated is instructed to seek authentication information from three other clients of the network, although other numbers of clients could be used, if desired. The clients selected are preferably chosen randomly.

The server's authentication request message includes a server"signature"to allow it to be verified by the

client receiving it, as otherwise a malicious user could use a forged request to flood a client and hence trigger a chain reaction. In the present embodiment, as shown in Figure 4, this is done using a simple hash function which uses the secret client ID, Secret~Client~A~ID, (i. e. verification information cookie sent to the client when the authentication information is distributed) for the client being authenticated and the authentication information, Secret-Client-A-sec, stored by that client.

In the present embodiment, clients are also unable to resolve more than one server authentication request each K-seconds, where K depends on the bandwidth of the network. This further increases security against flooding of the network.

The server also sends in its authentication request a parameter to allow it to authenticate the response of the client. This is necessary because the server requests are stateless. In the present embodiment, the parameter sent by the server to authenticate the response of the client is a hash of the local server secret information Ka and the current time parameter t, and will be referred to as"time confidential information", TCI (see Figure 4). However, other authentication parameters could be sent if desired. The client has to return this"time confidential information"with its response to the server and the server then uses that time confidential information to verify or otherwise the response of the client.

Indeed, in the present embodiment, the response of the client to be authenticated to the server's authentication request is verified using two signatures.

The first is the time confidential information discussed above, which allows the server to confirm that the client's answer is effectively in response to its authentication request. The second authentication

preferably uses the client's verification information (i. e. secret client identity cookie) and its authentication information (i. e. its client secret).

This second signature allows the server to authenticate the user that has sent the message. Only if both signatures are matched, should the server process the message.

In the present embodiment, as shown in Figure 4 the server will also time-out an authentication information response that takes too long. In other words, the client being authenticated must respond within a predetermined time period, or its response is considered invalid in any event. The time-out should be stateless and is preferably based only on the time difference.

This exchange of messages is shown in Figure 4. The server's authentication request to the client includes, as discussed above, the server request message M, the message M hashed with the client's secret identity

(Secret~Client~A~ID) and the client's secret (authentication) information (Secret~Client~A~sec) and the current value of the time parameter t, the"time confidential information parameter"TCI to allow the server to authenticate the response of the client, and the current value of the time parameter t. The client's response to the server includes the"time confidential information"sent by the server, the message M and the client's answer, and the message M and the client's answer hashed with the client's secret identity and the client's secret information, and the current time t.

Of course, as will be appreciated by those skilled in the art and as illustrated in Figure 4, in between these two messages, the client being authenticated must ask the other clients for their authentication information and collect that authentication information for sending

to the server. This exchange of messages will now be discussed.

When the client to be authenticated receives and verifies the server's authentication request, it requests the relevant authentication information from the other network clients indicated by the server. The exchange of messages with one of those other clients will now be described. The exchange of messages is essentially the same for each client from which authentication information is sought.

Figure 5 shows schematically this exchange of messages between the server, the client being authenticated (client A in Figure 5) and the client providing the authentication information (client B in Figure 5).

When the client being authenticated (client A) receives the authentication request from the server, he must ask client B (and the other clients) for their authentication information. This message is verifiable, because client B normally would not know if client A is a legitimate user (and therefore verification is desirable as otherwise any user could potentially ask for, and obtain, client B's authentication information).

This verification is done in the present embodiment by means of a random number N. This random number is 10-16 bits long, although its size can be varied depending on the resources of the network entities. As discussed below, it is necessary for client B to be able to determine the number N by means of a"brute force" attack (i. e. an attack in which the attacker simply tries all possible solutions to identify the true value) over the message it receives from client A containing the number N. Thus N cannot be too big or else client B may not be able to determine it.

The server in its authentication request provides to client A (i. e. the client being authenticated) the random number N in some disguised form that the client A can decipher to derive the value of the random number N, and also in a disguised form that the client providing the authentication information, client B, can decipher to derive the random number N. In the present embodiment the disguised version of the random number N that is to be deciphered by client A comprises the hash of that random number N with client A's client secret (i. e. authentication information, Secret~Client~A~sec) and the current time parameter t. The disguised random number N for deciphering by the client B comprises the hash of that random number with client B's secret identity (i. e. the cookie first sent to it by the server when the authentication information is distributed, SecretClient~B~ID) and the current time parameter t.

Thus in this embodiment, the server's authentication request message also includes, as shown in Figure 5, a first message comprising the hash of the random number N with client B's secret ID (cookie) and the current time parameter t, and a second message comprising the hash of client A's client secret, the random number N and the current time t. The message also includes the current time parameter t.

Upon receipt of this authentication request message, client A derives the random number N from its disguised form. It then passes an authentication information request on to client B, which request for the authentication information includes the disguised version of the random number N from the server that can be deciphered by the legitimate client B.

Upon receipt of this authentication information request, the client B firstly deciphers the random number N from

the request. It does this by means of a"brute force" attack over the part of the message containing N by trying all possible values of N until it finds the correct value of its secret identity (SecretClient~B~ID) and the time parameter t in the message (both of which client B knows already). The value of N found to give the correct values for client B's secret identity and the time parameter t is assumed to be the correct value of N.

This arrangement is sufficiently secure because of the secure properties of the hash function. It is also efficient because a hash is a low resource function. An attacker would not be able readily to determine N, because he would not know client B's secret identity.

The bigger the possible value of this identity

(secret~Client~B~ID), the less susceptible this method is to an attacker using a"brute force"attack.

If client B verifies client A's request, it then returns to client A its reply, which comprises the random number N that it has derived, the disguised form of N sent to it (comprising the hash of the random number N, client B's secret identity and the time parameter t), and the authentication information in the form of the hash of client B's secret information.

Upon receipt of this message, client A verifies it by checking the random number N returned by client B against its derived value of N, and upon verification accepts the hashed authentication information from client B as the authentication information to return to the server.

This exchange of messages is repeated with each relevant client indicated by the server until the client being authenticated has collected all the authentication

information requested by the server.

The client then returns that information to the server in an appropriate form. In the present embodiment this is done by the client being authenticated making an EX-OR of all the authentication information that it receives and sending the result of that operation to the server. Of course, other arrangements could be used if desired.

Upon receipt of the client being authenticated's message, the server checks if the message is correct and, if so, authenticates the client. If the message is incorrect, then the server can take that as an indication that the client is malicious or that there are problems in the network.

The above process is repeated as appropriate to authenticate other clients.

Figures 6A, 6B and 6C show schematically the overall method. As shown in Figure 6A, the server 10 distributes appropriate authentication information (client secrets) 11,12, 13 to the relevant clients 14, 15,16 when a session is initialised. When it is desired to authenticate a particular client 15 (network entity), then as shown in Figure 6B the server 10 sends the appropriate authentication request to that client 15. In response to the authentication request, the client 15 asks the other clients (network entities) 14, 16 for their secret (authentication) information 11,13 which it collects and then returns to the server 10 as shown in Figure 6C.

The table below summarises the messages exchanged in the above embodiment on an IP network.

Action Protocol Information Security stored by the method used server Distribution of the UDP IP address of the Cookie exchange, authentication client, Time based method. information Time parameter Local secret.

Server Request and UDP No information. Hash signature.

Client Response Time based signature for the Client response.

Communications TCP Problem resolution, between clients signature information come from the server Authentication TCP Hash function of the information (by the server) real secret transmission UDP information. No (by the client) encryption is used.

It can be seen from the above that in the present embodiment, when a server needs to authenticate a client, it hands out a server request to the client which asks the client for authentication information which it must obtain from another client. The client being authenticated then sends these requests to the client specified in the authentication request to obtain the authentication information from those clients. Once the client to be authenticated has received the relevant authentication information from the other clients, it returns it to the server and is authenticated or not accordingly.

In the above embodiment, the server communicates directly with the client to be authenticated. However,

in another preferred embodiment, the server communicates with the client to be authenticated via an intermediate network entity. This intermediate network entity (which could, for example, be a router or firewall and should be a"trusted third party") acts to pick-up an authentication request crossing the network and forwards a different authentication request to client to be authenticated. The client to be authenticated answers this different request as being the request from the server. The intermediate network entity intercepts the client's response and forwards it with an appropriate modification to the authenticating server.

This further enhances the security of the authentication process, as an attacker would also have to know via which intermediate network entity authentication messages should pass, even if they manage to intercept some of those messages. The intermediate network entity effectively acts as a"stepping stone"that makes identifying the authentication message path more difficult. Figure 9 illustrates this.

The present invention provides a relatively non-complex authentication procedure that does not have to rely on, for example, the use of cryptographic algorithms and shared keys for its security. The present invention instead relies primarily for its security on the principle that an attacker in the network cannot intercept all of the traffic used in the authentication process and thereby obtain sufficient authentication information to be authenticated.

The reason for this security can be appreciated by considering the number of different authentication information permutations that may be available to an authenticating network entity. If there are N network users, and each authentication request asks for secret

information from J network entities, then the authenticating network entity can choose from C (N, J) possible combinations of authentication information, where

Thus in a network of 100 users, with the authenticating network entity asking for authentication information from three other network entities in the authentication procedure, there are 161,700 different combinations of authentication information available to the authenticating network entity. Thus, even if, for example, an attacker has installed a sniffer on the network and knows 20% of the authentication information, the probability that the attacker can successfully fool the authenticating network entity into authenticating the attacker is only about 1%.

Thus the present invention provides a relatively secure and reliable process for authenticating network entities, without the need for additional security measures such as encryption.

It is also appropriate to consider the performance of the authentication process of the present invention where there are malicious users, i. e. network entities that do not give the correct response to another network entity. Figure 7 is a table, and Figure 8 the corresponding graph, showing the percentage of authentication requests that fail given a particular percentage of malicious users for a network with 100 users and where each authentication request requires authentication information from three different users.

It can be seen that in this network, if 10% of users are malicious, then 27% of authentication requests will

fail. Figures 7 and 8 show that it may be desirable for the authentication process of the present invention to ask for authentication information from network entities which are known to be secure and not malicious.

The present invention is applicable to authentication in networks, such as computer and/or communications networks, generally. It works particularly well when an attacker is connected to a server using a spoofed address, as in that case the attacker can easily be detected with the authentication procedure of the present invention.

The present invention is particularly (although not exclusively) suitable for stateless networks, such as IP networks. It is particularly useful where there is a large number of network entities that can participate in the authentication process and there can be many authentication messages crossing the network using different paths. In such cases in particular, the large topology and stateless properties of the network (such as the Internet) can render it very difficult or unfeasible for an attacker to intercept ("sniff") a significant amount of authentication traffic (as there is, for example, no obvious strategic positions where a "sniffer"could be installed).

The authentication procedure of the present invention can also be used to, for example, monitor the behaviour of a network. This is because a failed authentication request can be an indication that the network has some problem, such as congestion at a particular part (e. g. router) in the network.

The process of the present invention could also be used in multicast networks, as the hierarchical structure of a multicast network could be used in accordance with the

present invention in order to trust some multicast user.

Claims

CLAIMS 1. A method of authenticating an entity on a network used by plural network entities, the method comprising: an authenticating network entity instructing the entity to be authenticated to obtain authentication information from one or more other network entities; the entity to be authenticated obtaining the authentication information from the other network entity or entities and sending that information to the authenticating network entity; and the authenticating network entity authenticating or not the entity to be authenticated on the basis of the authentication information it is sent.
2. The method of claim 1, wherein the authenticating network entity is a server of the network.
3. The method of claim 1 or 2, wherein the network entity to be authenticated comprises a client on the network.
4. The method of any one of the preceding claims, wherein the authentication information comprises particular information that is stored by the network entity from which it is sought.
5. The method of any one of the preceding claims, wherein each piece of authentication information is only valid for a limited period of time.
6. The method of any one of the preceding claims, further comprising at least one network entity distributing authentication information to one or more network entities.
7. The method of claim 6, wherein the authentication

<Desc/Clms Page number 41>

information is distributed by plural network entities.
8. The method of claim 6 or 7, wherein the authentication information is distributed by the authenticating network entity or entities.
9. The method of claim 6,7 or 8, wherein the authentication information is distributed in plain text.
10. The method of claim 6,7, 8 or 9, further comprising the distributing network entity first verifying the network entity that it is distributing the authentication information to, and then, once it has verified the recipient entity, transmitting the authentication information to that network entity.
11. The method of claim 10, wherein the network entity verification is done using a token exchange technique.
12. The method of claim 11, wherein network entities store the token sent to them by the distributing network entity during the authentication information distribution process for future use.
13. The method of any one of the preceding claims, comprising the authenticating network entity instructing the entity to be authenticated to obtain authentication information from at least two other network entities.
14. The method of any one of the preceding claims, further comprising the network entity being authenticated verifying the authentication instruction from the authenticating network entity before responding to that instruction.
15. The method of any one of the preceding claims, further comprising the authenticating network entity

<Desc/Clms Page number 42>

including with the authentication instruction information that the entity being authenticated can return to the authenticating entity with its response to the authentication instruction to allow the authenticating entity to verify that response as being in answer to the authentication instruction.
16. The method of any one of the preceding claims, further comprising the entity to be authenticated, once it has received the authentication instruction, sending authentication information request messages to the indicated other network entity or entities asking them for the authentication information which are such as to allow the receiving network entity to verify the authentication information request.
17. The method of any one of the preceding claims, further comprising the entity being authenticated returning the authentication information to the authenticating network entity together with information to allow the authenticating network entity to verify the message as coming from the correct network entity, and as coming in response to a previous authentication instruction from the authenticating network entity.
18. The method of any one of the preceding claims, further comprising the authenticating network entity determining the time delay between its authentication instruction and the response from the entity being authenticated, and rejecting the response if the response is returned outside a predetermined period of time from the original instruction.
19. The method of any one of the preceding claims, wherein the authentication takes place via an intermediate network entity which modifies the authentication process.

<Desc/Clms Page number 43>
20. The method of claim 19, wherein the authentication instruction from the authenticating network entity is sent to the entity to be authenticated via the intermediate network entity which modifies that instruction, and further comprising the entity being authenticated answering this modified instruction and returning its response, and the intermediate network entity intercepting the response and modifying it appropriately before returning it to the authenticating network entity.
21. A method of operating a network entity, comprising the network entity instructing a network entity to be authenticated to obtain and send to the instructing network entity authentication information from one or more other network entities; and the instructing network entity authenticating or not the network entity to be authenticated on the basis of the authentication information it is sent.
22. The method of claim 21, further comprising the network entity first distributing authentication information to one or more network entities.
23. The method of claim 22, further comprising the network entity first verifying the network entity that it is distributing the authentication information to, and then, once it has verified the recipient entity, transmitting the authentication information to that network entity.
24. The method of any one of claims 21 to 23, further comprising the network entity including with the authentication instruction information that the entity to be authenticated can return to the network entity with its response to the authentication instruction to allow the network entity to verify that response as

<Desc/Clms Page number 44>

being in answer to the authentication instruction.
25. The method of any one of claims 21 to 24, further comprising the network entity determining the time delay between its authentication instruction and the response from the entity being authenticated, and rejecting the response if the response is returned outside a predetermined period of time from the original instruction.
26. A method of operating a network entity comprising: the network entity receiving a request from another network entity for authentication information stored by another network entity or entities; the network entity in response to such a request seeking the authentication information from the indicated network entity or entities; and the network entity returning the authentication information to the requesting network entity.
27. The method of claim 26, further comprising the network entity verifying the authentication information request from the requesting network entity before responding to that request.
28. The method of claim 26 or 27, further comprising the network entity, once it has received the authentication information request, sending authentication information request messages to the indicated other network entity or entities asking them for the authentication information which messages are such as to allow the receiving network entity to verify the authentication information request.
29. The method of any one of claims 26 to 28, further comprising the network entity returning the authentication information to the requesting network

<Desc/Clms Page number 45>

entity together with information to allow the requesting network entity to verify the message as coming from the correct network entity, and as coming in response to a previous authentication request from the requesting network entity.
30. A method of operating an entity in a network, comprising: the entity distributing authentication information to one or more other network entities; the entity requesting a network entity to obtain and return to it authentication information distributed to one or more other network entities; and the entity authenticating the network entity to which the request is sent on the basis of the authentication information it returns in response to the request.
31. An apparatus for a network entity, comprising: means for authenticating other network entities, including means for instructing a network entity to be authenticated to obtain and send to the instructing network entity authentication information from one or more other network entities; and means for authenticating or not the network entity to be authenticated on the basis of the authentication information it sends.
32. The apparatus of claim 31, further comprising means for distributing authentication information to one or more network entities.
33. The apparatus of claim 32, further comprising means for verifying the network entity to which the authentication information is to be distributed.
34. The apparatus of any one of claims 31 to 33,

<Desc/Clms Page number 46>

further comprising means for including with the authentication instruction information that the entity to be authenticated can return to the instructing network entity with its response to the authentication instruction to allow the instructing network entity to verify that response as being in answer to the authentication instruction.
35. The apparatus of any one of claims 31 to 34, further comprising means for determining the time delay between an authentication instruction and the response from the entity being authenticated, and means for rejecting the response if the response is returned outside a predetermined period of time from the original instruction.
36. An apparatus for a network entity comprising: means for receiving a request from another network entity for authentication information stored by another network entity or entities; means for, in response to such a request, seeking the authentication information from the indicated network entity or entities; and means for returning the authentication information to the requesting network entity.
37. The apparatus of claim 36, further comprising means for verifying the authentication information request before responding to that request.
38. The apparatus of claims 36 or 37, further comprising means for sending authentication information request messages to the indicated other network entity or entities asking them for the authentication information which are such as to allow the receiving network entity to verify the authentication information request.

<Desc/Clms Page number 47>
39. The apparatus of any one of claims 36 to 38, further comprising means for returning with the authentication information to the requesting network entity information to allow the requesting network entity to verify the message as coming from the correct network entity, and as coming in response to a previous authentication request from the requesting network entity.
40. An apparatus for a network entity, comprising: means for distributing authentication information to one or more other network entities; means for requesting a network entity to obtain and return to the instructing network entity authentication information distributed to one or more other network entities; and means for authenticating the network entity to which the request is sent on the basis of the authentication information it returns in response to the request.
41. A network entity comprising the apparatus of any one of claims 31 to 40.
42. A network comprising: an authenticating network entity comprising means for authenticating other network entities, including means for instructing a network entity to be authenticated to obtain and send to it authentication information from one or more other network entities and for authenticating or not the network entity to be authenticated on the basis of the authentication information it sends; and one or more other network entities each comprising means for storing authentication information and for sending that information to a requesting network entity.

<Desc/Clms Page number 48>
43. The network of claim 42, wherein the authenticating network entity is a server of the network.
44. The network of claim 42 or 43, further comprising one or more network entities comprising: means for receiving the authentication instruction from the authenticating network entity; means for, in response to such an instruction, seeking the authentication information from the indicated network entity or entities; and means for returning the authentication information to the authenticating network entity.
45. The network of any one of claims 42 to 44, wherein the network entity to be authenticated comprises a client on the network.
46. The network of any one of claims 42 to 45, further comprising at least one network entity for distributing authentication information to one or more network entities.
47. The network of claim 46, comprising plural network entities for distributing the authentication information.
48. The network of any one of claims 42 to 47, wherein the authenticating network entity comprises the apparatus of any one of claims 31 to 35.
49. The network of any one of claims 42 to 48, wherein the authenticating network entity comprises means for instructing the entity to be authenticated to obtain authentication information from at least two other network entities.
50. The network of any one of claims 42 to 49, wherein the network entity to be authenticated comprises the

<Desc/Clms Page number 49>

apparatus of any one of claims 36 to 39.
51. The network of any one of claims 42 to 50, further comprising an intermediate network entity via which the authentication takes place, and which intermediate network entity modifies the authentication process.
52. The network of claim 51, wherein the intermediate network entity comprises means for receiving and modifying the authentication instruction from the authenticating network entity and means for intercepting the response of the entity being authenticated and for modifying that response appropriately before returning it to the authenticating network entity.
53. A computer program element comprising computer software code portions for performing the method of any one of claims 1 to 30 when the program element is run on data processing means.