Internet DRAFT - draft-floroiu-dynsa-mip

draft-floroiu-dynsa-mip



INTERNET DRAFT                                                J. Floroiu
Date: 30 November 2001                                         FhG Fokus
Expires: May 2002


	    Dynamic Security Associations Setup in Mobile IP
		    <draft-floroiu-dynsa-mip-00.txt>


Status of This Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 obsoleted 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

   This document proposes extensions to the Mobile IPv4 base protocol
   [RFC2002] enabling mobile nodes and mobility agents to dynamically
   setup security associations. Mobile IP is therefore employed as a
   supporting protocol for SA negotiation. The proposed mechanism is
   based on RSA cryptography [RSA78], entities acting as key
   distribution centers and Diffie-Hellman exchanges [DH76].

1.  Terminology

     Mobile Node (MN)
         Mobile IP mobile node

     Home Agent (HA)
         Mobile IP home agent

     Foreign Agent (FA)
         Mobile IP foreign agent

     Security Association (SA)
         Set of parameters describing a simplex secure "connection"
         between two peers

     RSA
         Rivest, Shamir and Adleman public key algorithm



Floroiu                                                         [Page 1]

INTERNET DRAFT                                          30 November 2001


     Diffie-Hellman (DH)
         A protocol enabling two nodes to securely derive a shared
         secrets without having a pre-existent security relationship

     Certificate
         A data structure which associates an entity (identified for
         instance by its name) with a public key and some other possible
         extensions, signed by a trusted third party

     Network Access Identifier (NAI)
         A character string identifying the mobile nodes and mobility
         agents

     Internet Key Exchange Protocol (IKE)
         A protocol which negotiates and provides authenticated keying
         material for security associations in a protected manner
   
2.  Introduction
   
   There are several potential methodologies of authenticating Mobile
   IP control messages, such as manually distributed shared secrets,
   IKE negotiated SAs, AAA key distribution, CA signed certificates
   [Jacobs01].
   
   Manually distributed shared secrets have two main disadvantages.
   First, it does not scale well as the number of shared secrets
   experience a quadratic grow.  Secondly, keys need to be
   pre-configured on all involved entities as there is also no support
   for dynamic keys configuration.
   
   AAA key distribution is based on the idea of having pre-distributed
   shared secrets between the interacting entities. This approach
   actually shifts the problem rather than addressing it. 
   
   IKE provides flexibility and a very good level of security. Peers
   authenticate each other through shared secrets, public keys or
   certificates. In the first phase IKE sets up the ISAKMP SA which is
   used to secure the negotiation of further SAs. In aggressive mode
   this process requires three trips. The SA negotiation which takes
   place during phase two requires three more trips.
   A mobile node to negotiate SAs with FA and HA requires therefore
   three round trips to FA and three round trips to HA. This extensive
   control message exchange however negatively impacts on hand-over
   performance.
   Besides, a MN visiting a private addressing realm will not be able
   to communicate at the IP level with the HA unless a Mobile IP tunnel
   is created, which cannot be done prior to MN authentication.
   
   The proposed protocol does not seek to achieve a level of
   flexibility comparable to IKE, but to use Mobile IP as a SA
   negotiation supporting protocol which would satisfy the security
   needs of a mobile node.



Floroiu                                                         [Page 2]

INTERNET DRAFT                                          30 November 2001

   The proposed solution is based on the use of RSA cryptography for
   initial authentication of peers and as a mean to secure further SA
   negotiation. The advantage of such an approach is that no additional
   control message exchange is necessary in order to set up a "main SA"
   to protect further exchanges, as IKE does (ISAKMP SA).
   
