idnits 2.17.00 (12 Aug 2021) /tmp/idnits12334/draft-caron-aaa-cost-advertisement-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2002) is 7280 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 110 looks like a reference -- Missing reference section? '2' on line 110 looks like a reference -- Missing reference section? '3' on line 110 looks like a reference -- Missing reference section? '4' on line 110 looks like a reference -- Missing reference section? '5' on line 125 looks like a reference -- Missing reference section? '6' on line 140 looks like a reference -- Missing reference section? '7' on line 414 looks like a reference -- Missing reference section? '8' on line 714 looks like a reference -- Missing reference section? '9' on line 715 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Jacques Caron 3 INTERNET-DRAFT IP Sector Technologies 4 Expires: December 2002 June 2002 6 AAA cost advertisement extensions 8 10 1 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 2 Abstract 33 In many roaming scenarios, it is necessary to be able to carry cost 34 information between the different parties in order to facilitate 35 credit checking, real-time accounting, cost presentation to the 36 user. It is also necessary that this information be interpretable by 37 automated systems, that these systems be able to modify it to take 38 commissions into account, and that non-repudiation mechanisms be 39 available. This document proposes such a system to be used with AAA 40 architectures. 42 Table of Contents 44 1 Status of this Memo..............................................1 45 2 Abstract.........................................................1 46 3 Introduction.....................................................2 47 4 Terminology......................................................3 48 5 Conventions used in this document................................3 49 6 Description of the overall setup.................................3 50 7 Billing formats..................................................4 51 8 AAA attributes...................................................7 52 8.1 Cost advertisement attribute...................................7 53 8.2 Cost acceptance attribute.....................................10 54 9 Examples........................................................12 55 9.1 Fixed visited network cost....................................12 56 9.2 Fixed end-user cost...........................................14 57 10 Security Considerations........................................15 58 11 References.....................................................15 59 12 Author's Address...............................................17 61 3 Introduction 63 In many roaming contexts, in particular public WLAN roaming, costs 64 incurred for connection to foreign networks can vary significantly. 65 Costs can also vary according to the user's subscription plan, and 66 to the exact relationship (possibly multi-level) between the visited 67 network and the commercial operator that bills the end-user, in such 68 a manner that it is difficult to determine these costs in advance. 70 For these reasons, it appears necessary to be able to: 72 - verify that a user can use such a connection, based on its 73 subscription plan and any credit-checking that could be needed; 75 - present costs to the user during connection setup time; 77 - be able to carry billing and accounting information in real time 78 between the different parties involved (the visited network, the 79 commercial operator, and eventually one or many roaming operators in 80 between). 82 This billing and accounting information is not necessarily the same 83 over the whole chain, since intermediate roaming operators are 84 likely to take a commission on transaction they handle and for which 85 they manage compensation. 87 It is also important for all parties to be sure that they will get 88 payment for the services provided, and hence non-repudiation 89 mechanisms are needed on all commercial relationships involved: 91 - between the end-user and its home network (out of the scope of 92 this document) 94 - between each pair of operators along the path between the visited 95 network and the home network, via possible one or many roaming 96 operators. 98 Finally, cost information can be expressed in many different ways, 99 ranging from a simple fixed cost per connection to complex variable 100 costs based on duration or volume. Similarly, the commissions can be 101 either added to the cost requested by the visited network (the cost 102 to the end-user being then higher), or accounted separately (the 103 cost to the end-user being exactly what the visited network 104 proposes, but the home network getting a smaller share of the 105 total). Any specification must account for this variety of different 106 formats. 108 This document aims to describe such a specification for carrying 109 cost information within AAA protocols, more specifically RADIUS 110 [1,2,3] or Diameter [4]. 112 4 Terminology 114 WISP Wireless Internet Service Provider. An organization which 115 provides access to the Internet via Wireless LAN 116 infrastructure. 118 WLAN Wireless LAN, using e.g. IEEE 802.11 protocols. 120 5 Conventions used in this document 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 124 this document are to be interpreted as described in RFC-2119 [5]. 126 6 Description of the overall setup 128 To help in the understanding of the specification, we will use a 129 typical example of a multi-level roaming scenario, in which two 130 roaming operators are intermediaries between the visited network and 131 the home network: 133 +----+ +----+ +-----+ +-----+ +----+ 134 |USER| ---> |WISP| ---> |ROAM1| ---> |ROAM2| ---> |HOME| 135 +----+ +----+ +-----+ +-----+ +----+ 136 / / | 137 +----+ <-----------------------------------------------+ 139 In this scenario, the USER attempts to connect to WISP. It provides 140 an identity in the form of a NAI [6], which the WISP uses to route 141 (using a method like that described in [7]) an authentication and/or 142 authorization request towards the HOME network. Given the various 143 bi-lateral agreements in place, it actually sends the AA request to 144 ROAM1, which in turn sends it to ROAM2, and this one finally sends 145 it to HOME. Optionally, HOME may send a request (using an other 146 protocol not described here) to USER to verify that USER agrees to 147 the costs associated with this connection. These requests follow the 148 direction of the top arrows in the above diagram. 150 AA responses are sent along the same path in the reverse direction, 151 and match money flows: HOME will pay ROAM2, who will pay ROAM1 152 (after deducting its commission), ROAM1 will do the same to WISP. 153 Obviously, though, WISP will not pay USER, but USER will pay HOME. 154 For this reason, these responses need to have non-repudiation 155 mechanisms (digital signatures) to guarantee payment in exchange for 156 the service provided. 158 7 Billing formats 160 This specifications aims to take into account a wide variety of 161 billing formats, in order to accommodate various business models. 162 They are described using the following structures. 164 The format begins with a header structure: 166 +---------------+--------------------------------------------+ 167 | Decimals | Currency | 168 +---------------+---------------+----------------------------+ 169 | Number of types | Reserved | 170 +-------------------------------+----------------------------+ 172 - Decimals in the number of decimals in the decimal representation 173 of currency units. For instance, if Decimals is 2, then a value of 174 150 means 1.50 of the currency unit. 176 - Currency is the ISO 4217 code of the currency used. It is expected 177 that on any given relationship, only one currency will be used (the 178 currency used for the actual billing between the two entities), and 179 that roaming operators will perform conversion between currencies if 180 they have relationships with entities using different currencies. 181 This information is used for confirmation purposes, and for events 182 of currency changes (like the switch from national currencies to the 183 Euro). 185 - Number of types is the number of different billing types 186 following, as described further. 188 After the cost header, comes the type header, which describes the 189 type of billing to be performed: 191 +-------------------------------+----------------------------+ 192 | Type | Number of units | 193 +-------------------------------+----------------------------+ 195 - Type describes what is counted to perform billing. Possible values 196 are: 198 1 Transaction: this is a one-off cost 199 2 Duration: billing is based on duration in seconds 200 3 Bytes in: billing is based on bytes received 201 4 Bytes out: billing is based on bytes sent 202 5 Bytes total: billing is based on total bytes 204 - Number of units indicates the number of billing units that follow. 205 Must be 1 for Type 1. 207 Billing units are described using the following format: 209 +------------------------------------------------------------+ 210 | Amount | 211 +------------------------------------------------------------+ 212 | Quantity | 213 +------------------------------------------------------------+ 214 | Repeat | 215 +------------------------------------------------------------+ 217 - Amount is the amount of money that should be billed. The value 218 stored here should be divided by 10^decimals to get the number of 219 currency units. 221 - Quantity is the number of seconds or bytes that this amount will 222 cover. 0 means none, and all ones means unlimited. This field is 223 ignored for a Type of Transaction. 225 - Repeat is the number of times this unit will be repeated before 226 moving on to the next one. 0 means unlimited. This field is ignored 227 for a Type of Transaction. 229 Here are some examples: 231 00 'E' 'U' 'R' 232 00 01 00 00 233 00 01 00 01 234 00 00 00 0A 235 00 00 00 00 236 00 00 00 00 238 This indicates we bill in Euros (EUR), and amounts are given with no 239 decimals (0). There is one billing type, which is a transaction, 240 with only one unit, indicating an amount of 10. 242 In short: a cost of 10 euros for the transaction. 244 The same information could be represented as follows: 246 00 'E' 'U' 'R' 247 00 01 00 00 248 00 02 00 01 249 00 00 00 0A 250 FF FF FF FF 251 00 00 00 00 253 The difference being that billing is based on duration, but the 254 first (and only) duration billing unit is unlimited (FFFFFFFF). 256 An example of volume billing: 258 04 'U' 'S' 'D' 259 00 01 00 00 260 00 05 00 01 261 00 00 00 0F 262 00 00 04 00 263 00 00 00 00 265 Here we bill in US dollars (USD), with 4 decimals. There is one 266 billing type, which is based on total volume, and one unit, which 267 indicates that each kilobytes (0x400 = 1024 bytes) is billed 0.0015 268 USD (the value is 15 but we have 4 decimals). Measured quantities 269 should be rounded up to the next billing quantity. 271 An example of billing with an initial payment for a long period, 272 then smaller increments for additional time: 274 02 'E' 'U' 'R' 275 00 01 00 00 276 00 02 00 02 277 00 00 01 F4 278 00 00 03 84 279 00 00 00 01 280 00 00 00 32 281 00 00 00 3C 282 00 00 00 00 284 In this case we bill in euros with 2 decimals. There is one billing 285 type, which is based on duration, and two units. The first unit 286 indicates a cost of 5.00 EUR (0x1F4 = 500) for the first 15 minutes 287 (0x384 = 900 seconds). This unit is used once, after which 288 additional time is billed 0.50 EUR (0x32 = 50) per minute (0x3C = 60 289 seconds), indefinitely. 291 This last examples describes a scenario where we bill based on two 292 different quantities (here volume in and volume out): 294 02 'E' 'U' 'R' 295 00 02 00 00 296 00 03 00 01 297 00 00 00 0A 298 00 00 04 00 299 00 00 00 00 300 00 04 00 01 301 00 00 00 14 302 00 00 04 00 303 00 00 00 00 305 In this scenario we still bill in euros with 2 decimals, and there 306 are two billing types. The first one is based on volume in, and has 307 one unit of 0.10 EUR per kilobyte received, indefinitely. The second 308 billing type is based on volume out, and has one unit of 0.20 EUR 309 per kilobyte sent, indefinitely. 311 Many other combinations are possible, such as billing based on 312 duration and volume, free initial periods, discounts after a certain 313 time or volume, etc. 315 8 AAA attributes 317 In order to support the required functionality, the following new 318 attributes are required: 320 - a cost advertisement attribute 322 - a cost acceptance attribute 324 8.1 Cost advertisement attribute 326 The cost advertisement attribute Cost-Advertisement (code TBD) is 327 used in authorization requests, or in protocols such as RADIUS that 328 do not make a distinction between authentication and authorization 329 requests, in Access-Request packets. 331 In this last case, and if authentication takes several round-trips 332 (with Access-Challenge responses for authentication protocols such 333 as CHAP, ARAP, or EAP), the cost advertisement attribute should be 334 ignored by the AAA server until authentication is complete. 335 Intermediate proxies not being able to determine in advance whether 336 an Access-Request will be the final one, should handle all requests 337 the same. 339 The attribute format (excluding code and length portions which are 340 specific to the AAA protocol), is defined below: 342 +------------------------------------------------------------+ 343 | Flags | 344 +------------------------------+-----------------------------+ 345 | Type | Length | 346 +------------------------------------------------------------+ 347 | Cost data | 348 . ... . 349 +------------------------------+-----------------------------+ 350 | Type | Length | 351 +------------------------------------------------------------+ 352 | Cost data | 353 . ... . 354 +------------------------------------------------------------+ 356 - Flags is a bitmap of global flags. Currently, all bits are 357 reserved, and should be set to 0. 359 - Type indicates the type of cost information following. It can have 360 the following values: 362 - 0 indicates this is the cost requested. Further parties along 363 the authorization chain should increment this cost to include their 364 commission or charges. In this case, there should be only one cost 365 element (type, length, cost data) present in the packet. 367 - 1 indicates this is the cost that the visited network (the 368 party originating the request) wants to charge the end-user. Further 369 parties along the authorization chain should leave this cost 370 unchanged, but add or increment a cost information element with type 371 2. The initial request (from the visited network to the first 372 roaming operator along the path) might contain only one cost element 373 (type, length, cost data). Further along the path, there should be 374 two elements, one with type 1 representing the cost the user should 375 be charged, and one with type 2 representing commissions and charges 376 of other parties. Only per-connection costs (i.e. with no variable 377 duration-based or volume-based costs) are allowed. 379 - 2 indicates this is the added cost that intermediate parties 380 want to charge for this transaction. Only per-connection costs (i.e. 381 with no variable duration-based or volume-based costs) are allowed. 383 - Length is the length of the cost data (excluding type and length) 385 - Cost data is cost information encoded as specified in section 7. 387 There can be one or two cost elements (type, length, cost data) in 388 the request. There can be one of type 0 or 1, or two of types 1 and 389 2 respectively. It is illegal to have a request containing: 391 - a cost element of type 0 and another cost element; 393 - more than one cost element of the same type; 395 - a cost element of type 2 with no cost element of type 1. 397 Such requests should be rejected with code TBD. 399 Upon reception of a request containing a Cost-Advertisement 400 attribute, roaming operators should: 402 - store cost elements received for this request; 404 - if there is a cost element of type 0, increment it with their 405 charges; 407 - if there is a cost element of type 1 and no cost element of type 408 2, create one cost element of type 2 with their charges; 410 - if there is a cost element of type 1 and one of type 2, increment 411 this last one with their charges; 413 - find which other party the request should be sent to, either via 414 static tables, or using a dynamic protocol as described in [7]; 416 - convert all cost information to the appropriate currency. 418 Note that a roaming operator might use several AAA proxies or 419 relays. In such a case, some of the nodes might carry the attribute 420 transparently, while others will perform the above functions. 422 Upon reception of an authorization request containing a Cost- 423 Advertisement attribute, and after successful authentication and 424 other authorization is performed, the home server should: 426 - store cost elements received for this request; 428 - if there is a cost element of type 0 or of type 1, use it for 429 credit-checking purposes and optional end-user cost advertisement; 431 - if the user does not pass credit-check tests, or rejects the cost, 432 authorization can be rejected, and none of the attributes defined in 433 this document need to be present; 435 - if there is a cost element of type 0, send it back in a Cost- 436 Accept attribute (defined below), with a proper digital signature; 438 - if there is a cost element of type 1, deduct cost information from 439 cost element of type 2 and any local costs that should be deducted, 440 and send the result back in a Cost-Accept attribute (defined below), 441 with a proper digital signature. 443 - if there is a maximum amount a user can be billed (e.g. pre-paid 444 users), then information from the Cost-Advertisement attributes can 445 be used to compute a maximum amount of time the user is allowed to 446 be connected, and sent back to the requestor in appropriate AAA 447 attributes. 449 Discussion: 451 One might want to be able to carry cost information of type 1 452 in the original currency, for inclusion on the end user's bill. 453 However, since this information is used to compute compensation 454 between the different parties, which happens in fixed currencies, 455 the information must also be converted. An extra informational cost 456 element might need to be introduced to address this issue, but it 457 might make inconsistencies in currency conversion (which would 458 otherwise be "hidden" in the commissions/charges) a bit too obvious. 460 Discussion: 462 One might want to be able to support a maximum commission that 463 can be deducted from the amount billed to the end-user to compute 464 the amount paid back to the visited network, and further charges 465 would be added the amount billed to the end-user (reproducing what 466 happens with credit cards, where merchants pay a fixed commission, 467 but international transactions incur additional fees for the end- 468 user). This would require using the cost element types differently: 469 0 would be the base amount, 1 would be commissions charged to the 470 visited network, and 2 commissions charged to the end-user, for 471 instance. 473 Discussion: 475 Using maximum credit to give a maximum connection time works 476 only for duration-based billing. In other situations, a maximum cost 477 information might be needed instead, with the usual options when 478 that amount is used up: terminate, re-authenticate... 480 8.2 Cost acceptance attribute 482 The cost acceptance attribute Cost-Accept (code TBD) is used in 483 positive authorization responses, when the corresponding request 484 contained a Cost-Advertisement attribute. A client that submits a 485 request with a Cost-Advertisement attribute, but does not receive a 486 Cost-Accept attribute in the associated positive response, knows 487 that at least one node on the AAA path does not support these 488 extensions, and can drop the connection. 490 The cost acceptance attribute is used to carry: 492 - for requests that used cost elements with types 1 and 2, 493 information the charges that will be levied off the cost billed to 494 the user by intermediate parties; 496 - for all requests, digital signatures from the upstream operator 497 confirming that the costs are accepted. 499 The cost acceptance attribute (excluding code and length information 500 that is specific to the AAA protocol used) has the following format: 502 +------------------------------------------------------------+ 503 | Flags | 504 +------------------------------+-----------------------------+ 505 | Cost Data Type | Cost Data Length | 506 +------------------------------+-----------------------------+ 507 | Signature Type | Signature Length | 508 +------------------------------+-----------------------------+ 509 | Cost Data | 510 . ... . 511 +------------------------------------------------------------+ 512 | Signature Data | 513 . ... . 514 +------------------------------------------------------------+ 516 - Flags is a bitmap of global flags. Currently, all bits are 517 reserved, and should be set to 0. 519 - Cost Data Type indicates the type of cost information following. 520 It can have the following values: 522 - 0 indicates that this is the net cost that is accepted for 523 this transaction. It should be the same as the cost in a type 0 cost 524 element submitted in a Cost-Advertisement attribute in the 525 corresponding request, or value lower than that submitted in a type 526 1 Cost-Advertisement attribute; 528 - no other values are defined yet. 530 - Cost Data length is the length of the cost data information, in 531 bytes, excluding types, lengths, and signature data. 533 - Signature type indicates the type of signature. The following 534 values are defined: 536 - 0 indicates a signature of type MD5 538 - 1 indicates a signature of type SHA-1 540 - Signature length is the length of the signature data field. 542 - Cost data is encoded as described in section 7. 544 - Signature data contains a signature of the type described in the 545 Signature type field, computed over the Cost Data field, using the 546 key of the sender of the attribute. 548 Transmission of key or certificate information between roaming 549 partners is outside the scope of this specification. 551 9 Examples 553 To illustrate the use of the attributes defined in this document, we 554 will describe some examples of scenarios using the setup defined in 555 section 6. 557 9.1 Fixed visited network cost 559 In this scenario, the visited network wants to be paid a fixed 560 amount (1 EUR per minute), whatever the cost may be for the end- 561 user. The first roaming operator takes a 10% commission, and 562 converts to USD before sending to the second roaming operator. This 563 operator adds a 1 USD per connection + 0.15 USD per minute charge, 564 and converts to AUD before sending to the home server, which charges 565 the end-user whatever amount they want. 567 Totally fictitious currency rates used are: 569 - 1 EUR = 1.2 USD 571 - 1 USD = 2 AUD 573 A single-roundtrip EAP method is used here, to illustrate how Cost 574 advertisement extensions are handled in this case. When using an EAP 575 method with more roundtrips, subsequent roundtrips are exactly 576 similar to the first one regarding cost information. 578 WISP --> ROAM1 579 Access-Request 580 User-Name=toto@home 581 Cost-Advertisement 582 Type 0=1 EUR/mn 584 ROAM1 --> ROAM2 585 Access-Request 586 User-Name=toto@home 587 Cost-Advertisement 588 Type0=1.32 USD/mn 590 ROAM2 --> HOME 591 Access-Request 592 User-Name=toto@home 593 Cost-Advertisement 594 Type0=2 AUD + 2.94 AUD/mn 595 ROAM2 <-- HOME 596 Access-Challenge 597 EAP-Message=EAP/Request/Method 599 ROAM1 <-- ROAM2 600 Access-Challenge 601 EAP-Message=EAP/Request/Method 603 WISP <-- ROAM1 604 Access-Challenge 605 EAP-Message=EAP/Request/Method 607 WISP --> ROAM1 608 Access-Request 609 User-Name=toto@home 610 EAP-Message=EAP/Response/Method 611 Cost-Advertisement 612 Type 0=1 EUR/mn 614 ROAM1 --> ROAM2 615 Access-Request 616 User-Name=toto@home 617 EAP-Message=EAP/Response/Method 618 Cost-Advertisement 619 Type0=1.32 USD/mn 621 ROAM2 --> HOME 622 Access-Request 623 User-Name=toto@home 624 EAP-Message=EAP/Response/Method 625 Cost-Advertisement 626 Type0=2 AUD + 2.94 AUD/mn 628 ROAM2 <-- HOME 629 Access-Accept 630 EAP-Message=EAP/Success 631 Cost-Accept 632 Type0=2 AUD + 2.94 AUD/mn 633 Signature by HOME 635 ROAM1 <-- ROAM2 636 Access-Accept 637 EAP-Message=EAP/Success 638 Cost-Accept 639 Type0=1.32 USD/mn 640 Signature by ROAM2 642 WISP <-- ROAM1 643 Access-Challenge 644 EAP-Message=EAP/Success 645 Cost-Accept 646 Type0=1 EUR/mn 647 Signature by ROAM1 649 9.2 Fixed end-user cost 651 In this scenario, the visited network wants to set the cost for the 652 end-user (10 EUR), and will receive this less the commissions 653 charged by intermediaries. ROAM1 wants 10% of the total (which is 654 different from what happens in the first scenario), and converts to 655 USD before sending to ROAM2. This one in turn wants 1 USD per 656 connection, and converts to AUD before sending to HOME. HOME wants 657 20% of the total cost. 659 The initial EAP roundtrips are not shown here. 661 WISP --> ROAM1 662 Access-Request 663 User-Name=toto@home 664 EAP-Message=EAP/Response/Method 665 Cost-Advertisement 666 Type 1=10 EUR 668 ROAM1 --> ROAM2 669 Access-Request 670 User-Name=toto@home 671 EAP-Message=EAP/Response/Method 672 Cost-Advertisement 673 Type1=12 USD 674 Type2=1.2 USD 676 ROAM2 --> HOME 677 Access-Request 678 User-Name=toto@home 679 EAP-Message=EAP/Response/Method 680 Cost-Advertisement 681 Type1=24 USD 682 Type2=4.4 USD 684 ROAM2 <-- HOME 685 Access-Accept 686 EAP-Message=EAP/Success 687 Cost-Accept 688 Type0=19.2 AUD 689 Signature by HOME 691 ROAM1 <-- ROAM2 692 Access-Accept 693 EAP-Message=EAP/Success 694 Cost-Accept 695 Type0=8.6 USD 696 Signature by ROAM2 698 WISP <-- ROAM1 699 Access-Challenge 700 EAP-Message=EAP/Success 701 Cost-Accept 702 Type0=6.45 EUR 703 Signature by ROAM1 705 10 Security Considerations 707 In a roaming environment, where AAA transactions result in money 708 exchanges, it is important that security of these transactions is 709 guaranteed. For this reason, one should: 711 - use only secure AAA mechanisms, such as Diameter or RADIUS over 712 IPsec. 714 - ensure that strong authentication mechanisms (such as EAP-SRP [8], 715 EAP-TLS [9]...) are used. 717 Also, to ensure non-repudiation of cost acceptance, this 718 specification introduces digital signature of Cost-Accept 719 attributes. Proper security measures to protect the keys used should 720 be put in place to ensure the validity of these signatures. 722 11 References 724 1 RFC 2865, C. Rigney, Willens, S., Rubens, A., Simpson, W., 725 "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, 726 June 2000. 728 2 RFC 2866, C. Rigney, "RADIUS Accounting", RFC 2866, June 2000. 730 3 RFC 2869, C. Rigney, Willats, W., Calhoun, P., "RADIUS 731 Extensions", RFC 2869, June 2000. 733 4 , P. Calhoun, Arkko, J., 734 Guttman, E., Zorn, G., Louhhney, J., "Diameter Base Protocol", 735 work in progress, April 2002. 737 5 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate 738 Requirement Levels", BCP 14, RFC 2119, March 1997 740 6 RFC 2486, B. Aboba, Beadles, M., "The Network Access Identifier", 741 RFC 2486, January 1999. 743 7 , Caron, J., "DNS-Based 744 Roaming", April 2000, work in progress. 746 8 , Carlson, J., B. Aboba, H. 747 Haverinen, "EAP SRP-SHA1 Authentication Protocol", July 2001, 748 work in progress. 750 9 RFC 2716, Aboba, B., D. Simon, "PPP EAP TLS Authentication 751 Protocol", October 1999. 753 12 Author's Address 755 Jacques Caron 756 IP Sector Technologies 757 Ecluse 36c 758 2000 Neuchatel 759 Switzerland 760 Phone: +41 79 699 8389 761 Email: jcaron@ipsector.com