SIPPING C. Jennings Internet-Draft Cisco Systems Expires: January 9, 2005 G. Jun Bitpass, Inc. July 11, 2004 Payment for SIP Services draft-jennings-sipping-pay-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 January 9, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Communication systems require that a person receiving a call be able able to charge the caller when they are from different administrative domains. This is necessary for making fair exchanges of service between two different communicating parties and is a major strategy for reducing the viability of SPAM. This draft proposes an approach for doing this in SIP. The approach relies on a third party to act as a payment service provider and is optimized for very simple, low value transactions. It does not provide the full range of services Jennings & Jun Expires January 9, 2005 [Page 1] Internet-Draft SIP Payment July 2004 that are desirable in typical online trading systems. This draft is being discussed on the sipping@ietf.org mailing list. It is at a very early stage and is missing significant syntax details. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 4.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 4.3 Computing costs . . . . . . . . . . . . . . . . . . . . . 7 4.4 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 7 4.5 Payment Service Provider Behavior . . . . . . . . . . . . 7 4.6 Customer and Merchant Enrollment and Transfer functions. . . . . . . . . . . . . . . . . . . . . . . . . 8 4.7 Account Names . . . . . . . . . . . . . . . . . . . . . . 8 4.8 Merchant Fetching Public Key . . . . . . . . . . . . . . . 8 5. SIP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1 Update response code 402 . . . . . . . . . . . . . . . . . 8 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1 Offer . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.2 Request for Payment . . . . . . . . . . . . . . . . . . . 10 7.3 Receipt . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.4 Computing Signatures . . . . . . . . . . . . . . . . . . . 11 7.5 Verifying Signature . . . . . . . . . . . . . . . . . . . 11 7.6 Replay Prevention . . . . . . . . . . . . . . . . . . . . 11 8. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1 SPAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.2 Micro Billing . . . . . . . . . . . . . . . . . . . . . . 12 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Security Consideration . . . . . . . . . . . . . . . . . . . 12 11. IANA Registration . . . . . . . . . . . . . . . . . . . . . 12 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 12.2 Informational References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 15 Jennings & Jun Expires January 9, 2005 [Page 2] Internet-Draft SIP Payment July 2004 1. Introduction The scheme is very simple and is optimized for low value transactions. It involves three parties: a consumer who is the caller, a merchant who is the person being called, and a common third party to broker the transaction, which is called the payment service provider. P C M | | 1) Call | | |------------------------>| | | | | | 2) 402+Offer | | 3) Request for Payment |<------------------------| |<-------------------------| | | | | | 4) Receipt | | |------------------------->| 5) Call+Receipt | | |------------------------>| | | | | | 6) 200 OK | | |<------------------------| | | | In the figure above, the Customer or caller is labeled C, the Merchant or person being called is M, and the Payment Service Provider is P. Initially C makes a call to M. M determines that a payment is required and includes information about the payment in an Offer body of a 402 (Payment Required) response to C. C looks at this Offer and decides to make a payment. C instructs P to make a transfer from C's account to M's account and provides C with a Receipt for this transfer. C resubmits the call to M but this time provides the Receipt for the transaction. M determines whether it feels the Receipt is valid or not and allows the call. The Offer includes the third parties, P, that are acceptable to M, the amount of transaction, the account identifier for M at P, and specific transaction data determined by M to make it easier for M to avoid replay attacks. C includes this information when making the Request for Payment to P; adds its own account information and authorization password; and sends this to P, which produces a Receipt for the transaction if it is successful. This transfer from C to P is made across an encrypted, integrity protected channel. The Receipt includes a time when P made the transaction and a signature of the critical information in the Receipt made with P's public key. C resubmits the call to M with the Receipt from P. M can check for replay attacks using the date and opaque data it provided in the offer. M can then check the signature is valid using P's public key. Jennings & Jun Expires January 9, 2005 [Page 3] Internet-Draft SIP Payment July 2004 HTTPS is used for the communications between P and C, while SIP is used for the communications between C and M. This scheme does not provide for the tightest of security. There is no guarantee or recourse if M does not provide the service after C transfers money into M's account. No refunds are possible in the protocol. The system is designed for low value transactions in which, if M cheats, C can choose to never deal with M again but the value of the transaction is lost. This scheme is for online systems in which M, C and P can all communicate with real time messages. The system does not provide anonymous transactions. While it is possible to develop schemes that deal with some of these problems, payment service providers deploying them have not been willing to provide services for transaction fees on the order one US cent. The authors believe that the simplified scheme presented here will make it easier to reach these low value transactions. 2. Terminology 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 [3]. This work adopts the terminology from the framework in RFC 2801 [8]. Customer: The entity that is paying for the call, typically the SIP UAC. Merchant: The entity wishing to be paid for the call, typically the SIP UAS or a proxy in the same administrative domain as the UAS. Payment Service Provider (or PSP): The third party that handles the transfer of currency from Customer to Merchant. RFC 2801 refers to this as the Brand. Offer: The information sent from the Merchant to the Customer describing what payment is needed. Request for Payment (or RFP): The information sent from the Customer to the Payment Service Provider describing the transfer of currency needed. Receipt: The information sent from the Payment Service Provider to the Customer and passed on to the Merchant. It provides confirmation that a particular transaction has occurred. Currency: Could be a classical currency such as the Euro or US Dollar or could be a pseudo currency such as airline mileage points. Jennings & Jun Expires January 9, 2005 [Page 4] Internet-Draft SIP Payment July 2004 3. Requirements Provide a system for callers to pay the person they are calling using a 3rd party clearing house. Work for very low value transactions. Support anonymous customers Not need to support refunds or guarantee that the 3rd party can prevent the Merchant from cheating. 4. Protocol 4.1 UAC Behavior The UAC SHOULD indicate that it can accept the application/pay-offer MIME type in SIP requests it sends. In the case wherein which the UAC receives a 402 response containing an application/pay-offer body, it MUST check that this offer is acceptable to the user of the UAC. This could be done using a policy that was previously entered by the user. If the offer contains a Payment Service Provider with which the user has an account and the offer is acceptable, then the UAC sends a Request for Payment to the Payment Service Provider. This is done by setting up an HTTPS connection to the URL specified for the Payment Service Provider and performing an HTTP POST of the XML Payment document. The exact syntax of this document is defined in section 7. The UAC needs to look at the available Payment Service Providers, cost, and currency and select an appropriate one. The UAC MUST copy the PaymentServiceProviderData fields from the offer into the Request for Payment. The UAC must look at the cost elements in the offer to decide how large a payment the user wishes to make and set the amount and currency field appropriately. Finally it needs to fill the CustomerData fields. It is critical that the UAC check the certificate of the HTTPS TLS connection as specified in RFC 2818 [5] and RFC 2246 [4]. The response from the Payment Service Provider either will be an error or will contain an application/pay-receipt body. The user needs to be informed if an error is received and the transaction SHOULD not be retried unchanged. When a valid response is received, the UAC SHOULD resubmit the SIP transaction that caused the 402 but this time attach the application/pay-receipt body to it. The UAC needs to compute the amount of payment it wishes to make by looking at the costs provided. This is described in section 4.3. Jennings & Jun Expires January 9, 2005 [Page 5] Internet-Draft SIP Payment July 2004 The UAC is also responsible for computing when the payments it has made will run out and refreshing the call with additional payments before this happens. For example, the UAC could initially decide to provide enough payment for 3 minutes. After 2.5 minutes it might decide to pay for an additional 3 minutes. It would do this by making a payment to the payment server for an additional 3 minutes' worth of resources and then sending the receipt with a SIP Re-INVITE or UPDATE transaction to the UAS. 4.2 UAS Behavior When the UAS receives a request it wishes to charge for, it should check whether the UAC has set the Accept header to include application/pay-offer. If it has, it MAY reject the request with a 402 and attach an application/pay-offer to the response. The syntax of the pay-offer body is defined in section 7. It needs to include lists of all the Payment Service Providers that are acceptable to the UAS and include the UAS's merchant-id at each one. It also needs to form a list of currencies that are acceptable and what the cost in each one is. The costs are described in section 4.3. When the UAS receives a request that contains an application/ pay-receipt, it should check that this is valid, using these steps. First, make sure the amount of the payment is appropriate and if it wishes, check that this is a receipt for an Offer it made. Second, check that the signature of the Receipt is valid. Computing and verifying the signatures is described in section 7.4. Third, check that the time between the payment and now is acceptably low. This MUST be a configurable parameter and should default to 30 seconds. The UAS SHOULD support NTP RFC 1305 [6]. Fourth, the UAS MUST check that this receipt has not been previous used. The limited time window limits the amount of state the UAS must keep to make this check. If several UASs are using the same merchant-id at the Payment Service Provider, this replay detection needs to be done across all the UASs. The OfferData can be used with opaque encrypted data to help do this. If the payment is accepted, it is Merchant's responsibility to end the call after the amount paid becomes inadequate to cover the session. The UAS could use a mechanism like SIP session timer to perform this function. The UAC may send a Re-Invite or UPDATE with a new receipt for a payment to prolong the session. The UAS is provisioned with the URL and account numbers of Payment Service Providers that are acceptable, along with the certificate containing the public key for the Payment Service Provider. The expiry dates in this certificate MUST be checked and honored. Jennings & Jun Expires January 9, 2005 [Page 6] Internet-Draft SIP Payment July 2004 4.3 Computing costs There are three types of costs: initial connection cost, cost per second, and cost per unit data. All three costs are added together to form the total cost and are assumed to be zero if not specified. The cost of the first time unit block size worth of time and the first data unit block size of data are considered to be included in the initial connection cost. If a call costs 30 cents to connect and then 12 cents per minute and is billed in 15 second increments (rounded down), the cost would be set so that the currency was USD, the initial costs was 0.3, the cost per unit time is 0.04, and the time unit size is 15000. If the time is to be rounded up, then some extra to cover the price of the first increment would be added to the connect cost. 4.4 Proxy Behavior In general a proxy does not do any special processing. A proxy in the same domain as the UAS MAY perform the UAS functions on behalf of the UAS. In this case the proxy performing this service would send the 402 to a request with no Receipt and would validate that the Receipt was acceptable before forwarding a request to the UAS. 4.5 Payment Service Provider Behavior The primary function of the Payment Service Provider is to receive Requests for Payments over HTTPS, transfer the currency from one account to another, and return a Receipt over HTTPS. A Payment Service Provider MUST support HTTPS. When it receives a new connection it MUST present a valid TLS certificate that corresponds to its domain in the normal ways specified in RFC 2818 [5]. The cipher suite negotiated must be encrypted and integrity protected because sensitive information is going to be transferred over this connection. When a Payment Service Provider receives a Request for Payment, it performs the following steps: 1. Verify that the customer-id corresponds to a valid account and that the authorization credential is correct for that account. If this fails, the connection should be terminated. An empty or error response MAY be sent. 2. MUST validate that the currency is acceptable by the Merchant, that the Customer has appropriate funds, and that the merchant-id corresponds to a valid account. 3. MUST form the Receipt by setting the PaymentServiceProviderData, currency information, amount, and merchant-id. Jennings & Jun Expires January 9, 2005 [Page 7] Internet-Draft SIP Payment July 2004 4. May set the PaymentData that the Payment Service Provider wishes to keep in the receipt. 5. MUST set the Date to the current time. 6. MUST compute and set the signature as described in section 7.4. 7. MUST transfer the money from the customer account to the vendor account. 8. MUST send the receipt as the HTTP response. 4.6 Customer and Merchant Enrollment and Transfer functions. The Payment Service Provider needs to provide a way for Customers and Merchants to enroll and transfer money in and out. This is outside the scope of this document but could be done using web forms to enroll, get an account number, and provide the typical credit card mechanism to transfer money into the account. Transfers out of the account could be done with the typical mechanism for transfers to bank accounts. 4.7 Account Names Note: Need to define they syntax for valid account id. Email style account names (where the host part is not the same as the PSP domain) need to be allowed. 4.8 Merchant Fetching Public Key The Merchant needs to be able to fetch the Payment Service Provider's public key. This is done by an HTTPS request to a URI provided by the Payment Service Provider. TODO - add more detail on how to do this. It is suggested that Payment Service Providers use signing certificates that are only valid for a short period of time - in the order of 1 to 7 days. 5. SIP Extensions 5.1 Update response code 402 This document updates 402 to mean that "A Payment is Required". Other mechanisms are used to indicate what type of payment is required. In the case of this draft, a particular MIME body type indicates the type of payment required. A single 402 may indicate that more than one type of payment is required. 6. Example The following example shows a simple call where the caller is not recognized by the callee and the callee wants to charge 25 cents to the caller to help reduce SPAM. The caller does not even bother to Jennings & Jun Expires January 9, 2005 [Page 8] Internet-Draft SIP Payment July 2004 actually collect this 25 cents but donates it their favorite charity. P C M | | 1) Call | | |------------------------>| | | | | | 2) 402+Offer | | 3) Request for Payment |<------------------------| |<-------------------------| | | | | | 4) Receipt | | |------------------------->| 5) Call+Receipt | | |------------------------>| | | | | | 6) 200 OK | | |<------------------------| | | | Still To Do - put in the rest of the messages for the example. 7. Syntax 7.1 Offer The Offer contains a lists of costs and a list of Payment Service Providers. The Customer can choose to pay any one of the provided costs and can choose any one of the Payment Service Providers to use, as long as the PSP supports the currency for the chosen cost. The bodies will be defined with XML Schemas. The syntax is not specified yet, since we are just trying to get down the basic semantics. Notes on types: The types are all constructed so that they have a clear canonical form for computing the signatures and so that "|" can be used a separator between them. Currency: if ISO, then 3 upper case letters. Amount: decimal number. If greater than or equal to 1, no leading zeros; otherwise must start with 0. No trailing 0. Must not have more than 8 digits to the left of the decimal point and not more than 6 digits to the right of the decimal point. Vendor ID: base 10 integer, 64 bits, no leading zeros, 0 not valid. Customer ID: base 10 integer, 64 bits, no leading zeros, 0 not valid. CustomerData: base64 encoded data. MerchantData: base 64 encoded data. PaymentData: base64 encoded data. Jennings & Jun Expires January 9, 2005 [Page 9] Internet-Draft SIP Payment July 2004 Offer * Cost List * Cost - currency name space - currency: 3 uppercase letters, ISO currency code - initial cost - cost per unit time - time unit size in milliseconds - cost per unit data - data unit size in octets * Payment Service Provider List * Paymnet Service Provider instance * PaymentServiceProviderData - id: domain name as a unique identifier for PSP - URL: general http URL to learn about the PSP - URL for RCP: URL to send the payment request - supported currencies: list of currencies supported by this PSP TODO TBD if this is needed - merchant-id: merchant's account # at this PSP - Accepted currencies: list of currencies accepted through this PSP - PSP Bits: some data provided by PSP * OfferData - offer-id: - offerExpiry date: ISO format UTC - MerchantBits: some bits provided by vendor 7.2 Request for Payment Request for Payment * Payment Service Provider; copied from Offer - ... - ... * CustomerData - customer-id: customer's account # at this PSP - customer authorization: authorization credential * RequestData - currency - amount * OfferData; copied from Offer - ... - ... Note: Request for Payment will be an HTTP message, which has fewer size restrictions. Therefore Customer does not need to try to reduce the size of the request. Generating the Request for Payment is Jennings & Jun Expires January 9, 2005 [Page 10] Internet-Draft SIP Payment July 2004 mostly copying chunks from Offer 7.3 Receipt Receipt - receipt-id: - 64bit integer - PaymentServiceProvider-id * OfferData; copied from RFP - ... - ... * ReceiptData - Date: ISO format UTC time - currency namespace - currency - amount - digest - hash * PaymentData (optional) - bits provided by PSP - SignatureData 7.4 Computing Signatures The signature in a receipt is computed across all the fields (other than the signature field itself, of course). The fields are defined so they have a clear and simple canonical form. A "|" separator is used between the fields. RSA and SHA1 MUST be implemented for computing signatures. 7.5 Verifying Signature Merchant needs to verify the signature in the Receipt to determine what to do. A suggested verification involves 1. Check ReceiptData.Date. If too old, reject. 2. Check whether receipt-id has been accepted in a previous payment since the TTL used by the UAS. If so, reject. (See section 7.6 on replay prevention) 3. Check whether Offer comes from this UAS. If not, reject. 4. Perform RSA signature verification. UAS chooses the public key based on PaymentServiceProvider-id 7.6 Replay Prevention Replay detection. If OfferData.offer-id contains device-id, the scope of replay detection can be limited to a single device. TODO - add more here. Jennings & Jun Expires January 9, 2005 [Page 11] Internet-Draft SIP Payment July 2004 8. Usage Scenario 8.1 SPAM Payment at risk has been suggested as part of a possible solution to SPAM in VoIP systems [9]. The idea is that A would call B. If A was not on B's white list, B could ask A to pay 5 cents for the privilege of ringing B's phone. A could pay, and if B wished, B could refund the 5 cents by simply doing a second payment from B to A. The payment service provider would collect two transaction fees in this scenario. Another possible scenario is that B simply requests that A donate 5 cents to one of B's favorite charities and show B the receipt for this transaction. 8.2 Micro Billing In this scenario, a merchant running a PSTN GW may charge a customer 5 cents to connect and operate for the first 90 seconds and then may charge 5 more cents for each additional minute. The customer would initially transfer 5 cents and then, before the 90 seconds ran out, would transfer another 5 cents and keep on doing this until the call ended. 9. Open Issues Would like to unify the body syntax so that it can also be used for Advice Of Charge information. 10. Security Consideration This system has many limitations and is appropriate only for low value transactions. Much more is needed in this section, but some topics to cover include: Certificate loss and revocation. Credential loss. Recommendation on low value transactions only. Loss of receipt in TCP transfer. Payment handler can cheat customer and vendor. Merchant can cheat customer. Things can simply get lost and cheat customer. Solutions like OSP are more complex but make these attacks less likely to be effective. 11. IANA Registration TODO - Need MIME types for Offer, Payment, and Receipt. Jennings & Jun Expires January 9, 2005 [Page 12] Internet-Draft SIP Payment July 2004 TODO - Update SIP 402 response code. 12. References 12.1 Normative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] International Organization for Standardization, "Codes for the representation of currencies and funds", ISO Standard 4217, 2001. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [5] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 12.2 Informational References [6] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992. [7] European Telecommunications Standards Institute, "Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); Open Settlement Protocol (OSP) for Inter- domain pricing, authorization, and usage exchange", ETSI Technical Specification 101 321. [8] Burdett, D., "Internet Open Trading Protocol - IOTP Version 1.0", RFC 2801, April 2000. [9] Rosenberg, J. and C. Jennings, "The Session Initiation Protocol (SIP) and Spam", July 2004. Jennings & Jun Expires January 9, 2005 [Page 13] Internet-Draft SIP Payment July 2004 Authors' Addresses Cullen Jennings Cisco Systems 170 West Tasman Drive MS: SJC-21/2 San Jose, CA 95134 USA Phone: +1 408 902-3341 EMail: fluffy@cisco.com Gyuchang Jun Bitpass, Inc. 3300 Hillview Avenue, Suite 165 Palo Alto, CA 94304 USA Phone: 650 354-1882 Jennings & Jun Expires January 9, 2005 [Page 14] Internet-Draft SIP Payment July 2004 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. 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 (2004). 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. Jennings & Jun Expires January 9, 2005 [Page 15]