3.  Assumptions and requirements
   
   In principle the design is based on the idea of using reverse
   tunneling [RFC2344], with the tunnel being segmented at the FA level.
   Also colocated care-of addresses are envisioned to be used.  Such an
   architecture supports bridging private IP addressing realms (a
   situation which occurs when both home and foreign domain employ
   private addressing schemes).
   
   The following requirements have been considered as having particular
   importance for the design: 
   
     1) The SA setup must be accomplished in one round trip so that the
     hand-over performances wouldn't be affected too much (higher delays
     are however expected due to the cryptographic operations involved).
     
     2) In real world environments, besides authenticating the Mobile IP
     control messages, a MN typically needs to set up an AH tunnel with
     the FA (or another administrative entity in the visited domain) and
     a MN an ESP encrypted tunnel with the HA.  This would protect MN in
     visited domains against attacks based on IP and MAC address
     spoofing and the MN inter-domain traffic against passive
     eavesdropping.  Therefore, the SAs set up between the mobility
     entities should address these needs as well.
     
     3) MN and FA must not be forced or assumed to have any previous
     knowledge of each other. MN and FA should therefore rely on HA for
     the initial MN-FA SA setup.
     
     4) The solution should be extensible to hierarchical Mobile IP
     architectures.  Although the document do not explicitly deal with
     hierarchical architectures, support is provided for enabling MN to
     perform "local" SA setup with the FA. In an hierarchical
     architecture the HA and FA referred throughout the document would be
     the gateway FA and the gateway HA. The SA setup schemes within a
     hierarchy of FAs or HAs is beyond the scope of the current version
     of this document.
   
4.  Key Distribution and Security Associations Setup
   
   For the authentication SAs MN negotiates all parameters except for
   the keys, which are provided (initially) by  HA and (later on also)
   by FA. For the encryption SAs the keys are typically 3DES keys
   derived from the shared secrets obtained as result of DH exchanges.
   
   MN and FA need to set up an encryption SA in order to ensure security
   of further "local" MN-FA authentication SA negotiations which would
   take place without the assistance of HA. As soon as the MN-FA
   encryption SA expires, MN should register again via the HA.

Floroiu                                                         [Page 3]

INTERNET DRAFT                                          30 November 2001


   HA and FA act as Key Distribution Centers for the authentication SAs.
   Only the MN-HA and MN-FA encryption SAs keys are adopted as result to
   DH key exchange. This breaks the symmetry of the MN-HA, FA-HA and
   MN-HA security relationships in the sense that MN and FA have to
   trust the HA and MN has to trust FA as soon as HA has authenticated
   the FA.

   This is assumed however to be acceptable since:
     
     1) MN is part of the same administrative domain as the HA, with the
     HA being the entity which authenticates the MNs, therefore having
     some kind of authority over the MN;
     
     2) MN is visiting a foreign domain to which it should present its
     credentials, with FA "representing" the local authority;
     
     3) FA must rely on HA for authenticating the MN.
   
   Besides, the control message exchange gets dramatically lower.
   
4.1. Security associations

   The following security associations will be negotiated by the
   protocol. Different authentication SAs have been defined for Mobile
   IP and AH authentication. 
   
   A MN-FA encryption SA was also defined. It aims at protecting the
   negotiation of the MN-FA AH SAs without assistance of HA.

      +-------------+--------------------+-------------------------+
      | Name        | Description        | How is the key obtained |
      +-------------+--------------------+-------------------------+
      | MH_MIP_AUTH | MN-HA MIP auth. SA | Key generated by HA     |
      | MF_MIP_AUTH | MF-HA MIP auth. SA | Key generated by HA     |
      | HF_MIP_AUTH | HF-HA MIP auth. SA | Key generated by HA     |
      |             |                    |                         |
      | MH_ESP_ENCR | MN-HA ESP encr. SA | DH Key exchange         |
      | MH_AH_AUTH  | MN-HA AH auth. SA  | Key generated by HA     |
      |             |                    |                         |
      | MF_AH_AUTH  | MN-FA AH auth. SA  | Key generated by HA, FA |
      | MF_MIP_ENCR | MN-FA MIP encr. SA | DH Key exchange         |
      +-------------+--------------------+-------------------------+
   

