Internet DRAFT - draft-qiu-mipshop-mn-map-security

draft-qiu-mipshop-mn-map-security





Network Working Group                                          Feng BAO
INTERNET-DRAFT                                              Robert DENG
Expires: April 15, 2006                                        Ying QIU
Network Working Group                                     Jianying ZHOU
                                   
                                                       October 16, 2005



              A Scheme for the Security between Mobile Node
          and Mobility Anchor Point in Hierarchical Mobile IPv6
                <draft-qiu-mipshop-mn-map-security-00.txt>


Status of this Memo

    By submitting this Internet-Draft, each author represents that
    any applicable patent or other IPR claims of which he or she is       
    aware have been or will be disclosed, and any of which he or she       
    becomes aware will be disclosed, in accordance with Section 6 of       
    BCP 79. 

    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 

    This Internet-Draft will expire on April 15, 2006. 


Copyright Notice 

    Copyright (C) The Internet Society (2005).  All Rights Reserved. 










Expires: April 15, 2006                                       [Page 1]


Internet Draft             MN-MAP Security             October 16, 2005 



Abstract

   The document proposes the solution for the security between mobile 
   nodes and MAPs. According to the requirements of the security 
   statement in the working group, two modes for two scenarios are 
   considered in the draft:  authentication-only mode and 
   authentication and authorization mode.





Table of Contents

   1.  INTRODUCTION ................................................. 2
   2.  NOTATIONS .................................................... 4
   3.  AUTHENTICATION-ONLY MODE ..................................... 4
   4.  AUTHENTICATION AND AUTHORIZATION MODE ........................ 6
   5.  SECURITY CONSIDERATIONS ...................................... 9
   6.  CONCLUSION ................................................... 9
   7.  ACKNOWLEDGEMENTS ............................................. 9
   8.  REFERENCES ................................................... 9
   9.  AUTHORS' ADDRESSES .......................................... 10
   Intellectual Property and Copyright Statements .................. 10


 
1. INTRODUCTION

   In the protocol of HMIPv6 [1], the concept of Mobility Anchor Point
   (MAP) is introduced. MAP is a router located in a domain visited by
   the mobile nodes. MAP provides the localized mobility management for
   the visiting mobile nodes.

   Every mobile node bundles three addresses: Home Address (HoA), 
   Regional Care-of-Address (RCoA), and On-Link Care-of-Address (LCoA). 
   RCoA is an address on the MAP subnet, and obtained by the mobile 
   Node (MN) from the visited domain. LCoA is configured on a MN's 
   interface based on the prefix advertised by its default router. In 
   fact, it is a care-of-address in normal MIPv6. Figure 1 shows the 
   architecture of HMIPv6. 











 Expires: April 15, 2006                                       [Page 2]


Internet Draft             MN-MAP Security             October 16, 2005 
 
 
                    +----+      +----+
                    | HA |      | CN |
                    +----+      +----+
                       |          |
                       +---+  +---+     
                           |  |
                         +-------+ 
                         |  MAP  | RCoA
                         +-------+  
                           |  |
                       +---+  +---+     
                       |          |
                    +-----+    +-----+
              LCoA1 | AR1 |    | AR2 | LCoA2
                    +-----+    +-----+
                 +----+     
                 | MN |   movement   
                 +----+  --------->     
     
         Figure 1. Hierarchical MIPv6 domain. 


   In HMIPv6, when CN sends packets to MN's RCoA, MAP intercepts the 
   packets and forwards the packets to MN's LCoA. However, as the 
   binding update (BU) message from MN to MAP is not authenticated when 
   MN changes its Access Router (AR), attackers can easily launch 
   "Redirect Attacks", i.e., the attacks which redirect the traffic 
   from MAP to fake destinations chosen by the attackers. On the other 
   hand, in some scenarios, the MAP is only open to the authorized 
   users.

   Two security models are described in the email discussion [2]:

   (1) Authentication-only model: In this model, a MAP only need to 
   ensure that the same MN is sending the BUs to the MAP. It is not 
   necessary for the MN to prove that it is authorized to use a MAP to
   manage its mobility. 

   (2) Authentication and Authorization model: In this model, the MAP 
   and the MN need to know that the other end is "trusted". The MAP 
   also needs to know if the MN is authorized for using it. 
  

   In this document, we propose a protocol to protect the BU messages 
   from MN to MAP as well as the method of authenticating MN's 
   identification without the global PKI.







Expires: April 15, 2006                                       [Page 3]


