SIP C. Jennings Internet-Draft Cisco Systems Expires: November 20, 2004 MAY 22, 2004 Payment for SIP Services draft-jennings-sip-pay-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 November 20, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract In communication systems, there is a need for someone receiving a call to be 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 that are desirable in typical online trading systems. Jennings Expires November 20, 2004 [Page 1] Internet-Draft SIP Payment MAY 2004 Table of Contents 1. TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . 5 5.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . 6 5.3 Computing costs . . . . . . . . . . . . . . . . . . . . . . 7 5.4 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 7 5.5 Payment Service Provider Behavior . . . . . . . . . . . . . 7 5.6 Customer and Merchant Enrollment and Transfer functions. . . 8 5.7 Account Names . . . . . . . . . . . . . . . . . . . . . . . 8 5.8 Merchant Fetching Public Key . . . . . . . . . . . . . . . . 8 6. SIP Extensions . . . . . . . . . . . . . . . . . . . . . . . 8 6.1 Update response code 402 . . . . . . . . . . . . . . . . . . 8 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1 Offer . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.2 Request for Payment . . . . . . . . . . . . . . . . . . . . 10 8.3 Receipt . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.4 Computing Signatures . . . . . . . . . . . . . . . . . . . . 11 8.5 Verifying Signature . . . . . . . . . . . . . . . . . . . . 11 8.6 Replay Prevention . . . . . . . . . . . . . . . . . . . . . 11 8.7 PreVerify . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Limitations . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . 12 10.1 SPAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.2 Micro Billing . . . . . . . . . . . . . . . . . . . . . . . 12 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 12 12. Security Consideration . . . . . . . . . . . . . . . . . . . 12 13. IANA Registration . . . . . . . . . . . . . . . . . . . . . 13 Normative References . . . . . . . . . . . . . . . . . . . . 13 Informational References . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . 14 Jennings Expires November 20, 2004 [Page 2] Internet-Draft SIP Payment MAY 2004 1. TODO Add HTTPS, TLS, and CMS references 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. 2. Introduction The scheme is very simple and is optimized for low value transactions and simplicity. 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. Jennings Expires November 20, 2004 [Page 3] Internet-Draft SIP Payment MAY 2004 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. 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. 3. Terminology MUST SHOULD This work adopts the terminology from the framework in 2801. 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. 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. Jennings Expires November 20, 2004 [Page 4] Internet-Draft SIP Payment MAY 2004 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 occurred. Brand: A Merchant may accept payments from several different Payment Service Providers. Each of these is referred to as a Brand. Each Brand may accept different type of currency. TODO - Note I would like a better term for this. Currency: Could be a classical currency such as the Euro or US Dollar or could be a pseudo currency such as airline mileage points. 4. 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 or prevent the Merchant from cheating. 5. Protocol 5.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 where 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 XXX. The UAC MUST copy the LIST FIELDS HERE fields from the offer into the Request for Payment. The UAC needs to look at the available Brands, cost, and currency and select an appropriate one. 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 field appropriately. Finally it needs to fill the LIST FIELDS. It is critical that the UAC check the certificate of the HTTPS TLS connection as specified in RFC XXXX. Jennings Expires November 20, 2004 [Page 5] Internet-Draft SIP Payment MAY 2004 The response from the Payment Service Provider will either be an error or 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 XXX. 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. 5.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 XXX. 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 lists of currencies that are acceptable and what the cost in each one is. The costs are described in section XXX. When the UAS receives a request that contains an application/ pay-receipt, it should check that this is valid with the following steps. Make sure the amount of the payment is appropriate and if it wishes, check that this is a receipt for an Offer it made. Check that the signature of the Receipt is valid. Computing and verifying the signatures is described in section XXX. 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 (TODO REF). Next it 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 UAS are using the same merchant-id at the Payment Service Provider, this replay detection needs to be done across all the UAS. 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 session timer (ADD REF) Jennings Expires November 20, 2004 [Page 6] Internet-Draft SIP Payment MAY 2004 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. 5.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 cost 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. 5.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. 5.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 TODO REF. 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. Jennings Expires November 20, 2004 [Page 7] Internet-Draft SIP Payment MAY 2004 (TODO - consider using HTTP Digest here instead ). 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. 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 XXX. 7. MUST transfer the money from the customer account to the vendor account. 8. MUST send the receipt as the HTTP response. 5.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 transfer to bank accounts mechanism. 5.7 Account Names TODO - define syntax for valid account id. Allow email style account name (where the host part is not the same as the PSP domain). 5.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. REF DOC on how to do. 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. 6. SIP Extensions 6.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 more than one type of payment is required. Jennings Expires November 20, 2004 [Page 8] Internet-Draft SIP Payment MAY 2004 7. 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 callee to help reduce SPAM. The caller does not even bother to 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 | | |<------------------------| | | | TODO - put in the rest of the messages for the example. 8. Syntax 8.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. 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 Expires November 20, 2004 [Page 9] Internet-Draft SIP Payment MAY 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 * Brand List * Brand * 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 brand of PSP TODO TBD if this is needed - merchant-id: merchant's account # at this PSP - Accepted currencies: list of currencies accepted through this brand of PSP - PSP Bits: some data provided by PSP * OfferData - offer-id: - offerExpirey date: ISO format UTC - MerchantBits: some bits provided by vendor 8.2 Request for Payment Request for Payment * Brand; 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 Expires November 20, 2004 [Page 10] Internet-Draft SIP Payment MAY 2004 mostly copying chunks from Offer 8.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 8.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. 8.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 XXX (REPLAY)) 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 8.6 Replay Prevention Replay detection. If OfferData.offer-id contains device-id, the scope of replay detection can be limited to a single device. If the device has a policy of generating up to two offers per second and specifying the offer-id as ".<0|1>.(some random string)", then verifying OfferData.hash is sufficient to ensure the uniqueness of Jennings Expires November 20, 2004 [Page 11] Internet-Draft SIP Payment MAY 2004 the offer. 8.7 PreVerify TODO - decide if this is useful or not. Verification procedure MAY differ from what suggested here, depending on the Merchant's policy. This suggested example enables the Merchant to verify the signature more efficiently. Verifying the hash before doing RSA signature verification will help the Merchant spot the forgery without wasting its CPU time on computationally intensive RSA verification. Verify ReceiptData.hash. If fails, reject. (recompute hash and compare with given hash) Verify Offer.hash Compute a digest of Brand.hash + Offer.hash + ReceiptData.hash (+: string concat.) - Merchant chooses right Brand.hash based on PaymentServiceProvider-id 9. Limitations 10. Usage Scenario 10.1 SPAM 10.2 Micro Billing 11. Open Issues Header or body? 12. Security Consideration Certificate loss and revocation. Credential loss. Recommendation on low value transactions only. Merchant IDs cannot be used a customer IDs. Helps keep money in a customer account low. Loss of receipt in TCP transfer. Jennings Expires November 20, 2004 [Page 12] Internet-Draft SIP Payment MAY 2004 13. IANA Registration Need MIME types for Offer, Payment, and Receipt. 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. Informational References [4] 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. [5] Burdett, D., "Internet Open Trading Protocol - IOTP Version 1.0", RFC 2801, April 2000. Author's Address 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 Jennings Expires November 20, 2004 [Page 13] Internet-Draft SIP Payment MAY 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Jennings Expires November 20, 2004 [Page 14] Internet-Draft SIP Payment MAY 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Jennings Expires November 20, 2004 [Page 15]