5.  Other considerations
   
   Each time a RSA extension is present, a NAI identifying the sender
   must also be present. NAI is used to retrieve the corresponding
   certificate.






Floroiu                                                         [Page 4]

INTERNET DRAFT                                          30 November 2001

   
   RSA cryptographic operations should be used only if no SA matching
   the intended operation is present. There are several reasons for
   that:
     1) to preserve the entropy of the RSA keys;
     2) to save some time by performing shared secret based operations
     rather than RSA operations;
     3) to save some space since the RSA cipher comes in chunks as large
     as the RSA key length.
   
6.  Formats of the extensions
   
   All message extensions are in the form of vendor extensions
   [RFC3115]. Every extension has at most one variable long field so
   that the length of such a field can be easily deduced from the vendor
   extension length field. 
   
6.1. SA Proposal Extension
   
   This extension carries a SA proposal containing the parameters to be
   negotiated between the peers. More proposals can be included by the
   initiator (MN). Currently SPI, the SA lifetime and the protocol are
   defined.
   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             SPI                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         SA lifetime           |            Protocol           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   The Type of the Key Extension is TBD.
   
   The Vendor-CVSE-Types (subtypes) are as follows:
   
     3010   MH_MIP_AUTH proposal   (PR_MH_MIP_AUTH/PR_HM_MIP_AUTH)
     3011   MF_MIP_AUTH proposal   (PR_MF_MIP_AUTH/PR_FM_MIP_AUTH)
     3012   HF_MIP_AUTH proposal   (PR_HF_MIP_AUTH/PR_FH_MIP_AUTH)
     
     3020   MH_AH_AUTH proposal    (PR_MH_AH_AUTH/PR_HM_AH_AUTH)
     3021   MF_AH_AUTH proposal    (PR_MF_AH_AUTH/PR_FM_AH_AUTH)
     
     3030   MH_ESP_ENCR proposal   (PR_MH_ESP_ENCR/PR_HM_ESP_ENCR)
     3031   MF_MIP_ENCR proposal   (PR_MF_MIP_ENCR/PR_FM_MIP_ENCR) 
     
   The same CVSE code is used in both directions of the SA negotiation
   between two given entities. The content however reflect the proposal
   of the sending peer. In the PR_MH_MIP_AUTH in the request for
   instance MN proposes the SPI to be used by HA when authenticating
   Mobile IP registration reply messages along with the SA lifetime and
   protocol to be used.  In the PR_HM_MIP_AUTH in the reply on the other
   hand HA proposes the SPI to be used by MN when authenticating Mobile
   IP registration requests along with the granted SA lifetime and
   protocol to be used.



Floroiu                                                         [Page 5]

INTERNET DRAFT                                          30 November 2001


   Protocol is one of the following:
     1      MD5/prefix+suffix authentication
     2      HMAC MD5 authentication
     3      HMAC SHA-1 authentication
     65     3DES encryption
     129    Diffie-Hellman key exchange
   
   
   
