Jacques Caron INTERNET-DRAFT IP Sector Technologies Expires: December 2002 June 2002 AAA cost advertisement extensions 1 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. 2 Abstract In many roaming scenarios, it is necessary to be able to carry cost information between the different parties in order to facilitate credit checking, real-time accounting, cost presentation to the user. It is also necessary that this information be interpretable by automated systems, that these systems be able to modify it to take commissions into account, and that non-repudiation mechanisms be available. This document proposes such a system to be used with AAA architectures. Table of Contents 1 Status of this Memo..............................................1 2 Abstract.........................................................1 3 Introduction.....................................................2 4 Terminology......................................................3 5 Conventions used in this document................................3 6 Description of the overall setup.................................3 Caron Informational - Expires December 2002 1 INTERNET-DRAFT AAA Cost Advertisement Extensions June 2002 7 Billing formats..................................................4 8 AAA attributes...................................................7 8.1 Cost advertisement attribute...................................7 8.2 Cost acceptance attribute.....................................10 9 Examples........................................................12 9.1 Fixed visited network cost....................................12 9.2 Fixed end-user cost...........................................14 10 Security Considerations........................................15 11 References.....................................................15 12 Author's Address...............................................17 3 Introduction In many roaming contexts, in particular public WLAN roaming, costs incurred for connection to foreign networks can vary significantly. Costs can also vary according to the user's subscription plan, and to the exact relationship (possibly multi-level) between the visited network and the commercial operator that bills the end-user, in such a manner that it is difficult to determine these costs in advance. For these reasons, it appears necessary to be able to: - verify that a user can use such a connection, based on its subscription plan and any credit-checking that could be needed; - present costs to the user during connection setup time; - be able to carry billing and accounting information in real time between the different parties involved (the visited network, the commercial operator, and eventually one or many roaming operators in between). This billing and accounting information is not necessarily the same over the whole chain, since intermediate roaming operators are likely to take a commission on transaction they handle and for which they manage compensation. It is also important for all parties to be sure that they will get payment for the services provided, and hence non-repudiation mechanisms are needed on all commercial relationships involved: - between the end-user and its home network (out of the scope of this document) - between each pair of operators along the path between the visited network and the home network, via possible one or many roaming operators. Caron Informational - Expires December 2002 2 INTERNET-DRAFT AAA Cost Advertisement Extensions June 2002 Finally, cost information can be expressed in many different ways, ranging from a simple fixed cost per connection to complex variable costs based on duration or volume. Similarly, the commissions can be either added to the cost requested by the visited network (the cost to the end-user being then higher), or accounted separately (the cost to the end-user being exactly what the visited network proposes, but the home network getting a smaller share of the total). Any specification must account for this variety of different formats. This document aims to describe such a specification for carrying cost information within AAA protocols, more specifically RADIUS [1,2,3] or Diameter [4]. 4 Terminology WISP Wireless Internet Service Provider. An organization which provides access to the Internet via Wireless LAN infrastructure. WLAN Wireless LAN, using e.g. IEEE 802.11 protocols. 5 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [5]. 6 Description of the overall setup To help in the understanding of the specification, we will use a typical example of a multi-level roaming scenario, in which two roaming operators are intermediaries between the visited network and the home network: +----+ +----+ +-----+ +-----+ +----+ |USER| ---> |WISP| ---> |ROAM1| ---> |ROAM2| ---> |HOME| +----+ +----+ +-----+ +-----+ +----+ / / | +----+ <-----------------------------------------------+ In this scenario, the USER attempts to connect to WISP. It provides an identity in the form of a NAI [6], which the WISP uses to route (using a method like that described in [7]) an authentication and/or authorization request towards the HOME network. Given the various bi-lateral agreements in place, it actually sends the AA request to ROAM1, which in turn sends it to ROAM2, and this one finally sends it to HOME. Optionally, HOME may send a request (using an other protocol not described here) to USER to verify that USER agrees to Caron Informational - Expires December 2002 3 INTERNET-DRAFT AAA Cost Advertisement Extensions June 2002 the costs associated with this connection. These requests follow the direction of the top arrows in the above diagram. AA responses are sent along the same path in the reverse direction, and match money flows: HOME will pay ROAM2, who will pay ROAM1 (after deducting its commission), ROAM1 will do the same to WISP. Obviously, though, WISP will not pay USER, but USER will pay HOME. For this reason, these responses need to have non-repudiation mechanisms (digital signatures) to guarantee payment in exchange for the service provided. 7 Billing formats This specifications aims to take into account a wide variety of billing formats, in order to accommodate various business models. They are described using the following structures. The format begins with a header structure: +---------------+--------------------------------------------+ | Decimals | Currency | +---------------+---------------+----------------------------+ | Number of types | Reserved | +-------------------------------+----------------------------+ - Decimals in the number of decimals in the decimal representation of currency units. For instance, if Decimals is 2, then a value of 150 means 1.50 of the currency unit. - Currency is the ISO 4217 code of the currency used. It is expected that on any given relationship, only one currency will be used (the currency used for the actual billing between the two entities), and that roaming operators will perform conversion between currencies if they have relationships with entities using different currencies. This information is used for confirmation purposes, and for events of currency changes (like the switch from national currencies to the Euro). - Number of types is the number of different billing types following, as described further. After the cost header, comes the type header, which describes the type of billing to be performed: +-------------------------------+----------------------------+ | Type | Number of units | +-------------------------------+----------------------------+ - Type describes what is counted to perform billing. Possible values are: Caron Informational - Expires December 2002 4 INTERNET-DRAFT AAA Cost Advertisement Extensions June 2002 1 Transaction: this is a one-off cost 2 Duration: billing is based on duration in seconds 3 Bytes in: billing is based on bytes received 4 Bytes out: billing is based on bytes sent 5 Bytes total: billing is based on total bytes - Number of units indicates the number of billing units that follow. Must be 1 for Type 1. Billing units are described using the following format: +------------------------------------------------------------+ | Amount | +------------------------------------------------------------+ | Quantity | +------------------------------------------------------------+ | Repeat | +------------------------------------------------------------+ - Amount is the amount of money that should be billed. The value stored here should be divided by 10^decimals to get the number of currency units. - Quantity is the number of seconds or bytes that this amount will cover. 0 means none, and all ones means unlimited. This field is ignored for a Type of Transaction. - Repeat is the number of times this unit will be repeated before moving on to the next one. 0 means unlimited. This field is ignored for a Type of Transaction. Here are some examples: 00 'E' 'U' 'R' 00 01 00 00 00 01 00 01 00 00 00 0A 00 00 00 00 00 00 00 00 This indicates we bill in Euros (EUR), and amounts are given with no decimals (0). There is one billing type, which is a transaction, with only one unit, indicating an amount of 10. In short: a cost of 10 euros for the transaction. The same information could be represented as follows: 00 'E' 'U' 'R' 00 01 00 00 Caron Informational - Expires December 2002 5 INTERNET-DRAFT AAA Cost Advertisement Extensions June 2002 00 02 00 01 00 00 00 0A FF FF FF FF 00 00 00 00 The difference being that billing is based on duration, but the first (and only) duration billing unit is unlimited (FFFFFFFF). An example of volume billing: 04 'U' 'S' 'D' 00 01 00 00 00 05 00 01 00 00 00 0F 00 00 04 00 00 00 00 00 Here we bill in US dollars (USD), with 4 decimals. There is one billing type, which is based on total volume, and one unit, which indicates that each kilobytes (0x400 = 1024 bytes) is billed 0.0015 USD (the value is 15 but we have 4 decimals). Measured quantities should be rounded up to the next billing quantity. An example of billing with an initial payment for a long period, then smaller increments for additional time: 02 'E' 'U' 'R' 00 01 00 00 00 02 00 02 00 00 01 F4 00 00 03 84 00 00 00 01 00 00 00 32 00 00 00 3C 00 00 00 00 In this case we bill in euros with 2 decimals. There is one billing type, which is based on duration, and two units. The first unit indicates a cost of 5.00 EUR (0x1F4 = 500) for the first 15 minutes (0x384 = 900 seconds). This unit is used once, after which additional time is billed 0.50 EUR (0x32 = 50) per minute (0x3C = 60 seconds), indefinitely. This last examples describes a scenario where we bill based on two different quantities (here volume in and volume out): 02 'E' 'U' 'R' 00 02 00 00 00 03 00 01 00 00 00 0A Caron Informational - Expires December 2002 6 INTERNET-DRAFT AAA Cost Advertisement Extensions June 2002 00 00 04 00 00 00 00 00 00 04 00 01 00 00 00 14 00 00 04 00 00 00 00 00 In this scenario we still bill in euros with 2 decimals, and there are two billing types. The first one is based on volume in, and has one unit of 0.10 EUR per kilobyte received, indefinitely. The second billing type is based on volume out, and has one unit of 0.20 EUR per kilobyte sent, indefinitely. Many other combinations are possible, such as billing based on duration and volume, free initial periods, discounts after a certain time or volume, etc. 8 AAA attributes In order to support the required functionality, the following new attributes are required: - a cost advertisement attribute - a cost acceptance attribute 8.1 Cost advertisement attribute The cost advertisement attribute Cost-Advertisement (code TBD) is used in authorization requests, or in protocols such as RADIUS that do not make a distinction between authentication and authorization requests, in Access-Request packets. In this last case, and if authentication takes several round-trips (with Access-Challenge responses for authentication protocols such as CHAP, ARAP, or EAP), the cost advertisement attribute should be ignored by the AAA server until authentication is complete. Intermediate proxies not being able to determine in advance whether an Access-Request will be the final one, should handle all requests the same. The attribute format (excluding code and length portions which are specific to the AAA protocol), is defined below: +------------------------------------------------------------+ | Flags | +------------------------------+-----------------------------+ | Type | Length | +------------------------------------------------------------+ | Cost data | Caron Informational - Expires December 2002 7 INTERNET-DRAFT AAA Cost Advertisement Extensions June 2002 . ... . +------------------------------+-----------------------------+ | Type | Length | +------------------------------------------------------------+ | Cost data | . ... . +------------------------------------------------------------+ - Flags is a bitmap of global flags. Currently, all bits are reserved, and should be set to 0. - Type indicates the type of cost information following. It can have the following values: - 0 indicates this is the cost requested. Further parties along the authorization chain should increment this cost to include their commission or charges. In this case, there should be only one cost element (type, length, cost data) present in the packet. - 1 indicates this is the cost that the visited network (the party originating the request) wants to charge the end-user. Further parties along the authorization chain should leave this cost unchanged, but add or increment a cost information element with type 2. The initial request (from the visited network to the first roaming operator along the path) might contain only one cost element (type, length, cost data). Further along the path, there should be two elements, one with type 1 representing the cost the user should be charged, and one with type 2 representing commissions and charges of other parties. Only per-connection costs (i.e. with no variable duration-based or volume-based costs) are allowed. - 2 indicates this is the added cost that intermediate parties want to charge for this transaction. Only per-connection costs (i.e. with no variable duration-based or volume-based costs) are allowed. - Length is the length of the cost data (excluding type and length) - Cost data is cost information encoded as specified in section 7. There can be one or two cost elements (type, length, cost data) in the request. There can be one of type 0 or 1, or two of types 1 and 2 respectively. It is illegal to have a request containing: - a cost element of type 0 and another cost element; - more than one cost element of the same type; - a cost element of type 2 with no cost element of type 1. Such requests should be rejected with code TBD. Caron Informational - Expires December 2002 8 INTERNET-DRAFT AAA Cost Advertisement Extensions June 2002 Upon reception of a request containing a Cost-Advertisement attribute, roaming operators should: - store cost elements received for this request; - if there is a cost element of type 0, increment it with their charges; - if there is a cost element of type 1 and no cost element of type 2, create one cost element of type 2 with their charges; - if there is a cost element of type 1 and one of type 2, increment this last one with their charges; - find which other party the request should be sent to, either via static tables, or using a dynamic protocol as described in [7]; - convert all cost information to the appropriate currency. Note that a roaming operator might use several AAA proxies or relays. In such a case, some of the nodes might carry the attribute transparently, while others will perform the above functions. Upon reception of an authorization request containing a Cost- Advertisement attribute, and after successful authentication and other authorization is performed, the home server should: - store cost elements received for this request; - if there is a cost element of type 0 or of type 1, use it for credit-checking purposes and optional end-user cost advertisement; - if the user does not pass credit-check tests, or rejects the cost, authorization can be rejected, and none of the attributes defined in this document need to be present; - if there is a cost element of type 0, send it back in a Cost- Accept attribute (defined below), with a proper digital signature; - if there is a cost element of type 1, deduct cost information from cost element of type 2 and any local costs that should be deducted, and send the result back in a Cost-Accept attribute (defined below), with a proper digital signature. - if there is a maximum amount a user can be billed (e.g. pre-paid users), then information from the Cost-Advertisement attributes can be used to compute a maximum amount of time the user is allowed to be connected, and sent back to the requestor in appropriate AAA attributes. Caron Informational - Expires December 2002 9 INTERNET-DRAFT AAA Cost Advertisement Extensions June 2002 Discussion: One might want to be able to carry cost information of type 1 in the original currency, for inclusion on the end user's bill. However, since this information is used to compute compensation between the different parties, which happens in fixed currencies, the information must also be converted. An extra informational cost element might need to be introduced to address this issue, but it might make inconsistencies in currency conversion (which would otherwise be "hidden" in the commissions/charges) a bit too obvious. Discussion: One might want to be able to support a maximum commission that can be deducted from the amount billed to the end-user to compute the amount paid back to the visited network, and further charges would be added the amount billed to the end-user (reproducing what happens with credit cards, where merchants pay a fixed commission, but international transactions incur additional fees for the end- user). This would require using the cost element types differently: 0 would be the base amount, 1 would be commissions charged to the visited network, and 2 commissions charged to the end-user, for instance. Discussion: Using maximum credit to give a maximum connection time works only for duration-based billing. In other situations, a maximum cost information might be needed instead, with the usual options when that amount is used up: terminate, re-authenticate... 8.2 Cost acceptance attribute The cost acceptance attribute Cost-Accept (code TBD) is used in positive authorization responses, when the corresponding request contained a Cost-Advertisement attribute. A client that submits a request with a Cost-Advertisement attribute, but does not receive a Cost-Accept attribute in the associated positive response, knows that at least one node on the AAA path does not support these extensions, and can drop the connection. The cost acceptance attribute is used to carry: - for requests that used cost elements with types 1 and 2, information the charges that will be levied off the cost billed to the user by intermediate parties; - for all requests, digital signatures from the upstream operator confirming that the costs are accepted. Caron Informational - Expires December 2002 10 INTERNET-DRAFT AAA Cost Advertisement Extensions June 2002 The cost acceptance attribute (excluding code and length information that is specific to the AAA protocol used) has the following format: +------------------------------------------------------------+ | Flags | +------------------------------+-----------------------------+ | Cost Data Type | Cost Data Length | +------------------------------+-----------------------------+ | Signature Type | Signature Length | +------------------------------+-----------------------------+ | Cost Data | . ... . +------------------------------------------------------------+ | Signature Data | . ... . +------------------------------------------------------------+ - Flags is a bitmap of global flags. Currently, all bits are reserved, and should be set to 0. - Cost Data Type indicates the type of cost information following. It can have the following values: - 0 indicates that this is the net cost that is accepted for this transaction. It should be the same as the cost in a type 0 cost element submitted in a Cost-Advertisement attribute in the corresponding request, or value lower than that submitted in a type 1 Cost-Advertisement attribute; - no other values are defined yet. - Cost Data length is the length of the cost data information, in bytes, excluding types, lengths, and signature data. - Signature type indicates the type of signature. The following values are defined: - 0 indicates a signature of type MD5 - 1 indicates a signature of type SHA-1 - Signature length is the length of the signature data field. - Cost data is encoded as described in section 7. - Signature data contains a signature of the type described in the Signature type field, computed over the Cost Data field, using the key of the sender of the attribute. Caron Informational - Expires December 2002 11 INTERNET-DRAFT AAA Cost Advertisement Extensions June 2002 Transmission of key or certificate information between roaming partners is outside the scope of this specification. 9 Examples To illustrate the use of the attributes defined in this document, we will describe some examples of scenarios using the setup defined in section 6. 9.1 Fixed visited network cost In this scenario, the visited network wants to be paid a fixed amount (1 EUR per minute), whatever the cost may be for the end- user. The first roaming operator takes a 10% commission, and converts to USD before sending to the second roaming operator. This operator adds a 1 USD per connection + 0.15 USD per minute charge, and converts to AUD before sending to the home server, which charges the end-user whatever amount they want. Totally fictitious currency rates used are: - 1 EUR = 1.2 USD - 1 USD = 2 AUD A single-roundtrip EAP method is used here, to illustrate how Cost advertisement extensions are handled in this case. When using an EAP method with more roundtrips, subsequent roundtrips are exactly similar to the first one regarding cost information. WISP --> ROAM1 Access-Request User-Name=toto@home Cost-Advertisement Type 0=1 EUR/mn ROAM1 --> ROAM2 Access-Request User-Name=toto@home Cost-Advertisement Type0=1.32 USD/mn ROAM2 --> HOME Access-Request User-Name=toto@home Cost-Advertisement Type0=2 AUD + 2.94 AUD/mn Caron Informational - Expires December 2002 12 INTERNET-DRAFT AAA Cost Advertisement Extensions June 2002 ROAM2 <-- HOME Access-Challenge EAP-Message=EAP/Request/Method ROAM1 <-- ROAM2 Access-Challenge EAP-Message=EAP/Request/Method WISP <-- ROAM1 Access-Challenge EAP-Message=EAP/Request/Method WISP --> ROAM1 Access-Request User-Name=toto@home EAP-Message=EAP/Response/Method Cost-Advertisement Type 0=1 EUR/mn ROAM1 --> ROAM2 Access-Request User-Name=toto@home EAP-Message=EAP/Response/Method Cost-Advertisement Type0=1.32 USD/mn ROAM2 --> HOME Access-Request User-Name=toto@home EAP-Message=EAP/Response/Method Cost-Advertisement Type0=2 AUD + 2.94 AUD/mn ROAM2 <-- HOME Access-Accept EAP-Message=EAP/Success Cost-Accept Type0=2 AUD + 2.94 AUD/mn Signature by HOME ROAM1 <-- ROAM2 Access-Accept EAP-Message=EAP/Success Cost-Accept Type0=1.32 USD/mn Signature by ROAM2 WISP <-- ROAM1 Access-Challenge EAP-Message=EAP/Success Caron Informational - Expires December 2002 13 INTERNET-DRAFT AAA Cost Advertisement Extensions June 2002 Cost-Accept Type0=1 EUR/mn Signature by ROAM1 9.2 Fixed end-user cost In this scenario, the visited network wants to set the cost for the end-user (10 EUR), and will receive this less the commissions charged by intermediaries. ROAM1 wants 10% of the total (which is different from what happens in the first scenario), and converts to USD before sending to ROAM2. This one in turn wants 1 USD per connection, and converts to AUD before sending to HOME. HOME wants 20% of the total cost. The initial EAP roundtrips are not shown here. WISP --> ROAM1 Access-Request User-Name=toto@home EAP-Message=EAP/Response/Method Cost-Advertisement Type 1=10 EUR ROAM1 --> ROAM2 Access-Request User-Name=toto@home EAP-Message=EAP/Response/Method Cost-Advertisement Type1=12 USD Type2=1.2 USD ROAM2 --> HOME Access-Request User-Name=toto@home EAP-Message=EAP/Response/Method Cost-Advertisement Type1=24 USD Type2=4.4 USD ROAM2 <-- HOME Access-Accept EAP-Message=EAP/Success Cost-Accept Type0=19.2 AUD Signature by HOME ROAM1 <-- ROAM2 Access-Accept EAP-Message=EAP/Success Cost-Accept Caron Informational - Expires December 2002 14 INTERNET-DRAFT AAA Cost Advertisement Extensions June 2002 Type0=8.6 USD Signature by ROAM2 WISP <-- ROAM1 Access-Challenge EAP-Message=EAP/Success Cost-Accept Type0=6.45 EUR Signature by ROAM1 10 Security Considerations In a roaming environment, where AAA transactions result in money exchanges, it is important that security of these transactions is guaranteed. For this reason, one should: - use only secure AAA mechanisms, such as Diameter or RADIUS over IPsec. - ensure that strong authentication mechanisms (such as EAP-SRP [8], EAP-TLS [9]...) are used. Also, to ensure non-repudiation of cost acceptance, this specification introduces digital signature of Cost-Accept attributes. Proper security measures to protect the keys used should be put in place to ensure the validity of these signatures. 11 References 1 RFC 2865, C. Rigney, Willens, S., Rubens, A., Simpson, W., "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 2 RFC 2866, C. Rigney, "RADIUS Accounting", RFC 2866, June 2000. 3 RFC 2869, C. Rigney, Willats, W., Calhoun, P., "RADIUS Extensions", RFC 2869, June 2000. 4 , P. Calhoun, Arkko, J., Guttman, E., Zorn, G., Louhhney, J., "Diameter Base Protocol", work in progress, April 2002. 5 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 6 RFC 2486, B. Aboba, Beadles, M., "The Network Access Identifier", RFC 2486, January 1999. Caron Informational - Expires December 2002 15 INTERNET-DRAFT AAA Cost Advertisement Extensions June 2002 7 , Caron, J., "DNS-Based Roaming", April 2000, work in progress. 8 , Carlson, J., B. Aboba, H. Haverinen, "EAP SRP-SHA1 Authentication Protocol", July 2001, work in progress. 9 RFC 2716, Aboba, B., D. Simon, "PPP EAP TLS Authentication Protocol", October 1999. Caron Informational - Expires December 2002 16 INTERNET-DRAFT AAA Cost Advertisement Extensions June 2002 12 Author's Address Jacques Caron IP Sector Technologies Ecluse 36c 2000 Neuchatel Switzerland Phone: +41 79 699 8389 Email: jcaron@ipsector.com Caron Informational - Expires December 2002 17