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]