6.2. Key Extension
   
   The Key Extension contains the key associated with a certain SA.
  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Key type              |            Key ...           
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Type of the Key Extension is TBD.
 
   The Vendor-CVSE-Types (subtypes) identify the particular SA type this
   key is related to. The following types have been defined:
   
     3110   Shared secret for MH_MIP_AUTH  (SS_MH_MIP_AUTH)
     3111   Shared secret for MF_MIP_AUTH  (SS_MF_MIP_AUTH)
     3112   Shared secret for HF_MIP_AUTH  (SS_HF_MIP_AUTH)
     
     3120   Shared secret for MH_AH_AUTH   (SS_MH_IPS_AUTH)
     3121   Shared secret for MF_AH_AUTH   (SS_MF_IPS_AUTH)
     
     3130   DH public info. for MH_ESP_ENCR  (DH_MH_ENCR_pub)
     3131   DH public info. for MF_MIP_ENCR  (DH_MF_ENCR_pub)
   
   SS_MH_ESP_ENCR is derived by combining DH_MH_ENCR_pub,
   DH_MH_ENCR_priv (produced by MN) and DH_HM_ENCR_pub, DH_HM_ENCR_priv
   (produced by HA).
   
   SS_MF_MIP_ENCR is derived by combining DH_MF_ENCR_pub,
   DH_MF_ENCR_priv (produced by MN) and DH_FM_ENCR_pub, DH_FM_ENCR_priv
   (produced by FA).

   Note that for DH keys DH_AB_XXX and DH_BA_XXX are different from each
   other, while for shared secrets SS_AB_XXX is the same as SS_BA_XXX.
   
   Key Type is one of the following:
   
   Authentication keys (for the MIP and AH authentication SAs):
     1      MD5/prefix+suffix authentication (typical length 16 bytes)
     2      HMAC MD5 (typical length 16 bytes)
     3      HMAC SHA-1 (typical length 20 bytes)
   
   Diffie-Hellman public key (for constructing the shared keys to be
   used by MIP and ESP encryption SAs)
     129    Diffie-Hellman


Floroiu                                                         [Page 6]

INTERNET DRAFT                                          30 November 2001


   Key field is a variable length field specifying the key. The length
   of this filed is deduced from the total length of the extension
   contained in the Vendor Extension header.
   
6.3. Authentication Extension
   
   This extension carries an RSA authenticator.
  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Authenticator...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
   Authenticator field is a variable length field containing an
   encrypted digest computed over the payload.

6.4. Encrypted Payload Extension
   
   The Encrypted Payload Extension transports a sequence of SA Proposal
   and Key extensions in encrypted form.   
   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Security Parameter Index                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Encrypted  Payload ...         
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The SPI is used for identifying the appropriate SA.

7.  The control message exchange
   
   The following diagram depicts a typical control message exchange. The
   MN aims at setting up an AH tunnel to FA and an ESP/AH tunnel to HA.
   The following notation have been used in order to indicate
   authentication and encryption:

   { Message } RSA_priv_Entity    A digest of Message was encrypted with
				  the RSA private key of the indicated
				  Entity and appended to Message;

   { Message } SS_XXX             When used in conjunction with Mobile
				  IP registration messages denotes an
				  Mobile IP prefix-suffix authenticator
				  which is appended to Message;

   < Message > Key                Message is encrypted using Key (which
				  might be a RSA key or a 3DES key) and
				  transferred as chiper.








Floroiu                                                         [Page 7]

INTERNET DRAFT                                          30 November 2001


  M N                           F A                       H A
   |                             |                         |
   { RegReq ----------->
     NAI
     FA-NAI
     PR_MH_ESP_ENCR
     PR_MH_AH_AUTH
     PR_MH_MIP_AUTH
     PR_MF_AH_AUTH
     PR_MF_MIP_AUTH
     DH_MH_ENCR_pub
   } RSA_priv_MN
				F A                       H A
				 |                         |
				 { { RegReq ----------->
				     NAI
				     FA-NAI
				     PR_MH_ESP_ENCR
				     PR_MH_AH_AUTH
				     PR_MH_MIP_AUTH
				     PR_MF_AH_AUTH   [1]
				     PR_MF_MIP_AUTH  [2]
				     DH_MH_ENCR_pub
				   } RSA_priv_MN
				   PR_FH_MIP_AUTH
				   PR_FM_MIP_AUTH  [3]
				   PR_FM_AH_AUTH   [4]
				 } RSA_priv_FA
				
				F A                       H A
				 |                         |
				 { { RegRpl <-----------
				     NAI
				     FA-NAI
				     PR_HM_ESP_ENCR
				     PR_HM_AH_AUTH
				     PR_HM_MIP_AUTH
				     PR_FM_MIP_AUTH  [3]
				     PR_FM_AH_AUTH   [4]
				     < SS_HM_AH_AUTH
				       SS_HM_MIP_AUTH
				       SS_MF_MIP_AUTH
				       SS_MF_AH_AUTH
				     > RSA_pub_MN
				     DH_HM_ENCR_pub
				   } RSA_priv_HA
				   PR_HF_MIP_AUTH
				   PR_MF_AH_AUTH   [1]
				   PR_MF_MIP_AUTH  [2]
				   < SS_HF_MIP_AUTH
				     SS_MF_AH_AUTH
				     SS_MF_MIP_AUTH
				   > RSA_pub_FA
				 } RSA_priv_HA
				