Internet Draft             MN-MAP Security             October 16, 2005 
  
 
2. NOTATIONS 

   The notations used throughout this paper are listed below for easy 
   reference:

   h():  a one-way hash function, such as MD5 or SHA.
   prf(k, m):  a keyed pseudo random function -- often a keyed hash 
      function. It accepts a secret key k and a message m, and 
      generates a pseudo random output. This function is used for both
      message authentication and cryptographic key derivations.
   e(k ,m):  encryption of message m with a secret key k.
   Px/Sx:  a public and private key pair of node X in a digital 
      signature scheme such as RSA or DSS.
   Sig(Sx, m):  node X's digital signature on a message m using a 
      private key Sx. 
   m|n: concatenation of two messages m and n.


3. AUTHENTICATION-ONLY MODE 

   In many scenarios the managers of MAP would like to provide free 
   connection for their customers, such as in conferences, hotels, 
   coffee bars, etc. In these scenarios, the MAP only needs to ensure 
   any binding update messages (BU) are from the claimed mobile nodes 
   (MN). The MAP not needs to check if the MNs have the right to 
   connect the MAP [2].

   Figure 2 shows message exchange between a MN and a MAP in the 
   Authentication-only mode. Below is a detailed description of the 
   protocol.  

                MN            MAP               
                |              |                 
                |==COOKIE0====>|       
                |              |       
                |<===COOKIE1===|       long term 
                |              |       messages
                |====BU_1=====>|       
                |              |       
                |<=====BA_1====|       
                |              |       
         ------------------------------------------
                |              |       
                |=====BU_i====>|    
                |              |       short term
                |<=====BA_i====|       message for BU
                |              |       
                |              |    

         Figure 2. Message exchange in Authentication-only mode 


Expires: April 15, 2006                                       [Page 4]


Internet Draft             MN-MAP Security             October 16, 2005 


   When a mobile node MN roams and enters to the domain of MAP, MN 
   creates a cookie C0 and sends

        COOKIE0 = {Src=LCoA, Des= MAP, Opt=HoA, C0}

   to MAP. In reply, MAP generates a nonce N1 and a cookie C1, and 
   sends to MN the message

        COOKIE1 = {Src=MAP, Des=LCoA, Opt=HoA, C0, C1, N1}.

   The use of cookies during the key exchange is a weak form of 
   protection against an attacker who generates a series of request 
   packets, each with a different spoofed source IP address, and sends
   them to a protocol party. For each request, the protocol party will 
   first validate cookies before performing computational expensive 
   public key cryptographic operations and memory allocation.

   Upon receiving COOKIE1, MN checks on the validity of C0, generates a 
   nonce N2 and replies MAP with

        BU_1 = {Src=LCoA, Des=MAP, Opt=HoA, C0, C1, N1, N2, 
                TS, SIG_MN, Cert_MN},

   where SIG_MN is MN¡¯s signature signed by its private key SK_MN

        SIG_MN = Sig(SK_MN, LCoA|HoA|MAP|N1|N2|TS).

   Note that the values of N1 and N2 are included in the signature 
   SIG_MN in order to counter replay of old signatures and to resist 
   chosen message attacks to the signature scheme, respectively. TS is 
   a time stamp. This time stamp does not have to be checked by the 
   recipient during the message exchange. It will be used to trace back 
   the culprit should a malicious mobile node flooding attack have 
   occurred. The Cert_MN is the public key certificate of the mobile 
   node that is issued by the MN¡¯s home agent and is not necessary to 
   be verified in this scenario.

   When MAP receives BU_1, it validates the cookies, extract MN¡¯s 
   public key from the certificate Cert_MN, and verify the signature. 
   If all the validations and checking are positive, MAP assigns the 
   RCoA to the MN and creates an entry for the MN, which includes HoA, 
   RCoA, LCoA, TS, certificate, etc. Then MAP adds the entry to its BU 
   cache. Finally, MAP sends to MN the binding acknowledgement

        BA_1 = {Src=MAP, Des=LCoA, Opt=HoA, RCoA, C0, C1, N1, N2},

   Since the binding acknowledgement is not important to MN in the 
   scenarios, the BA message is not necessary to do any secure process.

   The process for the following binding updates in the same domain is 
   simple. When MN moves to a new AR and gets a new LCoA, MN just needs 
   to send MAP the binding update message

Expires: April 15, 2006                                       [Page 5]


Internet Draft             MN-MAP Security             October 16, 2005 


        BU_i = {Src=LCoA, Des=MAP, Opt=HoA, old_LCoA, TS, SIG_MN_i}
   where 
        SIG_MN_i = Sig(SK_MN, LCoA|MAP|HoA|old_LCoA|TS).

   The reason of binding the old LCoA is to avoid the reply attack.

   After receiving the BU_i, MAP retrieves the entry based on HoA from 
   its binding cache and gets the Cert_MN. If the verification of the 
   signature is positive, MAP accepts the new LCoA and updates its 
   binding cache. Meanwhile MAP replies MN

        BA_i = {Src=MAP, Des=LCoA, Opt=HoA}



