Internet DRAFT - draft-sanchez-mvpn
draft-sanchez-mvpn
Mobile IP Working Group Erika Sanchez
INTERNET-DRAFT Vesselin Tzvetkov
Srba Cvetkovic
Sheffield University
16 June 2000
Mobile Virtual Private Network
<draft-sanchez-mvpn-00.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents, valid for a maximum of six
months, and may be updated, replaced, or obsolete by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
Current security mechanisms offer enough protection to fixed networks for
the establishment of secure communications between nodes. Security
protocols such as IPSEC offer a strong and secure solution for the
creation of VPNs and its functionality has made it very popular in the
networking community.
Mobile networks present several challenges and problems that current
security mechanisms did not take in consideration during their
specification and, even though they continue to be good solutions for
fixed and even mobile networks, they can also undermine the performance of
mobile environments.
This document specifies a protocol that uses the basis of encryption and
authentication for the establishment of Virtual Private Networks on mobile
environments, specifically Mobile IPv4, providing a secure and fast
mobile communication.
The registration of a mobile node with its home and foreign agents
requires the authentication of the mobile node as well as the creation and
distribution of security associations for the protection of the data flow.
Several solutions have been proposed and they have been well accepted by
the Internet community, we propose another solution that improves the
performance and security of a mobile network and provides other security
advantages by making minor changes to the Mobile IP protocol and adding
new extensions to its functionality.
Sanchez, et al Expires 16 December 2000 [Page i]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
Sanchez, et al Expires 16 December 2000 [Page ii]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
Contents
Status of This Memo i
Abstract i
1. Introduction 1
1.1. Comparison with IPSEC Virtual Private Networks . . . . . 2
2. Terminology 4
2.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Specification Language . . . . . . . . . . . . . . . . . 4
3. Overview of Mobile Virtual Private Network 5
3.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 5
3.2. Mobile Virtual Private Network . . . . . . . . . . . . . 7
3.2.1. First Contact . . . . . . . . . . . . . . . . . . 7
3.2.1.1. Registration Request . . . . . . . . . . 7
3.2.1.2. Registration Reply . . . . . . . . . . . 10
3.2.2. Re-registration of a mobile node . . . . . . . . 11
3.2.2.1. Revisiting a foreign agent . . . . . . . 11
3.3. Changing the foreign agent . . . . . . . . . . . . . . . 12
3.4. Session key generation . . . . . . . . . . . . . . . . . 12
3.5. Communication with the correspondent node . . . . . . . . 13
3.5.1. Mobile data flow . . . . . . . . . . . . . . . . 14
4. Error messages 16
5. MVPN Extensions 16
5.1. Mobile Information Extension . . . . . . . . . . . . . . 16
5.2. Foreign Information Extension . . . . . . . . . . . . . . 18
5.3. Home Information Extension . . . . . . . . . . . . . . . 18
5.4. Mobile Reply Extension . . . . . . . . . . . . . . . . . 20
6. MVPN Messages 20
6.1. Request Communication Message . . . . . . . . . . . . . . 21
6.2. Correspondent Information Message . . . . . . . . . . . . 22
6.3. Correspondent Response Message . . . . . . . . . . . . . 23
6.4. Communication Reply Message . . . . . . . . . . . . . . . 25
7. Public Key Infrastructure 26
7.1. Generation and distribution of keys . . . . . . . . . . . 26
8. TCP in TCP tunnelling 26
Conclusions 28
References 29
Authors' Addresses 30
Sanchez, et al Expires 16 December 2000 [Page 1]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
1. Introduction
The IETF RFC 2002 [1] defined the possibility for a node to change its
point of attachment without losing its ability to communicate. The
introduction of mobile entities provided new concerns especially for the
area of security having as principal concern the registration of a mobile
node. The mobile node and other mobile entities MUST be able to provide
information about their identity to other parties in order to be able to
trust and validate the information exchanged between them.
To ensure that the registration of a mobile node with its home agent
is made under secure conditions (authenticity, integrity and
confidentiality) it will be necessary to:
- Authenticate the mobile node with its home agent for the registration of
the mobile nodes' care-of address and provision of services paid by the
mobile node.
- Authenticate the home agent with the mobile node to ensure that a valid
home agent registers the care-of address and provides the services
required by the mobile node.
- Authenticate the foreign agent with the home agent to ensure that a
valid foreign agent provides the required services.
- Authenticate the home agent with the foreign agent for the same reasons
mentioned above. This authentication can be use for billing purposes.
- Authenticate the mobile node with the foreign agent to ensure that the
care-of address is assigned to an authorised and valid mobile node.
- Authenticate the foreign agent with the mobile node to ensure that the
care-of address assigned to the mobile node is valid.
Even when Mobile IP does not require the establishment of a security
association between the correspondent and mobile nodes it is necessary to
perform a mutual authentication to provide confidentiality and integrity
in the information exchanged between them, this will not only protect the
nodes but also the home and foreign networks.
The model presented in this document works under the assumption that a
company can have several private networks spread around the world, and
they can be visited by every node that is registered with them (locally or
externally).
This model requires each correspondent node to provide information that
enables the mobile entities (home agent, foreign agent and mobile node) to
authenticate it. This requirement is NOT mandatory for all applications
MPVN might have but it should be consider as an optional feature at
implementation time.
Until now, Virtual Private Networks (VPNs) have proved to be a convenient
solution for the establishment of secure connections between private nodes
throughout a public network. The creation of such VPNs requires the use of
special techniques such as IPSEC [2], which works under the basis of
encryption, and other cryptographic mechanisms.
The application of such techniques in a mobile environment will provide a
secure solution but it is probable that the performance of the network
will be affected. These techniques were created to work over fixed
networks and since mobile networks differ in certain characteristics it is
necessary to find better solutions.
Sanchez, et al Expires 16 December 2000 [Page 2]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
As mentioned earlier the basis of a Virtual Private Network relies on the
use of cryptographic mechanisms such as encryption, message digests, etc.
The protocol presented in this document seeks the best performance for
mobile environments without affecting the expected levels of security,
MVPN provides strong authentication and fast re-registration, and can be
applicable to current network systems, mobile or fixed.
1.1. Comparison with IPSEC Virtual Private Networks
IPSEC [2] is a standard defined by the IETF that describes a mechanism to
authenticate and/or encrypt IP packets. It defines two services:
Authentication Header (AH) [3] and Encryption Security Payload (ESP) [4]
that can be use in two different modes: transport mode and tunnelling
mode.
IPSEC was created to work for IPv4 and IPv6 so it is one of the most
popular mechanisms to implement VPNs along the Internet. It requires the
establishment of one security association that will offer a one-way
service, this means that it will be necessary to create four security
associations between entities A and B in order to authenticate and encrypt
packets in a two-direction communication path.
Even though IPSEC appears to be a secure and optimal solution for the
creation of VPNs and can be used for Mobile IP, it is necessary to
identify the best mode and structure on which it can provide a better
performance to the network without affecting the security requirements.
IPSEC can add extra and unnecessary overhead to packets that are short and
it is very strict in the use of its services and modes, which makes it
difficult to be optimised for Mobile IP. It also interferes with other
mechanisms such as the ones implemented by Quality of Service (QoS) by
using end to end encapsulation, which includes the TCP header [5].
Building Mobile Virtual Private Networks requires the consideration of new
parameters and the use of conventional methods such as IPSEC can arise
new problems, for example:
- If an 'end to end' protection with IPSEC is used, the foreign and home
agents will not be able to authenticate the data flow between the mobile
and correspondent nodes. In this case the foreign agent network will be
vulnerable since the firewall protecting the foreign agent cannot
perform packet authentication and packet filtering due to the fact that
all the information preceding the IPSEC header is encrypted.
- If a system of security tunnels is used, for example tunnels from:
'CN to HA', 'HA to FA' and 'FA to MN', the connection will not be
optimised for performance. IPSEC will allow the creation of such
tunnelling system but the management of security channels, keys and
packets will affect the performance of the MVPN.
Schneier and Ferguson performed an analysis of IPSEC [6] and described
several concerns about the security provided by IPSEC. Even though its
application to Mobile IP is possible [7] and in some level effective it
does not allow Mobile IP to offer its best performance.
Sanchez, et al Expires 16 December 2000 [Page 3]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
In comparison, MVPN only requires the use of encryption and other
cryptographic mechanisms as well as the inclusion of additional headers in
the registration request and registration reply messages of the Mobile IP
protocol. During the same registration process all entities involved in it
will receive session keys for authentication and encryption that will
enable them to perform a faster communication and negotiation for future
registrations. MVPN uses the same number of messages required for the
registration process hence it only adds processing time for the
encryption and decryption operations.
MVPN is based on a Public Key Infrastructure, which offers a secure
environment for authentication and session key distribution, it also
improves the security and performance of the system with the inclusion of
of a third party called Trusted Centre.
Even though MVPNs do not pretend to establish a universal solution, they
can be use in any environment that requires authentication, integrity and
confidentiality, by specifying the principles on which the MVPN should
work. No matter the requirements a network might have an appropriate MVPN
can be created or adapted, and the compatibility between them SHOULD be
seamless.
MVPN offers flexibility in the selection of the encryption/decryption
algorithm and key size, it is possible to make it compatible with existing
mechanisms and have the same features as IPSEC VPNs.
IPSEC can be used in any environment and will offer authentication,
confidentiality and integrity mechanisms but it will involve a more
complex administration for a mobile environment which makes it less
suitable as an appropriate solution.
To implement MVPN over Mobile IP, the latter will require small changes in
its functionality as well as the inclusion of the extensions defined in
this document, also it will be necessary for the foreign and home networks
to provide a Public Key Infrastructure mechanism that uses a trusted
third party for the authentication.
Sanchez, et al Expires 16 December 2000 [Page 4]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
2. Terminology
2.1. General Terms
IP
Internet Protocol.
MVPN
Mobile Virtual Private Network.
Node
A device that implements IP.
Nonce
Packet
It is an IP header plus payload.
Public Key
Key used in Public Key Infrastructures available for the public.
Private Key
Key used in Public Key Infrastructures as private.
Ku
A
Public key of node A.
Kr
A
Private key of node A.
E
Ku
A
Encryption using the public key of node A.
DSS
Digital Signature Standard.
Security association
Simplex connection that affords security services to the traffic
carried by it.
Virtual Private Network
Is a private data network that uses the public telecommunication
infrastructure, maintaining privacy through the use of a
tunnelling protocol and security procedures.
Terms specific to Mobile IP can be found in RFC 2002.
2.2 Specification Language
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3].
Sanchez, et al Expires 16 December 2000 [Page 5]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
3. Overview of Mobile Virtual Private Network
3.1. Basic Operation
Before a mobile node can start communicating with any correspondent node,
it is necessary for it to obtain a care-of address from an available
foreign agent, and then register it with its home agent.
To avoid any possible intrusions within the networks it is required to
authenticate all the messages exchanged during the registration process
(registration request and registration reply messages), and then establish
session keys. In the model described here the session keys include an
authentication and an encryption key, that will be used during subsequent
communications that any of the mobile agents may have with the other
parties.
The authentication of a node requires that a shared secret, referenced by
a security association, is already shared between the authenticating
parties. In many occasions this shared secret is exchanged between them
by a process called handshake or negotiation.
MVPN suggests the use of a Public Key Infrastructure (PKI), which requires
every mobile entity to have a Private (Kr) and Public (Ku) key registered
with a trusted third entity. The generation and distribution of these keys
will be explained in following sections.
With the use of a PKI every entity will be able to authenticate and
exchange session keys (shared secrets) between them in a very secure
manner. A third entity known as Trusted Centre will be in charge of
the registration of the public keys created by the home agent and their
distribution to other nodes.
If a node wishes to contact another one, it needs to query the Trusted
Centre for the public key of the node. This implies that every node will
know the public of the Trusted Centre and will be able to contact it in a
secure way.
MVPN will work under the following assumptions:
- Every mobile node MUST have a SMART CARD that contains its Private Key.
- Every mobile node MUST know the Public Key of its home agent.
- Every node that belongs to a domain MUST know the Public Key of the
Trusted Centre available for that domain.
- Every node MUST have a unique Identification that SHOULD be created and
distributed by the home agent.
- Every Public Key MUST be registered with the Trusted Centre and MUST
only be retrieved by providing a mean for its authentication.
- A node MUST only obtain the Public Key of another node by using the
Trusted Centre services. The Trusted Centre MAY act as a broker for the
retrieval of Public Keys of nodes that belong to different domains.
- The home and foreign agents MAY keep a list of Public Keys that belong
to specific mobile nodes. This to be used in case the Trusted Centre is
not available or to accelerate the authentication process.
- The keys MUST be refreshed every certain period of time to reinforce the
security of the system.
- Every node MUST have the capability of performing cryptographic
calculations such as encryption.
Sanchez, et al Expires 16 December 2000 [Page 6]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
- In order to communicate with the mobile node, the correspondent node
MUST provide information to prove its identity to the home agent.
- Every mobile entity, including the corresponding node, MUST support at
least the SHA-1 or MD5 algorithms.
The authentication information will be carried as extensions of the
Mobile IP protocol. The scheme presented here only establishes the basic
principles by which a PKI authentication process should be created in a
mobile environment hence, it will be possible to create compatible
security mechanisms that work under the same basis.
To provide a small level of protection the Agent Advertisement message
sent by the foreign agent will be linked to the Registration Request.
After that, the exchange of registration messages will be the same as the
one indicated in the Mobile IP protocol specification.
The protocol will be composed by two sets of messages. The first will be
known as 'First Contact', and is carry out when the mobile node visits a
foreign domain for the first time. The second set of messages belongs to
the 're-registration' phase, and is perform when the lifetime of the
previous Registration Request is about to expire, during this phase the
mobile agents already know their Public Keys, the Public Key of the
mobile node and already share session keys (authentication/encryption)
with the mobile node, these infers that less information will be
exchanged for the re-registration of the mobile node and will be not
necessary to contact the Trusted Centre unless it is required (keys
expired).
The messages transmitted on a public network, in the Mobile IP case the
registration request transmitted from the foreign agent to the home
agent, will require a stronger level of security. It is our belief that
security should be applicable according to the risks presented in
different scenarios; since the information is travelling on a public
network it is necessary to provide a stronger security mechanism. After
completing the registration process the mobile node is now able to
receive information from any authorised correspondent node.
Even though the mobile node is ready for receiving/sending information
the correspondent node will need to complete a similar procedure for
its authentication. Before initiating any communication, the
correspondent node needs to authenticate itself with the mobile node.
This will be performed with the help of the home and foreign agents and
will also serve for the distribution and establishment of a session key
to be shared between the correspondent and mobile nodes using the
Diffie-Hellman algorithm.
The mobile entities and the correspondent node MUST be able to negotiate
or indicate the type of cryptographic mechanism to implement for
encryption and message digest calculation, this implies that the length
of the keys will be variable and should be specified in the extension on
which it is included.
Sanchez, et al Expires 16 December 2000 [Page 7]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
3.2. Mobile Virtual Private Network
3.2.1. First Contact
In this phase the mobile node is visiting the network managed by a foreign
agent for the first time. None of them knows the Public Key of the other
party and they do not share any information that might be use to attach
them. The mobile node is only aware of the Public Key of its home agent.
The First Contact is performed by the distribution of four extensions that
are added to the Registration messages already needed to be exchanged
between the mobile entities.
The first message received by the mobile node is the ICMP Agent
Advertisement as described in [1]. This message MUST not be protected
since it represents the first encounter the foreign agent has with any
mobile node and it is certain that a mobile node does not have any
association with the foreign agent, i.e. does not know the Public Key of
the foreign agent.
The foreign agent MUST set the sequence number field of the ICMP Agent
Advertisement message. This 16-bit value MUST be used by the mobile node
as a nonce, notice that the nonce value is a 16-bit value, which means
that other 16-bit need to be added to the sequence number in order to
create the final mobile node nonce, this value MUST be returned to the
foreign agent to help it keep track of the advertisements answered and to
insure that the messages are not been replayed.
3.2.1.1 Registration Request
After receiving the ICMP advertisement, the mobile node answers with a
Registration Request, which must include an authentication extension and
the 'mobile information' extension defined by the MVPN protocol.
Since the mobile node is using a SMART CARD it is possible for the home
and foreign domains to keep a record and inventory of all the mobile nodes
using their services. That is why the extensions defined by the MVPN
include relevant information about the identity of the mobile node,
consisting of specific information of the SMART CARD.
If the mobile node is not using a SMART CARD then the information that
corresponds to it can be omitted or the fields can be use to provide other
relevant information, this information can also be discarded to reduce the
size of the packet.
Other information included in the 'mobile information' extension will
serve the home agent to perform the appropriate authentication and the
creation and distribution of the session keys.
The 'mobile information' extension MUST include:
- Mobile node's identification number.
- Home agent's identification number.
- Nonce generated by the mobile node.
- Sequence number of the ICMP Agent Advertisement message.
- Mobile node's authentication key.
Sanchez, et al Expires 16 December 2000 [Page 8]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
The 'mobile information' extension MIGHT include:
- MAC address of the computer.
- Identification number of the SMART CARD.
- Mobile node's public key (optional).
The complete structure of the 'mobile information' extension can be found
in section 4.1.
If the home agent is not available it is possible for the mobile node to
provide its Public Key to the foreign agent, this is not recommendable
during the 'first contact' since it could be possible for any attacker to
intercept the key and use it. The retrieval of the Public Key with the
Trusted Centre enables the foreign agent to verify its authenticity. This
will allow the foreign agent the provision of certain services while
trying to establish contact with the home agent.
The authentication extension will be constructed as defined in [1] and is
used to protect the integrity of the packets. The authentication key
applied for the generation of the authentication extension will be added
to the 'mobile information' extension to enable the home agent to perform
the appropriate verification of the message and authenticity of the node.
There is the possibility of using an optional extension 'home agent
addresses', which contains the addresses of other home agents trusted by
the mobile node's home agent that can perform the authentication of the
mobile node, they share the private key of the home agent and all the
Public Keys belonging to the mobile nodes. They cannot provide typical
home agent services such as binding messages, tunnelling and packet
forwarding, but they will enable the mobile node to have access to
Internet services.
The use of home agent negotiators provides the capability of allow a valid
user to communicate, more information about this extension will be
provided in a future draft.
Since this is the first contact the mobile node has with the foreign
agent, the latter will not be able to perform the integrity check and
authentication of the packet. The foreign agent MUST save the information
contained in the packet, create the 'foreign information' extension, add
it to the Registration Request message and send it to the home agent. The
integrity and authentication of the Registration Request message will be
performed until the home agent replies to the foreign agent about that
request, i.e. when it receives the key used by the mobile node for the
creation of the authentication extension.
The purpose of the 'foreign information' extension is to provide
information to the home agent so it can perform the authentication of the
foreign agent. The foreign agent MUST request the public key of the home
agent to the Trusted Centre by using the security association existing
between them, since the home agent belongs to a different domain the
Trusted Centre will need to contact another Trusted Centre in order to
retrieve the appropriate key.
The 'foreign information' extension includes the foreign agent IP address,
a nonce and the identification of the foreign agent. The complete
structure of the extension is shown in section 4.2.
Sanchez, et al Expires 16 December 2000 [Page 9]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
The authentication extension provided by the mobile node is no longer
needed, the foreign agent will calculate a new one that includes a
digital signature for integrity protection. The 'mobile information'
extension needs to be attached to the message.
More protection will be provided in this message since it will travel
outside the foreign domain, i.e. public network. This escalation of
security improves the optimisation of the authentication process.
The home agent will receive the Registration Request and perform the
authentication of the mobile node. Also it will verify the integrity of
the message by using the digital signature included in the packet, the
Public Key of the foreign agent and the group key, generated by the
Trusted Centre.
The following diagram shows where the extensions need to be included
in the Registration Request message:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |S|B|D|M|G|V|rsv| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| |
+ MVPN +
| Extension |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Authentication Extension +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sanchez, et al Expires 16 December 2000 [Page 10]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
3.2.1.2. Registration Reply
After verifying the integrity and authentication of the packet the home
agent will reply to the foreign agent with a Registration Reply message as
defined in [1].
The Registration Reply MUST include the 'home information' extension,
which serves the same purpose as the other extensions previously described.
It will provide information about the home agent as well as the session
keys, encryption and authentication, that the mobile entities will use in
future communications.
Some of the information will be available only for the mobile node, which
means that it will be protected with the mobile node's Public Key, it is
important to maintain confidentiality between the mobile node and home
agent and only provide to the foreign agent information relevant to the
services it needs to supply to the mobile node.
The 'home information' extension MUST contain the nonce provided by the
foreign agent, result of the Registration Request, Home Agent's
identification, Public Key of the foreign agent (provisioned by the
Trusted Centre), encryption and authentication keys (for future
communications), authentication key used by the mobile node for the
creation of the authentication extension send by the mobile node to the
foreign agent, and the Public Key of the mobile node.
The complete structure of the 'home information' extension is shown in
section 4.3.
The extension MUST be added to the Registration Reply and send to the
foreign agent as a 'home information' extension. The foreign agent MUST
verify the integrity of the message and the authentication provided by the
home agent, including the verification of the nonce.
With the information provided by the home agent, the foreign agent is now
able to authenticate the Registration Request message provided by
the mobile node, after that the message can be discarded.
The foreign agent will extract the information relevant to the mobile
node and create the 'mobile reply' extension that contains an acknowledge
value that indicates whether the authentication process was successful or
not, the nonce value provided in the registration request by the mobile
node, registration and authentication keys, and foreign agent's public key.
The complete structure of the 'mobile reply' extension is shown in section
4.4.
Notice that the authentication between the mobile node and foreign agent
is performed by using the information provided in the Registration Request
message, while the authentication between the home agent and foreign agent
is performed with the information provided in the Registration Reply
message.
The nonce values help the foreign agent to identify the mobile node it
needs to authenticate and to prevent any replay attack, the same happens
with the authentication of the home agent.
Sanchez, et al Expires 16 December 2000 [Page 11]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
After performing the authentication, the Registration Reply MUST be
encrypted with the public key of the mobile node and its integrity MUST be
protected with an authentication extension created with the application of
a hash function and using the authentication key provided by the home
agent in the 'home information' extension.
The Registration Reply is send to the mobile node, with the 'mobile reply'
added. The mobile node MUST verify the authenticity of the packet and
record the encryption and authentication keys provided by the home agent.
At the end the mobile node is capable of communicate with any
correspondent node, providing that the Registration process was
successful, and the mobile entities share an encryption and an
authentication key, they also know the public keys of the other parties.
3.2.2. Re-registration of a mobile node
3.2.2.1. Revisiting a foreign agent
The re-registration phase refers to the registration of a mobile node to
its current point of attachment, which means that the lifetime of the
previous Registration Request is about to expire and a new registration is
needed.
During the previous registration all the necessary information was
distributed to the mobile entities, which means that less calculations
will be required and more time will be saved. The purpose of MVPN is to
optimise the authentication process for security and performance.
The re-registration specified in this document will be applicable only if
the lifetime of the encryption and authentication keys shared between the
mobile entities are still valid, if not the mobile node will need to
complete the 'first contact' phase for the registration.
Before the lifetime of the previous registration expires, the mobile node
MUST send a normal Registration Request message without including any
extension, but protecting the data flow by using the encryption and
authentication keys that the mobile entities already share. In this way
the procedure of re-registration is quicker and more secure.
The Registration Request received by the foreign agent will be encrypted
and authenticated, since the foreign agent has a copy of the keys it MAY
decrypt and verify the integrity of the packet.
The foreign agent MAY decide to delegate the message to the home agent by
only changing the IP header of the packet, or it can perform the
validation of the Registration Request.
The home agent MAY create new encryption and authentication keys to
improve the security of the system and meet the requirements of key
refreshment.
Sanchez, et al Expires 16 December 2000 [Page 12]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
3.3. Changing the foreign agent
When changing foreign agents, the mobile node MUST provide the
authentication key shared with the previous foreign agent and the
correspondent node to the new foreign agent. This will allow the mobile
node to keep communicating without interruptions.
After the first contact of the mobile node, the latter MUST send the
encrypted information to the foreign agent. The message MUST be send as
an UDP message and MUST contain the ID of the session held between the
mobile node and the correspondent node, the correspondent nodes' IP
address, the length of the authentication key and the authentication key.
Every time a mobile node changes foreign agents or the lifetime of the
previous Registration Request ends, the keys will be considered expired
and the mobile node will need to register following the procedure
indicated in the 'First Contact' phase.
3.4. Session key generation
Once the authentication and the public key exchanged has been performed
the mobile node is able to communicate with a correspondent node. In the
model presented here we specified the requirement of authenticating the
correspondent node before establishing any communication with the mobile
node.
The home agent MUST perform the initial authentication of the
correspondent node and MUST create and distribute an authentication key
that will be shared between the mobile entities, including the
correspondent node.
The session key can have a variable extension to allow the use of any
encryption algorithm selected by the communicating parties. The basic
principle is to authenticate the packets exchanged between the nodes with
the help of the mobile agent, they will not be able to decrypt the
packets, only the correspondent node and mobile node are capable of
doing that. That way confidentiality between the mobile and correspondent
nodes is still guaranteed.
The correspondent and mobile nodes MUST generate a session key, using the
Diffie-Hellman algorithm, to perform data flow encryption. This key will
be shared only between them.
There will be one data flow authentication key between the home agent,
foreign agent, correspondent node and mobile node, and one data
encryption key shared between the correspondent node and mobile node.
The correspondent node - mobile node session key is not modified when the
mobile node changes foreign agents, the new foreign agent MUST receive
the authentication key from the mobile node so the data flow continues as
before.
Sanchez, et al Expires 16 December 2000 [Page 13]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
3.5. Communication with the correspondent node
Before communicating with the mobile node, the correspondent node needs to
authenticate itself to the home agent by using its public key registered
with the Trusted Centre, and receive the authentication key distributed by
the home agent.
After that, the correspondent node can initiate the communication. All
messages, including the session key exchange messages, are sent as UDP
messages.
The correspondent node sends a 'Request Communication' message to the home
agent, which includes a random generated number representing the Y value
of the Diffie-Hellman algorithm, the identification of the correspondent
node, the IP address of the mobile node, a nonce, and the security
algorithms supported by the correspondent node.
The complete structure of the 'Request Communication' message is shown in
section 5.1.
The security algorithms are represented as flags, if the flag has a zero
value it means that the correspondent node does not support an specific
security algorithm (SHA-1, MD5). This will allow the mobile node and
foreign agent to select an algorithm that they implement.
The information will be encrypted with the Public Key of the home agent
and the private key of the correspondent node, depending on the type of
information to be send. The authentication of the message will be
performed by the home agent using the Public Key of the correspondent
node.
The home agent MUST authenticate the message and check its integrity, if
everything is correct it MUST generate the session key for authentication
and distribute it to the nodes. It sends a 'Correspondent Information'
message to the mobile node that includes the session key, the Y value,
correspondent nodes' identification, public key, and IP address,
a 'Hello value' and the security algorithms supported by the
correspondent node.
The complete structure of the 'Correspondent Information' message is shown
in section 5.2.
Since the packets are received by the foreign agent this needs to be
involved in the process of establishing the communication parameters, it
will verify the 'Hello value', extract the authentication key, set the
security algorithm that it supports and send that information along with
the one received from the home agent to the mobile node. Protecting it
with the Public Key of the mobile node and the foreign agents' Private
Key.
The mobile node MUST reply to the foreign agent with a 'Correspondent
Response' message by sending a random number that represents the Y value
of the Diffie-Hellman algorithm, the nonce generated by the correspondent
node and indicate the security algorithms it supports. This information
will be protected with the Public Key of the correspondent node and the
Private Key of the mobile node.
Sanchez, et al Expires 16 December 2000 [Page 14]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
The complete structure of the 'Correspondent Response' message is shown in
section 5.3.
Finally, the foreign agent MUST send the 'Communication Reply' message to
the correspondent node. It will basically contain the same information as
the one contained in the 'Correspondent Response' message.
This information is already encrypted so it is not necessary to re-encrypt
it, its integrity will be protected by using a nonce and the
authentication key. The complete structure of the 'Communication Reply'
message is shown in section 5.4.
The mobile entities, including the correspondent node, share a session key
for authentication, and the mobile node and correspondent node have the
material to calculate the encryption key by using the Diffie-Hellman
algorithm. They will use as encryption algorithm one of the specified in
the security algorithm field of the messages.
Now the nodes are able to communicate with the added value of
authentication and encryption of the data flow. It is important to note
that the establishment of security associations between the correspondent
nodes with the mobile entities is optional, but it is significant to
consider the authentication and protection of information generated by a
correspondent node since it will also have access in an indirect way to
the protected networks.
3.5.1. Mobile data flow
The data field of the packet that flows from the mobile node to the
correspondent node, or vice versa, contains information about the security
association built between the mobile node and the correspondent node
during the process described in section 3.5. This security association
makes reference to information for encryption and authentication of the
packets exchanged between them.
The structure of the packet, from the mobile node's point of view, will be
as follows:
----------------------------------------------------------
| IP | TCP | CN | Authentication | security | data |
| hdr | hdr | nonce | | parameters | |
----------------------------------------------------------
The authentication value is added to verify the integrity of the packet,
and is calculated using a keyed MD5 or HMAC of the entire IP packet. The
key is the one shared between the mobile entities and the correspondent
node, and it is distributed as described in section 3.5.
The CN nonce will be use as a first step for authentication, if the value
is not correct then the packet is considered invalid and therefore it is
discarded. It is used to protect against replay attacks and to serve
against minor Denial of Service attacks.
The message received by the home agent from the correspondent node will be
verified by using first the CN nonce value and then the authentication
value. The home agent will tunnelled the packet using TCP in TCP (see
section 7 for more details) to the foreign agent modifying the
authentication value to protect the new TCP header.
Sanchez, et al Expires 16 December 2000 [Page 15]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
The foreign agent will authenticate the packet, de-tunnelled it and
delivered it to the mobile node, building a new authentication value. The
mobile node can prove the authentication and can decrypt the message by
using the shared key with the correspondent node. Notice that the
encryption key is different from the authentication key.
The encryption method can be selected by the parties, according to the
encryption algorithms they support. The structure of the message is as
follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Auth Sec Par | Encr Sec Par |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
55
Length
96
Auth Sec Par
8-bit value indicating the authentication method used, the values are
defined as follows:
01 - MD4
02 - MD5
03 - SHA-1
04 - DSS
Encr Sec Par
8-bit value indicating the encryption method used, the values are
defined as follows:
01 - DES
02 - SkipJack
03 - IDEA
04 - Blowfish
05 - triple DES
06 - AES
SPI
32-bit security parameter index to identify the key to be used for
the authentication and decryption of the packet
Data
n-bit information send by the parties
Sanchez, et al Expires 16 December 2000 [Page 16]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
4. Error messages
In case of encountering an error during the communication of nodes MVPN
specifies the use of error messages. Upon the arrival of the error
message, the receiver will not need to perform any specific mechanism,
these messages have informational purposes only.
The errors occurred during the 'first contact' phase will be send as UDP
packets from a different port as the data flow errors.
Following is the structure of the error message:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Error code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error code
01 - Authentication key not valid
02 - Session key not valid
03 - No support offered for MVPN
04 - Public key not valid
05 - Home agent not found
06 - Trusted Centre not found
07 - other
The mobile entities can also use the error messages specified by the MIP.
5. MVPN Extensions
MVPN establishes the use of three new extensions to perform the process of
authentication, each extension MUST be added to the Registration Request
and Registration Reply messages as indicated in section 3.2.
It is important to point out that the boundaries shown in the following
diagrams will disappear after the encryption of the packet, the diagrams
only show them to be more comprehensible.
5.1. Mobile information extension
The logical structure of the 'mobile information' extension from the
cryptographic point of view:
M = [MN Nonce | MAC ID | USER ID | SC ID | MN Auth key]
Mobile information extension = E [E [M] | OTHER INFO] | HA ID
Kr Ku
MN HA
Sanchez, et al Expires 16 December 2000 [Page 17]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | MN Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Nonce | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| DVC MAC ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| USER ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| len | MN Auth key ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
36
Length
Size of the complete message, excluding the type and length fields
MN Nonce
32-bit number, the first 16-bit represent the sequence number of the
ICMP Agent Advertisement the mobile node is responding. The rest
16-bit are generated by the mobile node as nonce
DVC MAC ID
64-bit identification of the computer used as mobile node
USER ID
48-bit identification of the mobile node
SC ID
64-bit identification of the SMART CARD the mobile node is using.
This information is optional.
OTHER INFO
64-bit information for the foreign agent. It is used in case the
foreign agent cannot contact the home agent and the foreign agent has
the mobile node's Public Key in its cache memory or obtained it
through a Trusted Centre. This information is optional.
len
6-bit length of the authentication key
MN Auth key
n-bit key used in the calculation of the authentication extension.
The maximum value for this authentication key will be [8]
Sanchez, et al Expires 16 December 2000 [Page 18]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
5.2. Foreign information extension
The logical structure of the foreign information extension from the
cryptographic point of view:
F = E [FA ADR | FA Nonce]
Ku
HA
Foreign information extension = E [F] | FA ID
Kr
FA
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | FA Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FA Nonce | FA ADDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FA ADDR | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| FA ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
37
Length
16 bytes
FA Nonce
32-bit nonce number generated by the foreign agent
FA ADDR
32-bit IP address of the foreign agent
FA ID
64-bit Identification of the foreign agent
5.3. Home information extension
The logical structure of the home information extension from the
cryptographic point of view:
Q = FA Nonce | Result | KuMN | MN Nonce | Ses Key | Auth Key | MN Auth key
W = E [KuFA | MN Nonce]
Ku
MN
Home information extension = E [E [Q]] | W
Ku Kr
FA HA
Sanchez, et al Expires 16 December 2000 [Page 18]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | FA Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FA Nonce | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| FA ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | len1 | len2 | len3 | len4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ses Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Auth Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KuMN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
38
Length
Size of the extension
MN Nonce
32-bit nonce generated by the mobile node
len(i)
4-bit size of the following keys
KuFA
n-bit foreign agent's public key
Ses Key
n-bit session key used by the mobile entities for encryption
Auth Key
n-bit authentication used by the mobile entities
MN Auth Key
n-bit authentication key used by the mobile node in the
authentication extension
KuMN
n-bit mobile node's public key
5.4. Mobile Reply Extension
The logical structure of the mobile reply extension from the cryptographic
point of view:
T = E [E [ACK | MN Nonce | Ses Key | Auth Key]]
Ku Kr
MN FA
Mobile reply extension = T | W
Sanchez, et al Expires 16 December 2000 [Page 20]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | MN Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Nonce | ACK |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK | len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Ses Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| len | Auth Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| W |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
39
Length
Size of the mobile reply extension
ACK
32-bit response of the home agent and mobile node
W and other fields
See section 5.3
6. MVPN Messages
MVPN introduces the use of three messages for the authentication of a
correspondent node wishing to communicate with the mobile node and the
creation of a security association between them. Their use is explained in
section 3.4.1.
It is important to point out that the boundaries shown in the following
diagrams will disappear after the encryption of the packet, the diagrams
only show them to be more comprehensible.
6.1. Request Communication Message
The logical structure of the request communication message from the
cryptographic point of view:
V = MN ADDR | E [Ycn | CN ID] | CN Nonce
Kr
CN
Request communication message = E [V | Sec Par | P value | g value]
Ku
HA
Sanchez, et al Expires 16 December 2000 [Page 21]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Ycn |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ CN ID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CN Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sec Par | len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| P value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| len | g value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
1
Length
19
len
length of the Ycn value
Ycn
48-bit value for the Diffie-Hellman algorithm
CN ID
64-bit identification of the correspondent node
CN Nonce
32-bit nonce generated by the correspondent node
Sec Par
16-bit flags that represent security algorithms supported by the
correspondent node
len
6-bit size of the P value
P value
n-bit P value corresponding to the Diffie-Hellman algorithm for the
calculation of a shared secret key
len
6-bit size of the g value
g value
n-bit g value corresponding to the Diffie-Hellman algorithm for the
calculation of a shared secret key
Sanchez, et al Expires 16 December 2000 [Page 22]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
6.2. Correspondent Information Message
The logical structure of the correspondent information message from the
cryptographic point of view:
U = E [Ses Key | V | KuCN | CN ADDR]
Ku
MN
Correspondent information message =
E [U | E [Hello Value | Sec Par | P value | g value]]
Kr Ku
HA FA
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Ycn |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ CN ID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CN Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sec Par | len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Ses Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| len | KuCN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hello Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CN ADDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| len | P value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| len | g value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
2
Length
Size of the message
len
Size of the Ycn value
Ycn
48-bit value for the Diffie-Hellman algorithm
CN ID
64-bit identification of the correspondent node
Sanchez, et al Expires 16 December 2000 [Page 23]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
CN Nonce
32-bit nonce generated by the correspondent node
Sec Par
16-bit flags that represent security algorithms supported by the
correspondent node
Ses Key
n-bit session key shared between the mobile entities for encryption
KuCN
Public Key of the mobile node
Hello Value
Control string
CN ADDR
32-bit correspondent node IP address
len
6-bit size of the P value
P value
n-bit P value corresponding to the Diffie-Hellman algorithm for the
calculation of a shared secret key
len
6-bit size of the g value
g value
n-bit g value corresponding to the Diffie-Hellman algorithm for the
calculation of a shared secret key
6.3. Correspondent Response Message
The logical structure of the correspondent response message from the
cryptographic point of view:
L = E [E [Ymn | Sec Par | P value | g value]]
Kr Ku
MN CN
Correspondent response message =
E E [Ses Key | CN ID | CN ADDR] | L]
Kr Ku
MN FA
Sanchez, et al Expires 16 December 2000 [Page 24]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Ymn |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ CN ID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CN Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sec Par | len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Ses Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CN ADDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| len | P value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| len | g value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
4
Length
Size of the message
len
Size of the Ymn value
Ymn
48-bit value for the Diffie-Hellman algorithm
CN ID
64-bit correspondent node identification
CN Nonce
32-bit nonce generated by the correspondent node
Sec Par
16-bit flags that represent security algorithms supported by the
foreign agent
Ses Key
n-bit session key
CN ADDR
32-bit correspondent node's IP address
len
6-bit size of the P value
Sanchez, et al Expires 16 December 2000 [Page 25]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
P value
n-bit P value corresponding to the Diffie-Hellman algorithm for
the calculation of a shared secret key
len
6-bit size of the g value
g value
n-bit g value corresponding to the Diffie-Hellman algorithm for the
calculation of a shared secret key
6.4. Communication Reply Message
The logical structure of the correspondent response message from the
cryptographic point of view:
Communication reply message = L | CN Nonce
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Ymn |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CN Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sec Par |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
5
Length
Size of the message
len
Size of the Ymn value
Ymn
48-bit value for the Diffie-Hellman algorithm
CN Nonce
32-bit nonce value generated by the correspondent node
Sec Par
16-bit flags that represent security algorithms supported by the
mobile node
Sanchez, et al Expires 16 December 2000 [Page 26]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
7. Public Key Infrastructure
It is outside of the scope of this document to describe the complete
functions that a Trusted Centre must have when working in a mobile
environment, however it is important to mention the basic ideas on which
they should work.
7.1. Generation and distribution of keys
As mentioned earlier, every node that belongs to a network domain SHOULD
be provided with a Public and a Private Key that are managed by a Trusted
Centre.
In public key cryptography, the public and private key are generated at
the same time using the identical algorithm, normally these keys are
generated by the Trusted Centre. The private key is given only to the node
that requested it and the public key is made available to any node, in our
model a node will only acquire another party's public key through the
Trusted Centre. The private key is kept, as its own name describes it,
private, it is not shared with any other node and it is not sent across
the network, its distribution can be performed via a floppy disk or any
other mechanism that guarantees confidentiality and privacy.
The private key is used to decrypt messages that have been encrypted with
the public key. It is also possible to encrypt messages with the private
key and decrypt them with the public key. With the latter it is feasible
to perform the authentication of a node.
For example, A and B are trying to communicate and each have a private and
a public key registered with the Trusted Centre. A can retrieve B's public
key and vice versa. If A encrypts a message with B's public key, the only
one able to decrypt the message will be B, since it can only be decrypted
with B's private key. If A encrypts a message with its own private key
then any other node will be able to decrypt it with A's public key. If the
message encrypted by A is a certificate, then B can be certain that the
message was sent by A, since it is the only one that posses A's private
key.
In the model described here, it is recommended the keys to be created by
the home agent and registered with the Trusted Centre. The retrieval of a
key will be managed by the Trusted Centre and the security will need to be
more controlled. In order to communicate with the Trusted Centre, every
node SHOULD know its public key and the Trusted Centre should provide a
certificate of the key it is providing.
8. TCP in TCP tunnelling
As mentioned earlier, the IP in IP tunnelling used in mechanisms such as
IPSEC is not optimal because it interferes with the use of:
- Optimisation for GEO satellite connections. Techniques such as 'TCP
connection splitting'. GEO's are a very affordable technology that will
probably be part of the future.
- Firewall filtering.
- Network monitoring.
If tunnelling is still needed a better option will be TCP in TCP, which
will solve the problems IP in IP presents.
Sanchez, et al Expires 16 December 2000 [Page 27]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
It has a simple mechanism to construct it, new TCP and IP headers are
added in front of the original packet as shown in the following diagram,
and the original packet can be encrypted and authenticated.
----------------------------------------------------------
| new IP | new TCP | orig IP | orig TCP | |
| header | header | header | header | Data |
----------------------------------------------------------
As disadvantages, the packet will contain redundant information (extra
TCP header) and the traffic will be incremented.
The TCP header might contain information that an attacker can use, but
other techniques such as port masking can be used. Our recommendation is
to work with TCP in TCP tunnelling since MVPNs do not require the TCP
in TCP tunnelling that IPSEC or other mechanisms provides.
Sanchez, et al Expires 16 December 2000 [Page 28]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
Conclusions
Virtual Private Networks have proven to be an acceptable solution for the
implementation of secure communications between private networks that need
to use a public network as a communication path. There have been several
proposals for the creation of such VPNs and they seem to be working
accordingly to the requirements of each application.
These proposals, including IPSEC, were created thinking on a fixed
environment and even though they have had good results on some of their
applications, in others they do not allow the establishment of a secure
environment without sacrificing the performance of the network.
One example is their use on a mobile environment. VPN mechanisms were
thought also as global solutions when in practice it is necessary to
create a specific solution for a specific situation based in the same
foundations. IPSEC provides two services and two different modes that
offer several options for the implementation of a secure channel but it
does not allow the modification of the protocol to obtain the 'best' of
two worlds: performance and security.
Security protocols available nowadays can provide the same security level
in a mobile environment, we are not discussing the effectiveness of such
protocols only their applicability to mobile entities. Certainly IPSEC
can be used for the implementation of VPNs in a mobile world but it does
not guarantee that its use will be the most optimal.
The advantages provided by a mobile protocol can be affected if other
required processes are not the adequate, such is the case of
authentication. Mobile environments brought with them different
characteristics and more risks that need to be taken in consideration
before choosing or implementing a security framework.
The protocol presented in this document proposes the establishment of a
Mobile Virtual Private Network by using a Public Key Infrastructure that
will handle the authentication of the mobile agents during the
registration of the mobile node. The model used describes the application
of such MVPNs in private networks belonging to the same corporation, which
makes feasible the implementation of such PKI and other features presented
in this document, such as the use of SMART CARDS and the creation of
public and private keys by the home agent.
MVPN relies on the cryptographic basis of encryption and authentication,
providing some mechanisms to protect against man-in-the-middle attacks,
spoofing and some denial of service attacks. It also protects the home
and foreign networks by authenticating the correspondent node. Even though
this means more processing it also means the provision of more security
and since computational systems are becoming faster it should be possible
for them to perform these computations.
MPVN is a protocol optimised for:
- Small number of messages.
- Compatibility with Mobile IP.
- High security-high quality of Mobile Virtual Private Networks.
- Fast data transmission after the authentication procedure.
- Practical use and simplicity.
Sanchez, et al Expires 16 December 2000 [Page 29]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
Mobile IP still presents some security breaches that cannot be covered
with MVPN, other mechanisms need to be created to guarantee full
protection against denial of service attacks to the home and foreign
agents.
MVPN provides an authentication framework that can also be applied to
other protocols such as IIP [9], it will necessary to modified the
protocol but it should be compatible with other MVPN implementations.
This protocol is still under revision and its implementation and testing
will be performed during the following months.
Sanchez, et al Expires 16 December 2000 [Page 30]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
References
[1] Charles Perkins, editor. IP Mobility support. RFC 2002,
October 1996.
[2] Stephen Kent and Randall Atkinson. Security architecture
for the Internet Protocol. RFC 2401, November 1998.
[3] Stephen Kent and Randall Atkinson. IP Authentication header.
RFC 2402, November 1998.
[4] Stephen Kent and Randall Atkinson. IP Encapsulating Security
Payload (ESP). RFC 2406, November 1998.
[5] Yongguang Zhang, editor. The implication of end-to-end IPSEC.
Internet-draft, March 2000.
[6] Ferguson Neils and Schneier Bruce. A Cryptographic Evaluation of
IPSEC. Counterpane Internet Security, Inc.
[7] Secure Mobile Networking Project. Final Report. University of
Portland, June 1999.
[8] Rivest, R. The MD5 Message-Digest Algorithm, RFC 1321, April 1992.
[9] Nam Yap, C. et al. Itinerant Internet Protocol, draft, June 2000.
Sanchez, et al Expires 16 December 2000 [Page 31]
INTERNET-DRAFT Mobile Virtual Private Network 16 June 2000
Authors' Addresses
Questions about this document can also be directed to the authors:
Erika Sanchez
Centre for Mobile Communications
Department of Electronic and Electrical Engineering
University of Sheffield
Regent Court
211 Portobello Street
Sheffield S1 4DP, England
Phone: +44 114 222 2108
Fax: +44 114 222 8299
Web: http://www.dcs.shef.ac.uk/~esanchez
E-mail: E.Sanchez@dcs.shef.ac.uk
Vesselin Tzvetkov
Centre for Mobile Communications
Department of Electronic and Electrical Engineering
University of Sheffield
Regent Court
211 Portobello Street
Sheffield S1 4DP, England
Phone: +44 114 222 2108
Fax: +44 114 222 8299
E-mail: zzb99vt@sheffield.ac.uk
Srba Cvetkovic
Centre for Mobile Communications
Department of Electronic and Electrical Engineering
University of Sheffield
Regent Court
211 Portobello Street
Sheffield S1 4DP, England
Phone: +44 114 222
Fax: +44 114 222 8299
E-mail: srba@dcs.shef.ac.uk