Floroiu                                                         [Page 8]

INTERNET DRAFT                                          30 November 2001


  M N                           F A
   |                             |
   { RegRpl <-----------
     NAI
     FA-NAI
     PR_HM_ESP_ENCR
     PR_HM_AH_AUTH
     PR_HM_MIP_AUTH
     PR_FM_MIP_AUTH  [3]
     PR_FM_AH_AUTH   [4]
     < SS_HM_AH_AUTH
       SS_HM_MIP_AUTH
       SS_MF_MIP_AUTH
       SS_MF_AH_AUTH
     > RSA_pub_MN
     DH_HM_ENCR_pub
   } RSA_priv_HA
   
   A secondary objective would be fitting one control messages into one
   datagram, since fragmented control messages may introduce severe
   delays if fragments got lost. From the perspective of the message
   size, the main issue is related to the RSA plain text and cipher
   length: the cipher is as long as the RSA key and can accommodate a
   plain text almost as long as the RSA key.  Therefore, in order to
   optimize the space usage, the plain text and the RSA key must be
   nearly the same size.  Following this idea, and considering the size
   of the extensions transfered during a "normal" exchange, the SA
   proposal extensions in the reply messages could be encrypted along
   with the keys. It should be noted that even if there are multiple
   proposals for a given SA, the reply contains only the accepted
   proposal.
   
   If the same is done for the SA proposal extensions in the request
   packets, the SPI values won't appear in plaintext in the network
   which improves the security of the security material being
   negotiated.

   The exchange depicted below is based on this idea.
   
  M N                           F A                       H A
   |                             |                         |
   { RegReq ----------->
     NAI
     FA-NAI
     < PR_MH_ESP_ENCR
       PR_MH_AH_AUTH
       PR_MH_MIP_AUTH
       PR_MF_AH_AUTH
       PR_MF_MIP_AUTH
     > RSA_pub_HA  
     DH_MH_ENCR_pub
   } RSA_priv_MN



Floroiu                                                         [Page 9]

INTERNET DRAFT                                          30 November 2001


				F A                       H A
				 |                         |
				 { { RegReq ----------->
				     NAI
				     FA-NAI
				     < PR_MH_ESP_ENCR
				       PR_MH_AH_AUTH
				       PR_MH_MIP_AUTH
				       PR_MF_AH_AUTH   [1]
				       PR_MF_MIP_AUTH  [2]
				     > RSA_pub_HA
				     DH_MH_ENCR_pub
				   } RSA_priv_MN
				   < PR_FH_MIP_AUTH
				     PR_FM_MIP_AUTH  [3]
				     PR_FM_AH_AUTH   [4]
				   > RSA_pub_HA
				 } RSA_priv_FA
				 
				F A                       H A
				 |                         |
				 { { RegRpl <-----------
				     NAI
				     FA-NAI
				     < PR_HM_ESP_ENCR
				       PR_HM_AH_AUTH
				       PR_HM_MIP_AUTH
				       PR_FM_MIP_AUTH  [3]
				       PR_FM_AH_AUTH   [4]
				       SS_HM_AH_AUTH
				       SS_HM_MIP_AUTH
				       SS_MF_MIP_AUTH
				       SS_MF_AH_AUTH
				     > RSA_pub_MN
				     DH_HM_ENCR_pub
				   } RSA_priv_HA
				   < PR_HF_MIP_AUTH
				   PR_MF_AH_AUTH   [1]
				   PR_MF_MIP_AUTH  [2]
				   SS_HF_MIP_AUTH
				   SS_MF_AH_AUTH
				   SS_MF_MIP_AUTH
				   > RSA_pub_FA
				 } RSA_priv_HA
				 










