Mobile IP Working Group Erika Sanchez INTERNET-DRAFT Vesselin Tzvetkov Srba Cvetkovic Sheffield University 16 June 2000 Mobile Virtual Private Network 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