4. AUTHENTICATION AND AUTHORIZATION MODE 
   
   In some scenarios, the MAP and MN need to know the other end is 
   ¡°trusted¡± and the MAP also need to know if the MN is authorized for 
   using it [2].

   Figure 3 shows message exchange among a MN, a MAP and MN¡¯s HA in the 
   Authentication-Authorization mode. Below is a detailed description 
   of the protocol.  

  
                MN            MAP             HA   
                |              |              |    
                |===COOKIE0===>|              |    
                |              |              |    
                |<===COOKIE1===|              |    long term 
                |              |              |    messages
                |====BU_1=====>|              |    
                |              |==REQ_Cert===>|              |    
                |              |              |    
                |              |<===REP_Cert==|    
                |<====BA_1=====|              |    
                |              |              |    
         ------------------------------------------------------
                |              |              |    
                |====BU_i=====>|              |    
                |              |              |    short term
                |<=====BA_i====|              |  message for BU
                |              |              |    
                |              |              | 

    Figure 3. Message exchange in Authentication and Authorization mode


   When a mobile node MN roams and enters to the domain of MAP, MN 
   creates a cookie C0 and sends


Expires: April 15, 2006                                       [Page 6]


Internet Draft             MN-MAP Security             October 16, 2005 


        COOKIE0 = {Src=LCoA, Des= MAP, Opt=HoA, C0}

   to MAP. In reply, MAP generates a nonce N1 and a cookie C1, and 
   sends

        COOKIE1 = {Src=MAP, Des=LCoA, Opt=HoA, C0, C1, N1}

   to MN. 

   The use of cookies during the key exchange is a weak form of 
   protection against an attacker who generates a series of request 
   packets, each with a different spoofed source IP address, and sends
   them to a protocol party. For each request, the protocol party will 
   first validate cookies before performing computational expensive 
   public key cryptographic operations and memory allocation. These two
   messages are similar to the authentication-only mode.

   Upon receiving COOKIE1, MN checks on the validity of C0, generates a 
   nonce N2 and a Diffie-Hellman secret value x < p, computes its 
   Diffie-Hellman public value g^x and its signature

        SIG_MN = Sig(SK_MN, LCoA|HoA|MAP|g^x|N1|N2|TS)

   using MN¡¯s private key SK_MN, where TS is a time stamp. This time 
   stamp does not have to be checked by the recipient during the 
   message exchange. It will be used to trace back the culprit should a 
   malicious mobile node flooding attack have occurred. Note that the 
   values of N1 and N2 are included in the signature SIG_MN in order to 
   counter replay of old signatures and to resist chosen message 
   attacks to the signature scheme, respectively. Finally, MN replies 
   MAP with the first binding update message

        BU_1 = {Src=LCoA, Des=MAP, Opt=HoA, C0, C1, N1, N2, 
                g^x, TS, SIG_MN, Cert_MN},

   where 
        Cert_MN = {HoA, PK_MN, Valid_Iinterval, SIG_HA}.

   is the public key certificate of the mobile node which is issued by 
   its home agent. SK_MN and PK_MN are the private and public key pair 
   for MN. 

   When MAP receives BU_1, if the validation of the cookies is positive, 
   MAP then begins to verify the MN's public key certificate Cert_MN by 
   public key of MN¡¯s home agent. If MAP does not have the HA¡¯s 
   certificate in its cache, MAP will send a requesting message for 
   certificate to HA,

        REQ_Cert = {Src=MAP, Des=HA, request_cert}.



	
Expires: April 15, 2006                                       [Page 7]


