INTERNET-DRAFT M. Linehan, G. Tsudik IBM Research July, 1995 (Expires 1/96) Internet Keyed Payments Protocol (iKP) Status of this Memo This document is an Internet-Draft. 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." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Please send comments to the editors (see last page for email addresses) or to the e-payment mailing list at . Additional information on iKP and electronic commerce in general is available via WWW at the URL This document describes iKP as of June 23, 1995. Abstract iKP - the Internet Keyed Payments protocol - defines an architecture for secure payments involving three or more participants. "Architecture" means that iKP specifies a base protocol with a number of options that can be selected to meet varying business or security requirements. "Secure payments" means that iKP employs cryptographic techniques to minimize potential risks concerning payments over the open Internet. "Three or more parties" means that iKP addresses scenarios in which buyers and sellers invoke third-parties such as credit card systems or banks to accomplish payment transactions. Acknowledgments This document represents a joint effort by the following contributors: Mihir Bellare, Juan Garay, Ralf Hauser, Amir Herzberg, Hugo Krawczyk, Mark Linehan, Michael Steiner, Gene Tsudik, and Michael Waidner. Linehan, Tsudik Expires Jan. 1996 [Page 1] INTERNET DRAFT Internet Keyed Payments Protocol July 1995 1. Introduction A fast-growing trend on the Internet is the ordering and provision of information, goods and services via World Wide Web, electronic mail and other means. A key issue for this "electronic commerce" is how payments may be accomplished efficiently, reliably and securely. A number of organizations have addressed this issue by establishing proprietary payment systems which vary widely in design, performance and security features. This clearly calls for standardization. Payments in the non-electronic world are accomplished via cash, checks, credit and debit cards, money and postal orders, and other mechanisms. Electronic equivalents of all these payment systems are being developed. iKP addresses a subset of these mechanisms that involve direct payment transfers among accounts maintained by banks and other financial organizations. This includes credit and debit card transactions as well as electronic check clearing, but excludes electronic cash and money orders (as these require very different mechanisms.) The goal of iKP is to enable Internet-based secure electronic payments while utilizing the existing financial infrastructure for payment authorization and clearance. The intent is to avoid completely, or at least minimize, changes to the existing financial infrastructure outside the Internet. Payment systems incorporate tradeoffs among cost, timeliness, efficiency, reliability, risk management and convenience. For example, some systems attempt to suppress fraud by inducing payment delays. Security in payment systems means minimizing risk to a level acceptable to participants. Risk management in existing systems is accomplished by varying combinations of technology, payment practices, insurance, education, laws, contracts, and enforcement. iKP utilizes cryptographic technology in order to accomplish a new tradeoff among these competing considerations. Public-key cryptography is adopted in order to support, in a scalable manner, payments among parties who have no pre-existing relationship. To facilitate export of iKP, the use of encryption is restricted to the protection of sensitive data (such as PINs and account numbers.) To provide broad implementation flexibility, the iKP protocol is defined such that it can be implemented in any combination of software and hardware. Many existing cryptographic protocols, such as SSL (2), SHTTP (3), PEM (4), MOSS (5), and IPSP (7), provide security functions for pairwise communication. For example, SSL provides privacy and authentication (but no non-repudiation) between clients and servers of application-layer protocols such as HTTP and FTP. Many payment systems involve three or more parties, i.e., buyer, seller and bank. In such systems, certain types of risk can be ameliorated by sharing sensitive information only among a subset of the parties. For example, credit card fraud can be reduced by transmitting credit card account numbers between buyers and banks without revealing them to sellers. This motivates the development of new protocols such as iKP rather than employing multiple pair-wise secure channels buyer<->seller, seller<->bank and buyer<->bank. Linehan, Tsudik Expires Jan. 1996 [Page 2] INTERNET DRAFT Internet Keyed Payments Protocol July 1995 A more fundamental motivation for iKP is to define and attempt to standardize the mechanisms and the semantics for secure multi-party payments. Such standardization is key to enabling individuals and organizations throughout the world to produce products and services that can be expected to interoperate. iKP does not address in any way the terms and conditions associated with banking services. Prices, participation rules, settlement practices, and similar issues are matters for market competition and/or government regulation, rather than engineering design. 2. Protocol Participants The iKP protocols are designed to allow buyers to order goods, services, or information over the Internet, while relying on existing secure financial networks to implement the necessary payments, as suggested in the figure below. +--------+ +--------+ | Issuer |--------------------->|Acquirer| | | financial networks | | | I |<---------------------| A | +--------+ +--------+ /|\ | Internet | | or private | \|/ networks +--------+ +--------+ | Buyer |*********************>| Seller | | | Internet | | | B |<*********************| S | +--------+ +--------+ Participants in the iKP protocol are: 1) buyer who needs to pay for something via the Internet, 2) seller who wishes to receive payment, 3) seller's bank (or equivalent organization), and, 4) buyer's bank. In the context of today's credit card systems, seller's bank is called an acquirer because it acquires paper charge slips from sellers. Buyer's bank is called an issuer because it issues charge cards to buyers. In the context of iKP, an acquirer functions as a gateway between the Internet and existing financial networks that support transactions between banks. An acquirer maps the iKP protocol conducted on the Internet to the protocols utilized on the financial networks. iKP requires no changes in the communication between the issuer and acquirer banks. Communications between buyer and seller are assumed to occur over the public Internet. iKP is specifically designed to address security issues that arise in this environment. Communications between seller and acquirer may be via the Internet or over private channels. iKP may be used in either case, but it Linehan, Tsudik Expires Jan. 1996 [Page 3] INTERNET DRAFT Internet Keyed Payments Protocol July 1995 specifically provides for security concerns that arise when the Internet is also utilized for this purpose. Secure financial networks already exist to connect acquirers to issuers. Consequently, iKP assumes that adequate security is already in place between these parties. 3. Certificate Management The iKP technology is based on public-key cryptography (e.g. RSA.) Depending on requirements, an electronic payment transaction using iKP may involve one, two, or three public keys. In all cases, the acquirer has a public-private key pair for receiving confidential information such as buyer account numbers and for signing authorization messages. Sellers may also have key pairs for signing payment requests and purchase confirmations. Buyers can have key pairs for signing (authorizing) payment transactions. The acquirer is the only entity that both signs and receives confidential data. An acquirer may have two public/private key-pairs: one for signatures and one for encryption. However, both key-pairs may be validated by a single certificate. The recipient of any signed message must hold a copy of the public key required to validate the signature. Specifically, seller and buyer must both have a copy of the acquirer's public key in order to validate the acquirer's signature of the authorization method. The buyer also needs a copy of (a different) public key of the acquirer for encrypting the account number and related information. If the seller's signature of the invoice is implemented, both buyer and acquirer need to have the seller's public key. If the buyer signature of the payment is implemented, the acquirer (and, sometimes, the seller) need to have the buyer's public key. Public keys are distributed to the participants in the form of certificates signed by some authority. Certificates can be distributed in two ways: 1) before executing iKP, e.g., during browsing or out-of-band, or 2) in the course of iKP execution, as part of iKP option fields. In the former case, certificates may be cached from previous payment transactions, provided as part of HTML fields, transmitted via electronic mail, or communicated by any other means desired. Such mechanisms are outside the definition of iKP. The establishment of the certificate authority, and the communication of the authority's "root" public key is also outside this protocol. One possible design is for each credit card system to have a certificate authority with a well-known root public key. This authority would sign certificates for all acquirers, sellers, and buyers who utilize the credit card system. Alternatively, some other well-trusted organization could issue certificates for any or all iKP participants. Linehan, Tsudik Expires Jan. 1996 [Page 4] INTERNET DRAFT Internet Keyed Payments Protocol July 1995 4. Negotiation vs Payment Any purchase transaction involves (at least) three phases: 1) negotiation of the purchase terms and other details, 2) actual payment, and 3) order fulfillment/delivery. iKP addresses only (2). iKP is the electronic equivalent of the paper charge slip, signature, and submission process; or of a paper check with online funds verification. It comes after the negotiation is completed. iKP takes input from the negotiation process (payment amount, order description, payment method, etc.) and causes the payment to happen via a three-way communication among the buyer, seller, and acquirer. Negotiation is a bilateral conversation between the buyer and seller that may be implemented in many ways, e.g., via HTTP using a WWW browser and server, electronic mail, paper catalog for the offer from the seller and electronic mail for the order from the buyer. and other ways that have not yet been popularized. The negotiation process addresses not only what is ordered (x units of these widgets and y units of those) but the terms of the order (prices, delivery addresses, schedules, credit card type), and the method of payment (cash, paper check, digital cash, iKP, whether a receipt is required, etc.). Irrespective of the means used to conduct negotiation, the buyer -- at some point -- initiates payment. This is the point when negotiation ends and iKP starts. The data required by iKP in the buyer system are: acquirer's public key, seller's public key (if implemented), buyer's account number (BAN in the protocol description, see below), buyer's public/private key pair (if implemented), buyer's PIN (if implemented), payment amount and currency ($$), and the description of the order (DESC). The data required by iKP in the seller system are: acquirer's public key, seller's ID, seller's public/private key (if implemented), payment amount and currency ($$), and the description of the order (DESC). From the perspective of iKP, order description (DESC) is an opaque string that is incorporated via a hash into the protocol to bind the description to the payment. "Opaque" means that iKP does not interpret the contents of the description. The only requirement of iKP is for the description to contain all relevant details of the transaction (ordered goods, delivery address, payment terms, etc.), and that both buyer and seller possess exactly the same opaque string. 5. iKP as an Architecture iKP is a general architecture that accommodates a variety of payment methods interaction by making certain message flows and fields optional. This document defines what types of security are supported by various combinations of options. Any particular use of iKP (e.g. iKP for credit cards) will require a detailed specification for that particular use. Linehan, Tsudik Expires Jan. 1996 [Page 5] INTERNET DRAFT Internet Keyed Payments Protocol July 1995 iKP is intended for use with a number of different communications channels among the participants, e.g., HTTP, SHTTP, electronic mail. Applications of the iKP architecture to specific communications environments are not discussed in this document. It is envisaged that other documents will define the syntax of iKP for each desired communications method. Hopefully there will be one syntax for each communications channel regardless of the purchase style (e.g. credit card versus debit card). 6. Security Requirements We consider a range of requirements for each party directly involved in the iKP payment process: acquirer, seller, and buyer. The list below is not meant to be exhaustive. 6.1 Issuer/Acquirer Requirements The issuer and the acquirer are assumed to enjoy some degree of mutual trust. Moreover, infrastructures enabling secure communication between these parties are already in place. Therefore, the requirements of the issuer and the acquirer are considered jointly. [REQ A1] Proof of Transaction Authorization by Buyer. When debiting an account, the acquirer must have proof that the owner of the account has authorized the payment. [a.] Weak Proof --- authenticates buyer to acquirer but does not provide non-repudiation [b.] Strong Proof --- provides non-repudiation, i.e., can be used to resolve disputes between the buyer and the payment system provider. [REQ A2] Proof of Transaction Authorization by Seller. When acquirer authorizes payment to seller, acquirer must have proof that seller is willing to accept the payment. [a.] Weak proof [b.] Strong proof. 6.2 Seller Requirements [REQ S1] Proof of Transaction Authorization by Acquirer. Seller needs proof that acquirer authorized the payment. [a.] Weak proof [b.] Strong proof. [REQ S2] Proof of Transaction Authorization by Buyer. Seller requires proof that buyer authorized the transaction. [a.] Weak proof [b.] Strong proof. Linehan, Tsudik Expires Jan. 1996 [Page 6] INTERNET DRAFT Internet Keyed Payments Protocol July 1995 [REQ S3] Impossibility of Unauthorized Payment. It must not be possible for payment to occur without seller's authorization. [a.] Impossibility -- unauthorized payments are impossible provided acquirer is not compromised. [b.] Disputability -- even if the acquirer is compromised, seller can prove not having authorized the payment. 6.3 Buyer Requirements [REQ B1] Impossibility of Unauthorized Payment. It must not be possible to charge the buyer's account without possession of the account number itself, (optional) PIN, and (if applicable) buyer's secret signature key. [a.] Impossibility -- unauthorized payments are impossible provided acquirer is not compromised. [b.] Disputability -- even if the acquirer is compromised, buyer can prove not having authorized the payment. [REQ B2] Proof of Transaction Authorization by Acquirer Buyer demands proof that the acquirer authorized the transaction. [REQ B3] Certification and Authentication of Seller. Buyer needs proof that seller is accredited by some acquirer (this could be considered as a kind of guarantee for the trustworthiness of the seller.) [REQ B4] Receipt from Seller. Buyer needs proof that seller received payment and, thus, promises to deliver the goods. [a.] Weak proof [b.] Strong proof. [REQ B5] Transaction/Order Privacy [a.] Both buyer and seller want to maintain the privacy of the ordering information from eavesdroppers on the B<->S channel. [b.] Both buyer and seller want to hide the description of the goods/services from the acquirer and from eavesdroppers on the seller<->acquirer channel. [REQ B6] Anonymity Buyer want to protect its identity from both eavesdroppers and sellers. This includes the INABILITY of seller to correlate multiple payment transactions by the same buyer. [REQ B7] Commitment on behalf of Seller Buyer wants to solicit binding offers from multiple sellers (browsing) before choosing to make payment. Linehan, Tsudik Expires Jan. 1996 [Page 7] INTERNET DRAFT Internet Keyed Payments Protocol July 1995 6.4 Non-Requirements The following are considered out of scope for the iKP protocols: [NREQ 1] Untraceability of payment with respect to the payment system (An iKP acquirer can identify both buyer and seller.) [NREQ 2] Real-time (small payment) capability iKP cannot guarantee a certain throughput. This means that there is no support for small real-time payments. [NREQ 3] Secure Delivery of goods/services Being a payment protocol, iKP is not concerned with delivery of goods/services. [NREQ 4] Negotiations of payment amount (price) and other contractual details. [NREQ 5] Protection from traffic analysis protection and covert channels iKP is not a "bulk" security solution; it does not provide secrecy for information that is not considered sensitive in the context of a payment transaction. 7. iKP Unified Protocol Description As described in Section 4, before iKP starts the buyer and seller are assumed to have agreed on the description of the order, the price/currency and the payment method. (In practice, it is also possible for the buyer to share this information with the seller as part of the optional fields of the INITIATE message. However, this is outside the scope of iKP.) 7.1 High-Level Flows +--------+ +--------+ +--------+ | Buyer | | Seller | |Acquirer| +--------+ +--------+ +--------+ INITIATE --------------------------------> INVOICE <-------------------------------- PAYMENT --------------------------------> AUTH-REQUEST --------------------------> AUTH-RESPONSE <-------------------------- CONFIRM <-------------------------------- Linehan, Tsudik Expires Jan. 1996 [Page 8] INTERNET DRAFT Internet Keyed Payments Protocol July 1995 7.2 Atomic Fields/Symbols A, S, B | Protocol Participants: Acquirer, Seller, Buyer [...] | Optional fields PK_Z/SK_Z | Z's public/private key-pair; Z in {A,S,B} E_A | Encryption (with integrity) under PK_A. Takes | message M to be encrypted and a random SALT and | produces a ciphertext E_A(M;SALT). See the | discussion in the "Use of Encryption" section, below. S_Z(TXT) | Signature under Z's private key SK_Z; Z in {A,S,B} | NOTE: S_Z(TXT) does NOT include TXT in the clear SALT_B | Random number generated by B; used to ensure privacy | of order information on the S <-> A link V | Random number generated by seller; used to verify the | the binding from the CONFIRM message back to the | INVOICE and PAYMENT messages. $$ | Amount and currency DATE | Seller's date/time stamp NONCE_S | Seller's nonce (counter or random number) used | as challenge in replay protection. NONCE_S should be | unique to ensure the freshness of each INVOICE and | PAYMENT; there is no need for randomness. NONCE_S can | be implemented with a counter. ID_S | Seller id. This identifies seller to acquirer. TID_S | Transaction ID. This is an identifier chosen by | seller which uniquely identifies the context | of this transaction from the seller's point of view. H(.) | Strong one-way hash function DESC | Description of purchase/goods as an opaque string BAN | Buyer's Account Number (Eg. credit card No.) PIN | Optional buyer's PIN R_B | Random number chosen by B to form B_ID. It must be | random (not just unique) in order to serve as proof | by the buyer that the seller agreed to the payment. | See section on disputes below. B_ID | One-time buyer ID which uniquely identifies B; | computed as B_ID=H(R_B,BAN). Y/N | Response from the clearing network: YES/NO or | authorization code. TEXT_j | Optional information that can accompany the flows. (j=0,1,...) | For example, can be used to carry context identifiers. 7.3 Composite Fields/Symbols COMMON | $$, ID_S, TID_S, DATE, NONCE_S, B_ID, | H(DESC,SALT_B),[H(V)] CLEAR | ID_S, TID_S, DATE, NONCE_S, H(COMMON), H(DESC,SALT_B) SLIP | $$, H(COMMON), BAN, R_B, [PIN] SIG_S | S_S( H(COMMON) ), [H(V)] SIG_B | S_B( H(E_A(SLIP)), H(COMMON) ) SIG_A | S_A( Y/N, H(COMMON) ) Linehan, Tsudik Expires Jan. 1996 [Page 9] INTERNET DRAFT Internet Keyed Payments Protocol July 1995 7.4 Flow contents +--------+ +--------+ +--------+ | Buyer | | Seller | |Acquirer| +--------+ +--------+ +--------+ SALT_B, B_ID, [TEXT_0] --INITIATE-------------------------> CLEAR, [SIG_S], [TEXT_1], <-INVOICE--------------------------- E_A(SLIP), [SIG_B], [TEXT_2] --PAYMENT--------------------------> CLEAR, E_A(SLIP), [SIG_B], [SIG_S], [TEXT_3] -AUTH-REQUEST-----------------------> Y/N, SIG_A, [TEXT_4] Y/N, [SIG_A], <-AUTH-RESPONSE---------------------- [SIG_S], [V], [TEXT_5] <-CONFIRM--------------------------- Notes: + if SIG_S is present in INVOICE, then it must be included in AUTH_REQUEST and CONFIRM. + if SIG_B is present in PAYMENT, then it must be included in AUTH_REQUEST. + H(V) must be included in COMMON if and only if SIG_S is present in INVOICE. + if H(V) is included in COMMON, then V must be provided in CONFIRM. 7.5 Protocol Options The protocol may be suspended after the second (INVOICE) flow. This abbreviated version can be used for gathering SIG_S-s from multiple sellers (i.e., browsing, shopping around.) An abbreviated protocol run can be resumed at a later time provided that SIG_S is still timely/fresh. The following aspects of the protocol are OPTIONAL: [OPT1] Buyer's signature SIG_B in PAYMENT [OPT2] Sellers's signature SIG_S in INVOICE (mutually exclusive with OPT8) [OPT3] Seller's verification of SIG_B in PAYMENT (only if OPT1) Linehan, Tsudik Expires Jan. 1996 [Page 10] INTERNET DRAFT Internet Keyed Payments Protocol July 1995 [OPT4] The entire sixth flow CONFIRM [OPT5] Buyer's verification of SIG_A in CONFIRM (only if OPT4) [OPT6] Buyer's verification of SIG_S in INVOICE [OPT7] Buyer's verification of V (only if OPT4, OPT2 and OPT6; or OPT4, OPT8 and OPT9) [OPT8] Sellers's signature SIG_S in AUTH-REQUEST (mutually exclusive with OPT2) [OPT9] Buyer's verification of SIG_S in CONFIRM (only if OPT4 and OPT8) The following table summarizes the relationship between requirements and options. (0 stands for the protocol without any options.) Requirements | Necessary Options --------------+--------------------- A1 a | 0 A1 b | 1 A2 a+b | 2 or 8 S1 a+b | 0 S2 a | 0 * S2 b | 1,3 S3 a+b | 2 or 8 B1 a | 0 B1 b | 1 B2 | 4,5 B3 | 2 **** B4 a+b | 2,6,7 or 7,8,9 B5 a | 0 *** B5 b | 0 B6 | 0 ** B7 | 6 Notes: * - proof of buyer authorization is always indirect, i.e., seller takes acquirer's Y/N to mean that buyer authorization was verified. ** - anonymity is meaningless if OPT1 is used; unless buyer communicates directly to acquirer or the buyer's certificate is not transmitted in public. *** - an eavesdropper who captures SALT_B on the B<->S channel can mount a guessing attack against H(DESC, SALT_B) and thus obtain DESC. **** - a seller certificate which certifies ID_S and its electronic address might already serve as a weak proof. Linehan, Tsudik Expires Jan. 1996 [Page 11] INTERNET DRAFT Internet Keyed Payments Protocol July 1995 8. Protocol Actions and Other Details This section describes normal protocol operation by all parties. Handling of errors and other exceptions is discussed in the next section. All parties are assumed to have access to stable, non-volatile storage. The term "recording" means commitment to stable storage. It is further assumed that all parties commit all local variables -- transaction ids, nonces, signatures, etc. -- to stable storage BEFORE sending out a message flow. 8.1 FLOW 1: INITIATE 1) Buyer forms B_ID by generating random number R_B and computing B_ID = H(R_B,BAN). 2) Generates another random number SALT_B to be used for "salting" the hash of merchandise description (DESC) in subsequent flows. 3) Sets TEXT_0 to include desired protocol options (if any) and/or DESC. 4) Sends INITIATE 8.2 FLOW 2: INVOICE Note that DESC (merchandise description) and $$ (amount) are either agreed upon a priori or communicated in TEXT_0 of the INITIATE flow. 1) Seller retrieves SALT_B and B_ID from INITIATE. 2) Chooses/obtains DATE. 3) Generates nonce NONCE_S used later for freshness/uniqueness checks. 4) Chooses transaction id TID_S which identifies the context. 5) Computes H(DESC,SALT_B) 6) If OPT2, generates random V and computes H(V). 7) Forms COMMON as defined above and computes H(COMMON) Note: seller does not need to additionally "salt" H(COMMON) because it contains the already-salted H(DESC,SALT_B). 8) If OPT2, computes/composes SIG_S 9) Composes TEXT_1 to include, e.g., acquirer's certificate or (if OPT2) seller's certificate. TEXT_1 can also include a context pointer for the buyer, e.g., B_ID. Linehan, Tsudik Expires Jan. 1996 [Page 12] INTERNET DRAFT Internet Keyed Payments Protocol July 1995 10) Sends INVOICE *) The protocol may terminate at this point since, sometimes, the buyer may choose not to initiate payment. Seller keeps transaction state for some period of time (perhaps set to the maximum time skew for a given acquirer.) Thereafter, transaction is deleted. 8.3 FLOW 3: PAYMENT 1) Buyer retrieves CLEAR from INVOICE. (Validates DATE.) 2) If OPT2 and OPT6, verifies SIG_S. Also, records H(V). 3) Computes H(DESC,SALT_B) and matches it with the corresponding value in CLEAR. 4) Computes H(COMMON) and matches with corresponding value in CLEAR (A match provides an indication that buyer and seller agree on all payment parameters; in particular, on DESC and $$.) *) At this point, it is "legal" for the protocol to terminate. Buyer may be presented with the data in INVOICE and asked to confirm that he/she intends to go ahead with the payment. If so, the protocol resumes with step 5. 5) Buyer forms SLIP as defined above. 6) Encrypts SLIP under PK_A (see "Use of ENCRYPTION in iKP" below.) 7) If OPT1, computes SIG_B as defined above 8) Sends PAYMENT Note: TEXT_2 can include context identifying information, e.g., TID_S or H(COMMON). 8.4 FLOW 4: AUTH-REQUEST 1) Seller uses either addressing information or TEXT_2 to identify/retrieve the appropriate payment context. 2) If OPT1 and OPT3, retrieves buyer's signature SIG_B and verifies its validity. Note that SIG_B includes H(COMMON) which, in turn, includes DATE and NONCE_S. (In other words, verification of SIG_B implies timeliness/freshness to seller.) 3) If OPT8 (and, of course, not OPT2) computes SIG_S as defined above. 4) Forms AUTH_REQUEST and sends to acquirer Linehan, Tsudik Expires Jan. 1996 [Page 13] INTERNET DRAFT Internet Keyed Payments Protocol July 1995 8.5 FLOW 5: AUTH-RESPONSE Normal acquirer processing is as follows: 1) Check if valid DATE. 2) Using ID_S, TID_S, NONCE_S (all from CLEAR) checks for replays, i.e., makes sure that there is no previously processed request with the same ID_S/TID_S/NONCE_S combination. 3) If OPT2 or OPT8, verifies seller's signature SIG_S. 4) Decrypts E_A(SLIP) and obtains SLIP which contains $$, BAN, R_B, (optional) PIN and H(COMMON). 5) If OPT1, verifies buyer's signature SIG_B. 6) Re-forms COMMON from values: $$ (from SLIP), ID_S, TID_S, DATE, NONCE_S, B_ID, H(DESC,SALT_B). Then computes H(COMMON) and cross-checks it with both H(COMMON) in CLEAR and H(COMMON) in SLIP. 7) Validates that R_B and BAN generate B_ID. 8) Records AUTH_REQ, marks record as pending 9) Composes and sends authorization request on the clearing network 10) Upon receiving a reply, computes SIG_A. 11) Composes, records and sends AUTH-RESPONSE. Note: TEXT_4 in AUTH_RESPONSE can include, among other things, TID_S and/or H(COMMON) that seller can use to identify the appropriate context. 8.6 FLOW 6: CONFIRM 1) Seller verifies acquirer's signature SIG_A. 2) Records AUTH-RESPONSE 3) If not OPT4, marks transaction as completed and terminates protocol. 4) If OPT4, composes and sends CONFIRM 8.7 CHECK: Final Check by Buyer Note: this part of the protocol is only executed if OPT4 is being exercised. Linehan, Tsudik Expires Jan. 1996 [Page 14] INTERNET DRAFT Internet Keyed Payments Protocol July 1995 1) If OPT2 and OPT6, buyer computes H(V) and compares with its counterpart within SIG_S (saved from INVOICE.) 2) If OPT5, checks if SIG_A is present and verifies it. 3) If SIG_S present -- if (OPT8 and OPT9) or (OPT2 and not OPT6) -- verifies SIG_S, computes H(V) and checks that it matches its counterpart in SIG_S. 9. Rationales and Explanations This section explains some of the features of the protocol design. 9.1 Verification of CONFIRM The purpose of H(V) in the CLEAR field of INVOICE, and of V in CONFIRM is to bind these two messages to each other. V assures the buyer (and any third party) that the seller is aware of the acquirer's authorization and is committed to the transaction. The combination of SIG_M and V gives the buyer undeniable proof of the seller's agreement to the transaction. 9.3 SALT_B The purpose of SALT_B is to "key" the hashing of DESC. The resulting quantity -- H(DESC,SALT_B) -- is transferred over A<->S link. If the hash wasn't "salted", an adversary snooping on A<->S link could mount a dictionary attack on H(DESC) since DESC is chosen from a small space of goods/services. Without the knowledge of SALT_B, dictionary attacks are computationally hard. Note that SALT_B must, of course, be kept secret. However, it is sent in the clear in the INITIATE flow, so that S can include it in COMMON. Thus, if B<->S link is not privacy-protected, an adversary can obtain SALT_B from there and then mount a dictionary attack on the salted hash. Nonetheless, this is a harder attack, and it is expected that B<->S link will be protected, e.g., through the use of SSL, SHTTP, or secure IP. 9.4 Disputes TBA Linehan, Tsudik Expires Jan. 1996 [Page 15] ^L INTERNET DRAFT Internet Keyed Payments Protocol July 1995 10. Fault Tolerance and Exception Handling As can be expected in any communication environment -- especially, in the Internet -- absolute reliability is next to impossible. Therefore, in order to design, not only secure, but also robust, payment protocols, we need to consider all possible anomalous scenarios. No assumptions are made below about the robustness of the underlying network infrastructure since it is envisaged that the iKP protocol will operate in environments with widely varying degrees of reliability. It is assumed that all parties in iKP (except acquirer) implement timeouts and retransmissions whenever a message elicits no reply. All unexpected messages, i.e., those not corresponding to an outstanding or recorded transaction, are ignored. All invalid messages (e.g., acquirer receiving INITIATE) are similarly ignored. The term "duplicate" is used below to mean that the message is otherwise valid. Also, the term "unsolicited" is used to mean that the message is otherwise valid, i.e., all contained signatures (if any) are verifiable. All parties are assumed to have access to stable, non-volatile storage. The term "recording" is used to mean commitment to stable storage. 10.1 Buyer The following exceptions can occur at the buyer: (Note that buyer does not sign its error messages.) 1) No reply to INITIATE Buyer gives up and goes away after retrying. Linehan, Tsudik Expires Jan. 1996 [Page 16] INTERNET DRAFT Internet Keyed Payments Protocol July 1995 2) Error message from seller (Error messages from seller are optionally signed.) a. Error message is signed Buyer verifies the signature. If invalid, message is discarded. Otherwise transaction is stopped and recorded. b. Error message unsigned Record message and resort to off-line means. 3) Error message from acquirer (All error messages from acquirer are signed.) First, buyer checks acquirer's signature. If invalid, message is discarded. Otherwise, transaction is stopped and error message is recorded with other transaction state. Note that the actual human user may need to be notified at this point. 4) No reply to PAYMENT Buyer gives up after recording PAYMENT, INITIATE, INVOICE and R_B. 5) Invalid CONFIRM This can happen if any of Y/N, SIG_A, or SIG_S (if implemented) are invalid, or V (if used) does not match H(V) from INVOICE. Buyer can either re-transmit PAYMENT immediately or wait for the timeout before doing so. Moreover, it may be a good idea to generate an error message. 6) Duplicate INVOICE Discard. 7) Duplicate CONFIRM Discard. 8) Invalid INVOICE If seller's signature (optional) is invalid, INITIATE is re-transmitted. If H(DESC,SALT_B) does not match its counterpart within COMMON, error message is sent and INITIATE is re-transmitted. If invalid B_ID within COMMON, error message is sent and INITIATE is re-transmitted. 10.2 Seller The following exceptions can occur at the seller: (It is assumed that sellers having signature capabilities ALWAYS sign error messages.) 1) Invalid INITIATE (This is probably not a real error condition.) Linehan, Tsudik Expires Jan. 1996 [Page 17] INTERNET DRAFT Internet Keyed Payments Protocol July 1995 2) Invalid PAYMENT This can occur if INVOICE is invalid or outdated. In either case, error message is sent back. (Food for thought: seller may even want to reply with a new, fresh INVOICE.) 3) No reply to AUTH-REQUEST Seller notifies buyer (via special error message) that acquirer is currently unreachable. IMPORTANT: both seller and buyer must retain this error message; it can be used in later disputes to show that seller was, at the time, unable to process the payment. 4) Invalid AUTH-RESPONSE If acquirer's signature invalid, discard. 5) Error message from acquirer Acquirer's signature is verified and error message is forwarded to buyer. 6) Error message from buyer TBA 7) Duplicate INITIATE Re-transmit INVOICE. 8) Duplicate PAYMENT If corresponding AUTH-REQUEST pending, ignore. Alternatively, a special error message can be sent back saying "transaction pending." If AUTH-RESPONSE received, re-send CONFIRM. 9) Duplicate AUTH-RESPONSE Discard/ignore. 10.3 Acquirer Note that acquirer signs all of its own error messages and discards/ignores all error messages it receives. Also, if buyer's PIN or BAN are incorrect, the acquirer will receive a negative answer from the clearing network. This is considered "business as usual", i.e., not an exception/error condition. (Acquirer simply replies to seller with a negative auth. code in CONFIRM.) 1) Invalid AUTH-REQUEST Note "intersection" between (e) and (c). a. Seller's signature (if present) invalid b. Buyer's signature (if present) invalid c. Hash of COMMON within SLIP does not match its counterpart in AUTH-REQUEST d. Outdated COMMON (but not duplicate) Linehan, Tsudik Expires Jan. 1996 [Page 18] INTERNET DRAFT Internet Keyed Payments Protocol July 1995 e. SLIP invalid, i.e., decryption fails (e.g., for integrity reasons) f. B_ID from COMMON does not match BAN,R_B from SLIP f. Replayed COMMON (this is different from duplicate AUTH-REQUEST; may happen if buyer tries to reuse an already-processed COMMON; acquirer detects this by checking [DATE,ID_S,TID_S].) In all these cases, an error message with an appropriate code is sent to seller. Transaction state is then recorded for posterity. 2) Duplicate AUTH-REQUEST If the transaction is still pending, ignore or send an error message to seller. Otherwise, re-send the appropriate AUTH-RESPONSE (or error message if the original AUTH-REQUEST resulted in an error condition.) 3) No reply from the clearing network (timeout) One possibility is to send a special error message to the seller. TBA 10.4 Error Messages All error messages have the following format: S_Z( error_code, in_msg, other_info ) where: Z is {A,S,B}, error_code is self-explanatory, in_msg is the incoming message that resulted in error other_info is the optional accompanying information 11. Miscellaneous 11.1 Use of ENCRYPTION in iKP Use of ENCRYPTION in the iKP protocol is limited to protecting the buyer's PIN and Buyer Account Number -- BAN. All protocols require the buyer to encrypt the SLIP as part of composing PAYMENT message flow. E_A denotes RSA encryption with integrity (see below) under PK_A -- public key of the acquirer. The size of PK_A's modulus is assumed to be at least 1024 bits. The format of TEXT to be encrypted is as follows: TEXT = [ V_NO, $$, H(COMMON), BAN, R_B, PIN, SALT ] \__________ SLIP __________/ These fields are as described under "Atomic Fields/Symbols", above. The expected sizes of these fields are listed here. Linehan, Tsudik Expires Jan. 1996 [Page 19] INTERNET DRAFT Internet Keyed Payments Protocol July 1995 V_NO ---- Protocol Version number, 32 bits (Note that V_NO can be easily moved outside the encrypted part; there is no particular reason it should be here.) $$ ---- 64 bits BAN ---- 0-128 bits; (128 bits can be used to encode up to 38 decimal digits; current credit cards are only 12 digits... PIN ---- 0-64 bits (up to 19 decimal digits) H(COMMON) - 128 bits R_B ---- At least 128 bits SALT ---- Random salt/padding, at least 64 bits; its maximum length is the difference between 896 bits and the sum (in bits) of all previous fields. All of the above components are encoded into a 896-bit long string TEXT. The actual encryption process is adapted from reference (6) and proceeds as follows: 1) Prepend 64 bits of zeros to TEXT to form x=[0^{64},TEXT] (x is 960 bits long.) 2) Generate random 64-bit string E_SALT 3) Compute a = x XOR H_1(E_SALT) and then let b = E_SALT XOR H_2(a) H_1() is a hash function outputting 960 bits and H_2() is a hash function outputting 64 bits. Example ways of constructing H_1 and H_2 from H are given below. 4) Compute E_a(a,b) (combined length of a,b is 1024 bits) Decryption proceeds as follows: 1) Compute D_a(Ea(a,b))=a,b 2) Compute E_SALT = b XOR H_2(a) 3) Compute x = a XOR H_1(E_SALT) 4) Check for existence of 64 leading 0-s in x and obtain TEXT. For the hash functions H_1 and H_2 one could use: + H_2(DATA) = First 64 bits of output of H(DATA) + H_1(DATA) = First 960 bits of the sequence H(START,0,DATA), H(START,1,DATA),H(START,2,DATA)... where START is a constant. Linehan, Tsudik Expires Jan. 1996 [Page 20] INTERNET DRAFT Internet Keyed Payments Protocol July 1995 11.2 Authorization versus Clearance Credit card payment systems differentiate between "authorization" and "clearance" of payments. Authorization confirms that a given payment does not raise the account holder's debt above his or her credit limit, and reserves the specified amount of credit. Clearance actually charges the amount to the credit account. Clearance may happen simultaneously with authorization, or as a separate step performed sometime after authorization. The distinction between authorization and clearance is key to certain commercial practices. For example, in the United States, a mail-order retailer may not charge for goods until actually shipped, but may wish to authorize the total amount when an order is initially processed. Similarly, car rental agencies and hotels often "put a hold on" the maximum possible charge amount, but clear only the actual charge when the car is returned or the guest checks out. The protocol outlined in this document supports authorization. Extending it to cover clearance involves an additional exchange of messages between the seller and acquirer. +--------+ +--------+ +--------+ | Buyer | | Seller | |Acquirer| +--------+ +--------+ +--------+ AUTH-REQUEST for clearance ------------------------------> AUTH-RESPONSE for clearance <------------------------------ Specifically, the following changes to the basic protocol are needed: - The AUTH_REQUEST message should include a field indicating whether the seller requests authorization only or both authorization and clearance of the payment. - The Y/N field in AUTH_RESPONSE and CONFIRM should indicate whether the payment is only authorized or both authorized and cleared. - To clear a (previously-authorized) payment, the original AUTH_REQUEST message is retransmitted by the seller to the acquirer with the new field set to request clearance. The acquirer sends AUTH-RESPONSE to the seller indicating whether the payment was successfully cleared. There is no CONFIRM message since the customer does not participate in clearance transactions. These changes involve very minor extensions to the basic iKP protocol. Linehan, Tsudik Expires Jan. 1996 [Page 21] INTERNET DRAFT Internet Keyed Payments Protocol July 1995 11.3 Refunds Credit card systems support the concept of "returns" or refunds. The buyer returns merchandise to the seller along with the original credit card slip. The seller issues a refund slip which causes all or part of the original payment amount to be credited to the buyer's credit card account. An analogous function can be achieved in iKP but only if seller can sign. To process a refund, buyer and seller simply run iKP using a negative amount, effectively crediting rather than debiting money to the buyer's account. This may be repeated multiple times if buyer returns portions of an order in multiple refund transactions. As an option, the seller and acquirer may require that the CONFIRM message from a purchase be associated (in the optional TEXT fields) with any refund. This permits the seller and acquirer to validate the refund amount against the original purchase amount. It permits the seller to verify the original purchase transaction and detect multiple refunds that total to more than the original purchase. 11.4 Order Status Inquiry Given the distinction between authorization and clearance, buyers may want a method of finding out from sellers whether a payment has cleared. This is one instance of many kinds of order status inquiry. For example, buyers may wish to know whether purchased goods have actually been shipped by the seller. Such inquiry functions are outside the scope of iKP because: 1) they are not required for payment, 2) they involve bilateral (rather than multi-party) communication, and, 3) they extend to a variety of non-payment issues. 12. Protocol Variations 12.1 Protocol without browsing This protocol can be used for buyers that want to conduct payment without prior browsing. Buyer can compose COMMON info from, e.g., a catalog and submit PAYMENT via email. Because of the differences in communication patterns, this protocol requires that the buyer communicate certain parameters (in PAYMENT) outside the encrypted SLIP. Linehan, Tsudik Expires Jan. 1996 [Page 22] INTERNET DRAFT Internet Keyed Payments Protocol July 1995 +--------+ +--------+ +--------+ | Buyer | | Seller | |Acquirer| +--------+ +--------+ +--------+ PAYMENT where TEXT_2 is set to: { $$, ID_S, TID_S, DATE, NONCE_S, B_ID, SALT_B, H(DESC,SALT_B) } -----------------------------------> AUTH-REQUEST -----------------------------> AUTH-RESPONSE <----------------------------- CONFIRM <----------------------------------- In this variation, the buyer (rather than the seller), would specify TID_S, DATE, and NONCE_S. The buyer would obtain ID_S from offline sources such as a printed catalog. 12.2 Protocol with Buyer-Acquirer Link This variation is useful whenever seller has no direct connection to acquirer or seller simply does not want the burden of communicating with acquirer. Of course, buyer must then be able to communicate to acquirer directly. (Since most fields remain unchanged this protocol is described with high-level flows.) +--------+ +--------+ +--------+ |Acquirer| | Buyer | | Seller | +--------+ +--------+ +--------+ INITIATE -------------------------------> INVOICE <------------------------------- PAYMENT / AUTH-REQUEST <--------------------------------- AUTH-RESPONSE ---------------------------------> AUTH-RESPONSE --------------------------------> *CONFIRM <------------------------------------- *CONFIRM does not need to include SIG_A; only V is necessary. Linehan, Tsudik Expires Jan. 1996 [Page 23] INTERNET DRAFT Internet Keyed Payments Protocol July 1995 13. Future Directions 13.1 iKP without confidentiality It is envisaged that at some not-so-distant future buyer account numbers (BANs) will no longer be treated as sensitive, confidential information. Universal buyer certification will make it unnecessary to hide BANs since only properly signed (with buyer's private key) authorizations will be accepted by acquirers. In other words, paying for something by supplying only a BAN will become impossible. (This is in contrast to today's credit card-based commerce where one can pay over the phone with nothing more than a credit card number.) Universal buyer certification is also likely to change the way PINs are used. In particular, a buyer may use a PIN to "unlock" his private (signature) key but this PIN is no longer necessary for authorization and authentication since a signature key serves the same purpose with stronger security guarantees. In light of the above, it is possible that future versions of iKP may not require any secrecy/confidentiality services. In particular, it might not be necessary for buyer to encrypt SLIP. Recall that SLIP = $$, H(COMMON), BAN, R_B, [PIN] and SIG_B = S_B( H(E_A(SLIP)), H(COMMON) ) The protocol would change so that SLIP, instead of E_A(SLIP), is sent in PAYMENT flow and SIG_B would change accordingly to S_B(H(SLIP),H(COMMON)) The only problematic issue is the secrecy of the payment amount -- $$. (If SLIP travels in the clear, $$ is visible to anyone.) 13.2 Payment Clearing on the Internet One of the fundamental assumptions of iKP is the need to interface with a separate financial clearing network through entities called acquirers or acquirer gateways. While this assumption may remain valid for some years to come, payment clearing may, at some point, migrate to the Internet. In this case, iKP would need to be amended to allow direct communication with the issuing (buyer's) bank or financial institution. Linehan, Tsudik Expires Jan. 1996 [Page 24] INTERNET DRAFT Internet Keyed Payments Protocol July 1995 14. Outstanding Issues + How to reveal BAN to seller (if needed for off-line transactions.) + Does V_NO have to be within the encrypted SLIP? (see above) + If buyer signs SLIP, should the signature be made "anonymous"? + Should we introduce a context pointer for buyer (TID_B)? This pointer would serve no security-related purpose but would allow for easy reference. Should TID_S be re-defined to serve the same purpose for seller? + Need a separate cancellation protocol for seller to obtain a receipt from acquirer stating that transaction either i) never took place or ii) is canceled/reversed. + Need a similar protocol between buyer and seller. + Currently, $$ is subject to discovery (via dictionary attack) by an adversary snooping on the S<->A link. How can this be fixed? Better yet, should it be fixed? 15. Security Considerations The intent of iKP is to address certain security issues related to three-party payment mechanisms conducted over the Internet. These issues are discussed in the section entitled Security Requirements. Note that iKP does not address security concerns applicable to negotiations that may occur before iKP is initiated. Depending upon the communications method utilized, security protocols such as SSL (2), SHTTP (3), PEM (4), or MOSS (5) should be utilized if privacy, authentication, signatures, or other security attributes are required for the negotiations. Public-key signature mechanisms are critically dependent upon the security of the corresponding private keys. iKP requires private and public keys of acquirers and optionally of sellers and buyers. Implementors should pay particular attention to the methods used to store the private keys of these participants. Encryption of stored private keys, tamper-proof hardware, certificate revocation mechanisms, and certificate expiration dates should all be considered. iKP expects that public keys are distributed via certificates signed by well-known certification authorities (CAs). The definition of such CAs, and the distribution mechanism for their "root" public keys, is outside Linehan, Tsudik Expires Jan. 1996 [Page 25] INTERNET DRAFT Internet Keyed Payments Protocol July 1995 the scope of iKP. The security of iKP ultimately relies upon the security of the root keys as utilized by the buyer, seller, and acquirer software. Implementors should consider carefully how software configures and stores these root keys. It is suggested that there be mechanisms by which buyers, sellers, and acquirer employees/users can verify the certificate authorities and root keys recognized by their software. 16. References 1) Mihir Bellare, Juan A. Garay, Ralf Hauser, Amir Herzberg, Hugo Krawczyk, Michael Steiner, Gene Tsudik, Michael Waidner, "iKP - A Family of Secure Electronic Payment Protocols", Usenix Electronic Commerce Workshop, July 1995. 2) Kipp E. B. Hickman, "The SSL Protocol", Internet Draft , work in progress, April 1995. 3) E. Rescorla and A. Schiffman, "The Secure HyperText Transfer Protocol", Internet Draft , work in progress, December 1994. 4) J. Linn, "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, 1993 February. 5) S. Crocker, N. Freed, and J. Galvin, "MIME Object Security Services", Internet Draft , work in progress, March 2, 1995. 6) M. Bellare and P. Rogaway, "Optimal Asymmetric Encryption", Eurocrypt 94. 7) R. Atkinson, "Security Architecture for the Internet Protocol", Internet Draft , work in progress, May 11, 1995. 17. Editors' Addresses Mark H. Linehan IBM T. J. Watson Research Center 30 Sawmill River Rd. Hawthorne, NY 10532, USA linehan@watson.ibm.com Gene Tsudik IBM Research - Zurich Saeumerstrasse 4 CH-8803, Rueschlikon, Switzerland gts@zurich.ibm.com Linehan, Tsudik Expires Jan. 1996 [Page 26]