MIP6 Working Group Padmakumar A V Internet Draft Intel Bangalore Expires: June 23, 2007 December 20, 2006 Multi-homed VPN Model for Automating Credit / Debit Cards draft-padmakumar-mip6-mipv6vpnmodelforcreditcards-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 document is a submission of the IETF MIP6 WG. Comments should be directed to the MIP6 WG mailing list, mip6@ietf.org. Copyright Notice Copyright (C) The Internet Society (2006) Padmakumar A V Expires – June 23, 2007 [Page 1] Internet Draft MIPv6-VPN Model for Automating Credit Cards December 2006 Abstract Credit Cards work on a 'trust model'. This document tries to replace this 'Trust Model' with a 'Secure Model' and proposes a way to cryptographically link Credit / Debit card identities to an end device. Conventions used in this document The key words "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 [i]. Table of Contents 1. Introduction...................................................2 2. Overview.......................................................3 2.1 Credit Card / Debit Card Registration......................3 2.2 Transaction Model..........................................4 3. Security Considerations........................................5 4. References.....................................................5 4.1 Normative References.......................................5 4.2 Informative References.....................................5 1. Introduction Credit Cards work on a 'trust model'. This document tries to replace this 'Trust Model' with a 'Secure Model' and proposes a way to cryptographically link Credit / Debit card identities to an end device. This association is achieved by correlating: O End user's certificates O Cryptographically Generated Address (CGA) [5] issued by the bank O IPSec Security associations negotiated between end device and Bank's Home Agents. In this model, credit / debit card details are never revealed to anyone. Even if the credit / debit card user level secrets like passwords, login id are compromised by an attacker, the attacker would not be able to use them. Padmakumar A V Expires – June 23, 2007 [Page 2] Internet Draft MIPv6-VPN Model for Automating Credit Cards December 2006 2. Overview This model suggests a way for banks to view their customers as part of their corporate network connected via a VPN. This will help them to implement corporate level security for their customers. That means before doing any bank transactions, customers MUST have to connect to the banks corporate network. Customer MUST use a Cryptographically Generated IP addresses given by the bank to connect to bank’s network. This address belongs to the bank’s network and this model looks like a home address in Mobile IPv6 [2]. Banks generate CGAs [5] using customer’s public key and bank’s own prefix. This makes the address cryptographically linked to address owner’s Public key. Using this scheme, Bank’s can have up to 2^59 customer identities linked to their IPv6 [1] home prefix. End point devices with MIPv6 and IPSec [3] support can use this address as an additional Home Address and will behave like a multihomed node. All transactions between bank and customers will be IPSec protected by MIPv6 tunnels and reverse tunnels. Nodes inside bank’s networks can be configured not to respond to Return Routability procedure. This prevents the route optimization and all traffic will be forward tunneled or reverse tunneled between MN and HA. 2.1 Credit Card / Debit Card Registration O CGA Generation Banks generate CGAs using customer’s public key and bank’s own prefix. Refer to CGA RFC [RFC3972] for details about CGA generation. Banks can link this CGA to their customers credit/debit card identities. The CGA generated is a permanent address and can be used as long as the private key associated with this address is secure. This address is also a home address and the packet originating with this home address – after binding and VPN enabling – will always be enclosed within another packet with current care of address as the source address and Home agent address as destination address. Padmakumar A V Expires – June 23, 2007 [Page 3] Internet Draft MIPv6-VPN Model for Automating Credit Cards December 2006 The application decides which home address to use. If the application uses this CGA for web browsing, then those packets will get dropped at banks firewalls. O Multi-homed Mobile Nodes Mobile Nodes will use this CGA as an additional home address. This address will be used on need basis. Mobile node will complete home binding with bank’s home agent and setup the MIPv6 tunnels (by disabling subsequent binding process with other correspondent nodes in bank’s network) before it starts any application level bank transactions. Customers MUST not be allowed to communicate with the bank with any other address other than CGAs generated by the bank. All messages sent from this address (CGA) have to be signed by CGA signature. Mobile Nodes disable subsequent binding procedure with Correspondent Nodes in the Bank’s network to gain the VPN behavior. This can also be achieved by disabling MIPv6 functionality at CN side. This would results in all communications between Correspondent nodes and Mobile node to flow through IPSec tunnels between Home Agent and Mobile Node. This will create the expected VPN behavior for the access model. 2.2 Transaction Model Merchant will certify the bill generated by him and forwards this to the Customer’s device. At this stage customer device will initiate binding with his Bank’s Home Agent and setup MIPv6 tunnels. Additional messages have to be defined for standardizing Merchant Customer communications. After establishing VPN tunnels with Banks, customer can forward this bill to the bank for payment. Banks can have additional application level authentications at this stage for added security. While establishing VPN tunnels Banks could verify the customer’s identity based on the CGA that he had used for the binding. Only authorized customers who have a CGA issued by the bank will be able to establish this VPN tunnel. Banks can have additional application level security, like login etc. on top of this. Banks verify the account details and pay the bill by signing it. The signed bill will be sent back to the customer and customer will forward this one to the merchant. Padmakumar A V Expires – June 23, 2007 [Page 4] Internet Draft MIPv6-VPN Model for Automating Credit Cards December 2006 Merchants can verify bank’s digital signature and accepts the payment. An additional level of authentication can be achieved by having customers signing it. 3. Security Considerations It is important to note that the credit / debit card identities are never revealed to anyone during the entire operation. Card identities are utmost secret and there exists rare chances of someone stealing the card details. If someone really wants to misuse the details then he must: 1. Get the private key associated to the address owner. 2. He has to know the CGA associated to address owner’s Public key. 3. He has to overcome the application level security of the bank. 4. He has to overcome the default authentication mechanisms offered by the end device. 5. No one really benefits by knowing application level credentials like password and login id alone because he can not establish VPN tunnels and hence can not do any transactions with the Bank without knowing all of the above. 4. References 4.1 Normative References [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. 4.2 Informative References [4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [5] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005 Padmakumar A V Expires – June 23, 2007 [Page 5] Internet Draft MIPv6-VPN Model for Automating Credit Cards December 2006 Acknowledgments The author would like to thank Sridhar Rajagopal, Rajeev D Muralidhar and Chinku Miandad for their input and discussions. Author's Addresses Padmakumar A V Intel Bangalore Email: Padmakumar.a.vasudevan.pillai@intel.com Padmakumar A V Expires – June 23, 2007 [Page 6] Internet Draft MIPv6-VPN Model for Automating Credit Cards December 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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. 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. Intellectual Property 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. 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Padmakumar A V Expires – June 23, 2007 [Page 7]