Internet Draft             MN-MAP Security             October 16, 2005 


   Then, HA will return to MAP its public key certificate issued by a 
   trusted CA,

        REP_Cert = {Src=HA, Des=MAP, Cert_HA}.

   Upon getting HA's public key certificate and verifying the 
   certificate through the trusted CA, MAP can verify HA's signature
   SIG_HA and then trust the MN's public key certificate Cert_MN. With 
   the Cert_MN, MAP can further verify MN's signature. After double 
   checking the equality of home link's subnet prefix string embedded 
   in both Cert_HA and HoA, MAP can finally trust the first MN's new 
   binding update message BU_1 and create an entry for the MN and add
   the entry to MAP¡¯s binding cache. 

   MAP next generates its Diffie-Hellman secret value y < p. It then 
   computes its Diffie-Hellman public value g^y, the Diffie-Hellman 
   master key 

        k_DH = (g^x)^y, 

   and a session secret 

        k_secret = prf(k_DH, N1|N2 )

   for future security purpose.

   Then MAP assigns a RCoA to MN and sends to MN the binding 
   acknowledgement

        BA_1 = {Src=MAP, Des=LCoA, Opt=HoA, RCoA, 
                C0, C1, g^y, SIG_MAP, Cert_MAP},

   where
        SIG_MAP = Sig(SK_MAP, MAP|LCoA|HoA|RCoA|g^y|BU_1)
   and
        Cert_MAP = {MAP, PK_MAP, Valid_Interval, SIG_CA} 

   is MAP's certificate from a trusted CA, SK_MAP and PK_MAP is the 
   security key pair of MAP. Therefore, both parties MN and MAP could 
   identify each other.

   After getting this message, MN first validates the cookies, 
   calculates the Diffie-Hellman master key k_DH = (g^y)^x and the 
   session secret k_master = prf(k_DH, N1|N2) for future security 
   purpose. Then MN also creates an entry for this channel and stores 
   the entry into its binding cache.

   The process for following binding update in the same domain is 
   simple. When MN moves to a new AR and gets a new LCoA, MN just needs 
   to send MAP the binding update message



Expires: April 15, 2006                                       [Page 8]


Internet Draft             MN-MAP Security             October 16, 2005 


        BU_i = {Src=LCoA, Des=MAP, Opt=HoA, old_LCoA, TS, SIG_MN_i}
   where 
        SIG_MN_i = Sig(SK_MN, LCoA|MAP|HoA|old_LCoA|TS).

   The reason of binding the old LCoA is to avoid the reply attack.

   After receiving the BU_i, MAP retrieves the entry based on HoA from 
   its binding cache and gets the Cert_MN. If the verification of the 
   signature is positive, MAP accepts the new LCoA and updates its 
   binding cache. Meanwhile MAP replies MN

        BA_i = {Src=MAP, Des=LCoA, Opt=HoA, SIG_MAP_i}
   where
        SIG_MAP_i = Sig(SK_MAP, MAP|LCoA|HoA|BU_i).



5. SECURITY CONSIDERATIONS

   The proposal consider the security binding update between mobile 
   nodes and the mobility anchor points.

 

6. CONCLUSION   

   The document proposes the solution for the security between mobile 
   nodes and MAPs as well as the method of authenticating MN¡¯s 
   identification without the global PKI. In the proposal, two security 
   modes are considered for different scenarios.



7. ACKNOWLEDGEMENTS    


8. REFERENCES

   [1]  H. Soliman, C. Castelluccia, K. El Malki, "Hierarchical Mobile 
        IPv6 Mobility Management (HMIPv6)", RFC 4140, Aug. 2005.
   [2]  Discussions in MIPSHOP working group, July 2005. 
   [3]  D. B. Johson and C. Perkins, "Mobility Support in IPv6", 
        RFC 3775, June 2004.
   [4]  F. Bao, R.Deng, Y. Qiu, J.y Zhou, "Certificate-based Binding 
        Update Protocol (CBU)", draft-qiu-mip6-certificated-binding-
        update-03.txt, March 2005







Expires: April 15, 2006                                       [Page 9]


Internet Draft             MN-MAP Security             October 16, 2005 


9. AUTHORS' ADDRESSES

      Feng BAO
      Institute for Infocomm Research
      21 Heng Mui Keng Terrace
      Singapore 119613
      Phone: +65-6874-8456
      EMail: baofeng@i2r.a-star.edu.sg

      Robert DENG
      Singapore Management University
      469 Bukit Timah Road
      Singapore 259756
      Phone: +65-6822-0920
      EMail: robertdeng@smu.edu.sg

      Ying QIU
      Institute for Infocomm Research
      21 Heng Mui Keng Terrace
      Singapore 119613
      Phone: +65-6874-6742
      EMail: qiuying@i2r.a-star.edu.sg

      Jianying ZHOU
      Institute for Infocomm Research
      21 Heng Mui Keng Terrace
      Singapore 119613
      Phone: +65-6874-6668
      EMail: jyzhou@i2r.a-star.edu.sg




INTELLECTUAL PROPERTY STATEMENT

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed 
   to pertain to the implementation or use of the technology described 
   in this document or the extent to which any license under such 
   rights might or might not be available; nor does it represent that 
   it has made any independent effort to identify any such rights.  
   Information on the procedures with respect to rights in RFC 
   documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository 
   at http://www.ietf.org/ipr.



Expires: April 15, 2006                                       [Page 10]


Internet Draft             MN-MAP Security             October 16, 2005 


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on 
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
   IMPLIED,INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.
























Expires: April 15, 2006                                       [Page 11]