Floroiu                                                        [Page 10]

INTERNET DRAFT                                          30 November 2001


  M N                           F A
   |                             |
   { RegRpl <-----------
     NAI
     FA-NAI
     < PR_HM_ESP_ENCR
       PR_HM_AH_AUTH
       PR_HM_MIP_AUTH
       PR_FM_MIP_AUTH  [3]
       PR_FM_AH_AUTH   [4]
       SS_HM_AH_AUTH
       SS_HM_MIP_AUTH
       SS_MF_MIP_AUTH
       SS_MF_AH_AUTH
     > RSA_pub_MN
     DH_HM_ENCR_pub
   } RSA_priv_HA
   
8.  Addressing Mobile IP hierarchical architectures
   
   One of the requirements identified at the beginning of the draft
   states that support for Mobile IP hierarchical architectures should
   be provided. Although the current version of the document is far from
   exhausting this topic, the proposed protocol addresses the issue.
   
   Taking benefit from the SS_MF_MIP_AUTH distributed by HA during the
   initial (inter-domain) registration to both FA and MN, the latter two
   engage in further negotiations. Thus, FA and MN exchange
   Diffie-Hellman keys by mean of which the distribution of
   SS_FM_MIP_AUTH by FA to MN is secured.
   
  M N                           F A
   |                             |
   { RegReq ----------->
     NAI
     FA-NAI
     PR_MF_AH_AUTH
     PR_MF_MIP_ENCR
     DH_MF_ENCR_pub
   } SS_MF_MIP_AUTH(old - distributed by HA)
   
   { RegRpl <-----------
     NAI
     FA-NAI
     PR_FM_AH_AUTH
     PR_FM_MIP_AUTH
     < SS_FM_AH_AUTH
       SS_FM_MIP_AUTH(new - generated by FA)
       SS_FM_AH_AUTH(new - generated by FA)
     > SS_FM_MIP_ENCR
     DH_FM_ENCR_pub
   } SS_MF_MIP_AUTH(old - distributed by HA)



Floroiu                                                        [Page 11]

INTERNET DRAFT                                          30 November 2001


   MN provides a DH public key (DH_MF_ENCR_pub), so that FA can derive
   SS_MF_MIP_ENCR based on this key and DH_FM_ENCR_priv - the private
   counterpart of DH_FM_ENCR_pub the FA will send in the reply. FA
   generates SS_FM_MIP_AUTH and SS_FM_AH_AUTH and encrypts them with
   SS_MF_MIP_ENCR. Upon receipt of the reply message, MN will be able
   based on DH_FM_ENCR_pub and DH_MF_ENCR_priv to derive the same
   SS_MF_MIP_ENCR which he will use then to retrieve SS_FM_MIP_AUTH and
   SS_FM_AH_AUTH.
 
9.   Interaction with other key exchange protocols

   A mobile node may set up ESP/AH tunnels with correspondent nodes.
   Assuming the mobile node establishes an ESP tunnel back to its home
   agent as well, the traffic between the mobile node and such
   correspondent nodes needs therefore not be sent through the MN-HA ESP
   tunnel, since double encryption requires double processing resources
   and double the amount of control information per datagram.

   This must and can be adjusted using routing mechanisms such as policy
   routing and packet filtering. As soon as the mobile node acquires IP
   level connectivity to its home network it can use key exchange
   protocols such as IKE to negotiate SAs with correspondent nodes. The
   IKE exchange and the locally generated ESP traffic will be sent
   through the Mobile IP IPnIP tunnel rather than through MN-HA ESP
   tunnel. Without going into implementation details it is worth
   mentioning that today operating systems provide the necessary support
   to implement such routing schemes - a sample suite is mentiond in
   [Impl].
 
