In addition to the Mobile-Home authentication extension, the optional Mobile-Foreign and Foreign-Home authentication extensions are defined. Based on security policy, a FA, MN or HA may require that the identity of other entities be authenticated. For example, the function of the foreign agent is to provide a routing service and based on security policy the foreign agent may wish to refuse service to a home agent or mobile node. In this case registration messages from the home agent to the foreign agent, and/or from the mobile node to the foreign agent should also be authenticated. For example, a foreign agent may charge mobile nodes as customers for a routing service. As a result, a likely policy would require that mobile nodes prove their identity.
In the case of registration, to add authentication between the mobile
node and foreign agent a Mobile-Foreign Authentication extension is added
by the mobile node to the registration packet after the Mobile-Home
Authentication extension.
A UDP mobile registration packet is:
In our abstract packet format a registration message
form the mobile node to the foreign agent is:
where data-list is the entire packet. The foreign agent will remove
and process the last extension. Note that if there is a pre-existing
security association between the mobile node and the foreign agent then
showing authentication here is no different then showing that
it holds in the case of the mobile node and home agent.
It seems unreasonable to establish shared symmetric keys between the mobile node and foreign agent or even the foreign agent and home agent prior to registration. In the broadest terms, mobility assumes that future locations are not determined in advance. Assuming a certificate infrastructure a foreign agent is able to authenticate either the home agent or mobile node or both in a scalable fashion. If the foreign agent gets a signed registration request and possibly also a certificate from the mobile node then the foreign agent can checks its own CA (certificate authority) to see if the request is signed correctly and if so then decide whether or not to permit registration. Similarly, the foreign agent can request that control messages from the home agent are signed and that a certificate is included. This can be used to verify the identity of the home agent. Using a certificate infrastructure allows the foreign agent to verify signatures when services are requested, so the foreign agent need not have shared secret keys for all potential users in advance.
In particular, using digital signatures would change the above registration packets in that the Authentication Data might now be an un-keyed hash (of the same fields) that was digitally signed. Optionally, a public key might be added in an additional extension. This is an interesting area for future examination.