Pruebas de Hipótesis 152.

This Shared key protocol [15] is used to authenticate binding updates between a mobile and a corresponding node that share a symmetric key. The protocol has the following properties:

• To prevent a malicious mobile from forging a binding update containing another node’s home address, it must know the secret key.

• To create a binding update for a care-of address a mobile node needs to be able to receive messages sent to it.

• A mobile does not need to be able to receive messages sent to a particular address to create a binding update that deletes a binding cache entry, however it does needs to know the secret key.

Each correspondent node has a secret key. There is no key distribution mechanism because the key does not need to be shared as the correspondent sends a challenge to the mobile node, which is made from the secret key. Each correspondent node also generates a randomly generated number called a nonce, at regular intervals. A correspondent node uses the same key and nonce with all the mobiles it is in communication with, avoiding the need to generate and store new ones when a new mobile communicates with it. Each nonce value is identified by a subscript. The subscript identifier is communicated in the protocol, so that if it is replaced by subscript +1, the correspondent can distinguish between them and can be checked against the old messages. The correspondent nodes store both the current and the previous nonce, as older values can be discarded. Any messages using the old nonces will be rejected as replays.

Keys can be either a fixed value or regularly updated. An update of the key can be done at the same time as an update of nonce, so that the subscript identifies both the nonce and the key. A correspondent node can generate a fresh key each time that it boots to avoid the need for secure persistent storage.

The protocol operates in following steps:

Step 1 - The mobile node MN establishes a connection with the corresponding node CN and

communicates its home and care of address. Refer to List of Notations.

Step2 - The correspondent node sends a binding request to the mobile node containing the challenge

(rc), and the subscript identifier serial number (j), which indicates the nonce version (Nj) used to

generate the challenge. The challenge can be recomputed from the nonce at any time, relieving the correspondent from storing state data. The challenge (rc) is created by using the Message Authentication Code, MAC, computed on message (CoA/Nj/1) with the Corresponding Nodes key KCN.

CN MN(CoA):rc,j

Rc = MACKCN(CoA/Nj/1)

Step 3 - The mobile node hashes together the shared secret and the challenge to form a session key

(KBU), and then uses this session key to authenticate a binding update. The binding update contains the

subscript identifier j, so that the correspondent knows which value of the nonce Nj to use to re-compute the session key.

MN CN : T0, HoA, CoA, I, MACKBU(T0/HoA/CoA/I),j

KBU = Hash(Kh/Rc)

Once the MAC has been verified, the correspondent creates a binding cache entry. This message contains a tag (T0) so that it can be distinguished from another variant version of the protocol. The

sequence number (I) is also contained in the binding update so that different binding updates sent within the same lifetime of the nonce Nj , can be established in their relative order.

By running the above protocol again, starting at step 2, the correspondent can refresh the binding cache entry for the mobile node when it expires. If the care-of address changes then the mobile node runs the protocol again using the new one, but only if the mobile node is still able to receive messages sent to the old care-of address.

However in that case that there is a change in care of address but the mobile cannot receive messages from the old care of address then an alternative variant protocol is used, the operation of this protocol is as follows:

Step 1 - The KBU key authenticates the binding update sent by the mobile node. To distinguish it from the binding update message of the previous protocol it contains a tag (T1).

MN CN: T1,HoA,CoA’,I’,MACKBU(T1/HoA/CoA’,I’),j

If the correspondent has a binding cache entry and is able to verify the Message Authentication Code, MAC, then it should mark the binding cache entry as invalid. If the correspondent does not have an existing binding cache entry, then it does not need to verify the MAC.

Step 2, - A new challenge is sent to the new care-of address by the correspondent. The challenge is sent

even if the MAC in message 1 is unverifiable. If messages have been lost or state lost has occurred within a node then by the correspondent sending a new challenge to the new care-of address allows the protocol to resynchronise.

CN MN(CoA’) : r’c,j’

r’c=MACKCN(CoA’/Nj’/1)

Step 3 - Once the MAC has verified the correspondent, the mobile’s binding cache entry can be created

or updated. This step is the same as the third step of the previous protocol.

MN CN : T0,HoA,CoA’,I’’,MACK’BU(T0/HoA/CoA’,i’’),j’

K’BU = H(Kh/r’c)