10.  Certificates considerations
   
   A PKI local to the home domain may be used in order to distribute
   certificates to mobile nodes. HA itself may act as a CA signing these
   certificates..
   
   The HA - FA secure communication relies however on certificates
   issued by a "global" authority.
   
   A discussion on CRL check is beyond the scope of the current version
   of the present draft.
   
   The certificates themselves may be transported along with Mobile IP
   registration messages, since they are not vulnerable to
   man-in-the-middle attacks. However, in order not to end up by having
   fragmented control messages - which are at least that bad as large
   number of control messages - piggybacking certificates should be used
   only when no timely alternate way to retrieve the peer's certificate
   is available.
   





Floroiu                                                        [Page 12]

INTERNET DRAFT                                          30 November 2001


11. Security Considerations

   The protocol does not introduce additional security threats beyond
   those known so far for the case of Mobile IP.

   The protocol provides support for the MN to negotiate authentication
   SA with FA. This breaks attacks based on IP and MAC addresses
   spoofing in the visited domains.

   The protocol provides support for the MN to negotiate encryption SA
   with HA. This enables a MN to encrypt all its data traffic up to the
   home domain.
   
   The shared keys used for authentication are distributed in encrypted
   form by HA and FA following a clear trust model (see chapter 4).
   Moreover the SA proposals themselves may be encrypted as well.

   The encryption keys are established following a Diffie-Hellman
   exchange. PFS is therefore achieved for the MN-FA SA negotiations and
   for the MN-HA data traffic.
   
12. Conclusion
  
   The draft explores the opportunities of making Mobile IP a supporting
   protocol for SA negotiation which would satisfy the security needs of
   mobile nodes.





























Floroiu                                                        [Page 13]

INTERNET DRAFT                                          30 November 2001


References
   
   [Jacobs01] Jacobs, S., Belgard, S., "Mobile IP Public Key Based
	      Authentication", draft-jacobs-mobileip-pki-auth-03.txt,
	      July 2001, work in progress

   [RFC2002] Perkins, C., editor, "IP mobility support", October 1996.

   [RFC2344] Montenegro, G., editor, "Reverse Tunneling for Mobile IP",
             May 1998.

   [RFC3115] Dommety, G., Leung, K., "Mobile IP
	     Vendor/Organization-Specific Extensions", April 2001.

   [DH76]    Diffie, W., Hellman, M. E., "New directions in
	     cryptography", IEEE Transactions on Information Theory,
	     IT-22(6):644-654, November 1976

   [RSA78]   Rivest, R.L., Shamir, A., Adleman, L., "A method for
	     obtaining digital signatures and public-key cryptosystems",
	     Communications of the ACM, 21(2):120-126, February 1978


   [Impl]    Linux Mobile IP/IPsec/routing suite:
             The Netfilter Project - http://netfilter.smaba.org
	     iproute2 utility - ftp://ftp.inr.ac.ru/ip-routing
	     FreeS/WAN - an implementation of IPSEC & IKE for Linux -
	     http://www.freeswan.org
	     Dynamics - an implementation of Mobile IP for Linux -
	     http://www.cs.hut.fi/Research/Dynamics
	     
	     

Author's Address

   Questions about this memo can also be directed to:

     John Floroiu
     FhG Fokus
     31 Kaiserin-Augusta-Allee
     10589 Berlin, Germany
     Phone: +49 (0)30 3463 7144
     Email: floroiu@fokus.fhg.de












Floroiu                                                        [Page 14]