idnits 2.17.00 (12 Aug 2021) /tmp/idnits58812/draft-lior-radius-prepaid-extensions-01.txt: 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: ---------------------------------------------------------------------------- == There are 27 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Note that the PrePaid Server role is not to record accounting messages and therefore it SHOULD not respond with an Accounting Response packet. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Authorize Only Access-Request MUST not include either User Password or Chap Password. In order to authenticate the message, the Access Device must include the Message-Authenticator(80) attribute. The Access Device will compute the value for the Message-Authenticator based on [RFC2869]. -- 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 30, 2003) is 6899 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2868' is defined on line 1136, but no explicit reference was found in the text == Outdated reference: draft-chiba-radius-dynamic-authorization has been published as RFC 3576 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lior 3 INTERNET-DRAFT Bridgewater Systems 4 Category: Informational P. Yegani 5 draft-lior-radius-prepaid-extensions-01.txt Cisco 6 Expires: 30 December 2003 K. Chowdhury 7 Nortel 8 L. Madour 9 Ericsson Canada 10 Y. Li 11 Bridgewater Systems 12 June 30, 2003 14 PrePaid Extensions to Remote Authentication Dial-In User Service 15 (RADIUS) 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of [RFC2026]. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as 30 reference material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Copyright Notice 39 Copyright (C) The Internet Society (2003). All Rights Reserved. 41 Abstract 43 The draft presents an extension to the Remote Authentication Dial-In 44 User Service (RADIUS) protocol to support PrePaid data services for 45 a wide range of deployments such as Dial, Wireless, WLAN. 46 Consideration for roaming using mobile-ip is also given. 48 Table of Contents 50 1. Introduction...................................................3 51 1.1 Terminology................................................4 52 1.2 Requirements language......................................4 53 2. Use-cases......................................................4 54 2.1 Simple use-case............................................5 55 2.2 Quota Recovery.............................................6 56 2.3 Support for concurrent PrePaid sessions....................7 57 2.4 Support for Roaming........................................7 58 2.5 PrePaid termination........................................8 59 3. Architecture...................................................8 60 4. Operations....................................................12 61 4.1 General Requirements......................................12 62 4.1.1 Broker AAA Requirements..............................12 63 4.2 Authentication and Authorization..........................12 64 4.3 Session Start Operation...................................15 65 4.4 Mid-Session Operation.....................................15 66 4.5 Dynamic Operations........................................17 67 4.5.1 Unsolicited Session Termination Operation............17 68 4.5.2 Unsolicited Change of Authorization Operation........18 69 4.6 Termination Operation.....................................19 70 4.7 Mobile IP Operations......................................20 71 4.8 Accounting Considerations.................................20 72 4.9 Interoperability with Diameter............................21 73 5. Attributes....................................................21 74 5.1 PPCC attribute............................................21 75 5.2 Dynamic-Capabilities attribute............................22 76 5.3 PPAQ Attribute............................................23 77 5.4 Table of Attributes.......................................26 78 6. Security Considerations.......................................26 79 6.1 Authentication and Authorization..........................26 80 6.2 Replenishing Procedure....................................27 81 7. IANA Considerations...........................................27 82 8. Normative References..........................................27 83 Acknowledgments..................................................28 84 Author's Addresses...............................................28 85 Intellectual Property Statement..................................28 86 Full Copyright Statement.........................................29 87 Expiration Date..................................................29 89 1. Introduction 91 This draft describes RADIUS protocol extensions supporting PrePaid 92 Data Services. 94 PrePaid data services are cropping up in many wireless and wireline 95 based networks. A PrePaid Data Service subscriber is one that 96 purchases a contract to deliver a data service for either a period 97 of time, or a quantity of data. The subscriber purchases the Data 98 Service using various means such as buying a PrePaid Card, or 99 online. How the subscriber purchases his PrePaid Data Service 100 depends on the deployment and is not in scope for this document. 102 In some deployments, the PrePaid data service will be combined with 103 a PrePaid voice service. This is not an issue for this document 104 other than the fact that the PrePaid Data Services described in this 105 paper should work with other PrePaid data services. 107 The fundamental business driver for a carrier to provide PrePaid 108 data services is to increase participation (subscriber base) and 109 thus to increase revenues. Therefore, it makes sense that PrePaid 110 services meet the following goals: 112 - Leverage existing infrastructure, hence reducing capital 113 expenditures typically required when rolling a new service; 114 - Protect against revenue loss; 115 - Protect against fraud; 116 - Be as widely deployable over Dialup, Wireless and WLAN networks. 118 The protocol described in this document maximizes existing 119 infrastructure as much as possible û hence the use of the RADIUS 120 protocol. The protocol is used in ways to protect against revenue 121 loss or revenue leakage. This is achieved by allocating small 122 quotas to each data session and having the ability to update the 123 quotas dynamically during the lifetime of the PrePaid data session. 124 As well, mechanisms have been designed to be able to recover from 125 errors that occur from time to time. 127 Protection against fraud is provided by recording of accounting 128 records, by providing mechanisms to thwart replay attacks. As well, 129 mechanisms have been provided to terminate data sessions when fraud 130 is detected. 132 PrePaid System will become more prevalent and sophisticated as the 133 various networks such as Dialup, Wireless and WLAN converge. This 134 protocol extension is designed to meet the challenges of converged 135 networks. 137 The draft mainly addresses how to use the RADIUS protocol to achieve 138 a PrePaid Data Service. The details of the PrePaid System, such as 139 its persistent store, its rating capabilities, how it maintains its 140 accounts are not covered at all. However, in order to define the 141 RADIUS protocol extensions it is necessary to discuss the functional 142 behavior of the PrePaid System. 144 1.1 Terminology 146 Access Device 147 PrePaid Client 148 PrePaid Server 149 Home agent (HA) 150 Home network 151 Home AAA (HAAA) 152 Broker AAA (BAAA) 153 Visited AAA (VAAA) 154 Foreign Agent (FA) 155 WLAN 157 1.2 Requirements language 159 In this document, several words are used to signify the requirements 160 of the specification. These words are often capitalized. The key 161 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 163 this document are to be interpreted as described in [RFC2119]. 165 2. Use-cases 167 In this section we present a set of use cases that will help 168 establish the requirements needed to deliver PrePaid data services. 169 These use cases donÆt address how the PrePaid account is established 170 or maintained. It is assumed that the PrePaid subscriber has 171 obtained a valid account from a service provider such as a wireless 172 operator or a WLAN operator. 174 To make the document as general as possible, the use cases cover the 175 experience from the Access Device and not from the UserÆs Device. 176 The connection between the UserÆs Device, which typically involves 177 setting up a PPP session is specific to a given network technology 178 and the details are not required to deliver a PrePaid service. 180 2.1 Simple use-case 182 A PrePaid subscriber connects to his home network. As usual, the 183 Access Device that is servicing the subscriber will use the AAA 184 infrastructure to authenticate and authorize the subscriber. 186 The Access Device sends a RADIUS Access-Request to the AAA system to 187 authenticate the subscriber, and identify and authorize the service. 188 The Access-Request includes the subscriberÆs credentials and may 189 include the PrePaid capabilities of the Access Device. PrePaid 190 capabilities will be included if the Access Device supports PrePaid 191 functionality.. 193 The AAA System proceeds with the authentication procedure. This may 194 involve several transactions such as in EAP. Once the subscriber 195 has been validated, the AAA system determines that the subscriber is 196 a PrePaid subscriber and requests that the PrePaid System authorize 197 the PrePaid subscriber. The request may include the PrePaid 198 Capabilities of the serving Access Device. 200 The PrePaid System will validate that the subscriber has a PrePaid 201 Account; it will validate that the Account is Active; and will 202 validate that the Access Device has the appropriate PrePaid 203 capabilities. If all is in order, the PrePaid System will authorize 204 the subscriber to use the network. Otherwise it will reject the 205 request. The response is sent back to the AAA System. The response 206 includes attributes such as, an allocation of a portion of the 207 subscriberÆs account called the initial quota (in units of time or 208 volume) and optionally a threshold value. 210 In order to support concurrent PrePaid sessions, at any time, the 211 PrePaid System allocates a portion of the subscribers account to a 212 given PrePaid session. For example, the subscriber may be on a 213 PrePaid voice call and may also have a concurrent PrePaid data 214 session. Throughout the lifetime of a session the Access Device 215 will request quota updates from the PrePaid System. 217 The AAA system incorporates the PrePaid attributes received from the 218 PrePaid System with the service attributes into an Access Response 219 message that it sends back to the Access Device. Note the AAA 220 System is responsible for authorizing the service whereas the 221 PrePaid System is responsible for PrePaid authorization. 223 Upon receiving the Access Response, the Access Device allows the 224 PrePaid data session to start and it starts to meter the session 225 based on time or volume. 227 Once the usage for the session approaches the allotted quota (as 228 expressed by the threshold), the Access Device will, as instructed 229 by the PrePaid System, request an additional quota. The re- 230 authorization for additional quota flows through the AAA system to 231 the PrePaid System. The PrePaid System revalidates the subscriberÆs 232 account; it will subtract the previous quota allocation from the 233 userÆs balance and if there is a balance remaining it will 234 reauthorize the request with an additional quota allotment. 235 Otherwise, the PrePaid System will reject the request. Note the 236 replenishing of the quotas is a re-authorization procedure and does 237 not involve re-authentication of the subscriber. 239 It is important to note that the PrePaid System is maintaining 240 session state for the subscriber. This state includes how much was 241 allocated during the last quota allocation for a particular session 242 and how much is left in the account. Therefore, it is required that 243 all subsequent messages about the PrePaid session reach the correct 244 PrePaid System. 246 Upon receiving a re-allotment of the quota, the Access Device will, 247 continue the data service session until the new threshold is 248 reached. If the Access Device receives a rejection, then it will 249 let the subscriber use up the remaining quota and then terminate the 250 session. 252 Alternatively, instead of terminating the session, the Access Device 253 may restrict the data session such that the subscriber can only 254 reach a particular web server. This web server maybe used to allow 255 the subscriber to replenish their account. This restriction can 256 also be used to allow new subscribers to purchase a PrePaid Service. 258 2.2 Quota Recovery 259 In the above scenario, should the subscriber terminate the session 260 before the session the quota is used up, the remaining balance 261 allotted to the session must be credited back to the subscriberÆs 262 account. 264 As well, while the Access Device is waiting for the initial quota, 265 the subscriber may have dropped the session. The initial quota must 266 be credited back to the subscribers account. 268 2.3 Support for concurrent PrePaid sessions 270 The subscriber at any given time may initiate more than one session. 271 To support concurrent sessions the PrePaid System allocates a 272 portion of the account to any given session at any given time. 274 Each session is treated independently. 276 2.4 Support for Roaming 278 For some networks it is essential that PrePaid Data Services be 279 offered to roaming subscribers. Support for static and dynamic 280 roaming models are needed. Static roaming is where the subscriber 281 logs onto a foreign network. The foreign network has a roaming 282 agreement directly with the home network or through a broker network 283 or networks. The subscriber remains logged into the network until 284 the subscriber changes location. When changing location a new 285 connection and a new login procedure is required. 287 Dynamic roaming allows to subscriber to move between foreign 288 networks while maintaining a connection with the home network 289 seamlessly. As the subscriber moves between networks, the data 290 session is handed off between the networks. 292 In both roaming scenarios, the subscriber always authenticates with 293 the home network. PrePaid authorization and quota replenishing for 294 the session need to be received at the home network and more 295 specifically at the PrePaid System where state is being maintained. 297 Dynamic roaming is particularly challenging. A subscriber that 298 established a PrePaid Data Session may roam to another Access Device 299 that doesnÆt not support PrePaid functionality. The system should 300 be capable to continue the PrePaid session. 302 2.5 PrePaid termination 304 When fraud is detected by the PrePaid System, or when an error is 305 detected, it may be beneficial for the PrePaid system to terminate a 306 specific session for the subscriber or all the sessions of a 307 subscriber. 309 Some errors can occur such that the PrePaid System is in a state 310 where it is not sure whether the session is in progress or not. 311 Under conditions such as this, the PrePaid system may wish to 312 terminate the PrePaid data session to make sure that resources are 313 not being utilized for which it canÆt charge for reliably. 315 Some handoff procedure used during dynamic roaming may require that 316 the PrePaid system explicitly terminate the subscribers PrePaid data 317 session at an Access Device. For example, if time based PrePaid 318 service is being used and the mobile subscriber performs a dormant 319 handoff, the PrePaid System needs to explicitly terminate the 320 PrePaid session at the old Access Device. 322 3. Architecture 324 A PrePaid Data Service deployment consists of Access Devices, AAA 325 servers, and PrePaid Servers. The subscriber device is not 326 implicated in the delivery of PrePaid Data Services. In mobile-ip, 327 the Home Agent may also be implicated in delivering a PrePaid Data 328 Service. 330 In order to be have as general a solution as possible, in this paper 331 we generalize the Access Devices, which in reality may be a NAS from 332 in Dialup deployments, PDSN in CDMA2000 deployments or an 802.11 333 WLAN Access Point. To actively participate in PrePaid procedures 334 outlined here, the Access Device MUST have PrePaid Client 335 capabilities. PrePaid Client Capabilities include the ability to 336 meter the usage for a PrePaid data session; this usage includes time 337 or volume usage. An exception to this rule is during dynamic 338 roaming scenarios, where the Access Device can relegate its PrePaid 339 Client Capabilities to the Home Agent (HA). Furthermore, the Access 340 Device may also have Dynamic Session Capabilities that include the 341 ability to terminate a data session and/or change authorization 342 attributes associated with a specific data session by processing 343 Disconnect Messages and Change of Authorization messages as per 344 [CHIBA]. 346 In this document the AAA server uses the RADIUS protocol. There are 347 three kinds or categories of AAA servers. The AAA server in the 348 home network, the HAAA, is responsible for authentication of the 349 subscriber and also authorization of the service. In addition, the 350 HAAA communicates with the PrePaid servers using the RADIUS protocol 351 to authorize PrePaid subscribers. In roaming deployments the AAA 352 server in the visited network, the VAAA, is responsible for 353 forwarding the RADIUS messages to the HAAA. The VAAA may also 354 modify the messages. In roaming deployments, the visited network 355 may be separated from the home network by one or more broker 356 networks. The AAA servers in the broker networks, BAAA are 357 responsible for the routing of the RADIUS message to the HAAA. 359 The PrePaid Server is described in functional terms related to itÆs 360 interface with the HAAA. The PrePaid Server maintains the 361 accounting state of the PrePaid subscribers. As well, the PrePaid 362 Server maintains state for each active PrePaid data service session. 363 This state includes, allocated quotas, the last known activity 364 counters (time or volume) for the PrePaid subscriberÆs data session 365 and the servicing Access Device. These counters are continuously 366 being updated during the lifetime of the PrePaid data service. 368 The various deployments scenarios for PrePaid are presented in the 369 remainder of this section. The first deployment is the basic 370 PrePaid data service and is depicted in figure 1. Here the Access 371 Device and the HAAA and the PrePaid Server are collocated in the 372 same operator network. 374 The Subscriber Device establishes a connection with one of several 375 Access Devices in the network. The Access Device communicates with 376 one or more HAAA servers in the network. To provide redundancy more 377 then one HAAA is available to use by an Access Device. 379 The network will have one or more PrePaid Servers. Multiple PrePaid 380 Servers will be used to provide redundancy and load sharing. The 381 interface between the HAAA and the PPS is the RADIUS protocol in 382 this specification. However, in cases where the PPS does not 383 implement the RADIUS protocol, the implementation would have to map 384 the requirements defined in this document to whatever protocol is 385 used between the HAAA and the PPS. 387 +------+ +-----+ 388 | | | | 389 +--------+ +--------+ +--| HAAA |--+--| PPS | 390 | | | | | | | | | | 391 | Sub | | Access | | +------+ | +-----+ 392 | |---| |--+ | 393 | Device | | Device | | +------+ | +-----+ 394 | | | | | | | | | | 395 +--------+ +--------+ +--| HAAA |--+--| PPS | 396 | | | | 397 +------+ +-----+ 399 Figure 1 Basic PrePaid Architecture 401 The following figure shows a static roaming PrePaid architecture 402 that is typical of a wholesale scenario for Dial-Up users or a 403 broker scenario used in Dial-Up or WLAN roaming scenarios. 405 +----+ +----+ +----+ +-----+ 406 | | | | | | | | 407 +------+ +------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | 408 | | | | | | | | | | | | | | | | 409 |Sub | |Access| | +----+ | +----+ | +----+ | +-----+ 410 | |--| |-+ | | | 411 |Device| |Device| | +----+ | +----+ | +----+ | +-----+ 412 | | | | | | | | | | | | | | | | 413 +------+ +------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | 414 | | | | | | | | 415 +----+ +----+ +----+ +-----+ 417 | Visited | |Broker | | Home | 418 | Network | |Network| | Network | 420 Figure 2 Static Roaming PrePaid Architecture 422 As in the basic PrePaid architecture the subscriberÆs device 423 establishes a connection with the Access Device (NAS, WLAN Access 424 Point). The Access Device communicates with the Visiting AAA server 425 (VAAA) using the RADIUS protocol. Again for redundancy there maybe 426 more then one VAAA. The VAAA communicate using the RADIUS protocol 427 with AAA servers in the broker network (BAAA). There maybe more 428 then one Broker Network between the Visited Network and the Home 429 Network. The Home Network is the same as in the simple 430 architecture. 432 To support dynamic roaming the network will most likely utilize 433 mobile-ip. Figure 3 illustrates a typical mobile-ip deployment. 434 Note that typically the mobile device would be moving between 435 networks that use the same technology such as Wireless or WLAN. 436 Increasingly, device will be able to roam between networks that use 437 different technology such as between WLAN and Wireless and 438 Broadband. Fortunately, mobile-ip can address this type of roaming 439 and therefore we need not be concerned with the underlying network 440 technology. 442 +------+ +------+ +----+ +----+ +----+ +-----+ 443 | | | | | | | | | | | | 444 |Sub | |Access+-----|VAAA|--|BAAA|--|HAAA|--| PPS | 445 | |--|Device| | | | | | | | | 446 |Device| | (FA) +--+ +----+ +-+--+ +----+ +-----+ 447 | | | | | | 448 +------+ +------+ | | 449 | | | +----+ 450 | | | | | 451 |ROAMS +------------------+ HA | 452 | | | | 453 V +----+ | +----+ 454 +------+ +------+ | | | | 455 | | | | +-|VAAA+------+ | 456 |Sub | |Access| | | | | 457 | |--|Device+-+ +----+ | 458 |Device| | (FA) | | 459 | | | +------------------------+ 460 +------+ +------+ 462 Figure 3 Roaming using mobile-ip 464 In the figure 3, the Subscriber device establishes a PrePaid session 465 between the Access Device in the foreign network, which has PrePaid 466 capabilities and the Home Agent (HA). The setup for this service is 467 identical to the cases covered above. Notice that the Access Device 468 is known as the Foreign Agent (FA). As the subscriber device moves 469 to another network it establishes a connection with another Access 470 Device in another foreign network. The PrePaid data service should 471 continue to be available. When a device associates to another 472 Access Device it MUST re-authenticate at the new Access Device and 473 de-associate or logoff the old Access Device. Furthermore, any 474 unused quota at the old Access Device MUST be promptly credited back 475 to the subscribers account. The reason we say promptly, is because 476 if the subscriber is very low on resources to start with, the 477 subscriber may not have enough resources to log on to the new Access 478 Device. The speed at which resources can be returned depend on the 479 type of handoff procedure that is used: dormant handoff vs. active 480 handoff vs. fast handoff. 482 As well, notice that if the Access Devices could communicate with 483 each other then there could be a way to accelerate a faster handoff 484 procedure. In particular, it could accelerate the return of the 485 unused portion of the quotas from the old Access Device. 487 Unfortunately, standards are evolving with each network technology 488 creating their own scheme to make the handoff procedures more 489 efficient. 491 4. Operations 493 4.1 General Requirements 495 4.1.1 Broker AAA Requirements 497 Broker AAA servers MUST support the Message-Authenticator(80) 498 attribute as defined in [RFC2869]. If BAAA servers are used, the 499 BAAA servers function is to forward the RADIUS packets as usual to 500 the appropriate RADIUS servers. 502 Accounting messages are not needed to deliver a PrePaid service. 503 However, accounting messages can be used to keep the PrePaid Server 504 current as to what is happening with the PrePaid data session. 505 Therefore, BAAA SHOULD deliver RADIUS Accounting messages using the 506 pass through mode described in [RFC2866]. 508 4.2 Authentication and Authorization 510 The Access Device initiates the authentication and authorization 511 procedure by sending a RADIUS Access-Request as usual. 513 If the Access Device has PrePaid Client capabilities, it MUST 514 include the PPCC attribute in the RADIUS Access-Request. The PPCC 515 attribute indicates to the PrePaid server the PrePaid capabilities 516 possessed by the Access Device. These are required in order to 517 complete the PrePaid authorization procedures. 519 If the Access Device supports the Disconnect-Message or the Change- 520 of-Auhtorization capabilities, then it SHOULD include the Dynamic- 521 Capabilities attribute. 523 In certain deployments, there may be other ways in which to 524 terminate a data session, or change authorization of an active 525 session. For example, some Access Devices provide a session 526 termination service via Telnet or SNMP. In these cases, the AAA 527 server MAY add the Dynamic-Capabilities message to the Access- 528 Request. 530 If the authentication procedure involves multiple Access-Requests 531 (as in EAP), the Access Device MUST include the PPCC attribute and 532 the Dynamic-Capabilities attribute (if used) in at least the last 533 Access-Request of the authentication procedure. 535 The Access-Request will be sent as usual to the HAAA. The packet 536 may be proxied through zero or more BAAA. 538 Once the Access-Request arrives at the HAAA, the HAAA will 539 authenticate the subscriber. If the subscriber is not 540 authenticated, the HAAA will send an Access-Reject message back to 541 the client. If the subscriber is authenticated, the HAAA will 542 determine whether or not the subscriber is a PrePaid subscriber. 543 The techniques used to determine whether or not a subscriber is a 544 PrePaid subscriber is beyond the scope of this document. If the 545 subscriber is not a PrePaid subscriber, then the HAAA will respond 546 as usual with an Access-Accept or Access-Reject message. If the 547 subscriber is a PrePaid Subscriber the HAAA SHALL forward the 548 Access-Request to a PrePaid server for further authorization. 550 The Access-Request will contain the PPCC attribute, the Dynamic- 551 Capabilities attribute if one was included; the User-Name(1) 552 attribute MAY be set to a value that would represent the 553 SubscriberÆs PrePaid Identity. This attribute is used by the 554 PrePaid server to locate the PrePaid SubscriberÆs account. For 555 added security, the HAAA MAY also set the User-Password(2) attribute 556 to the password used between the HAAA and the PrePaid server. 558 The PrePaid server lookups the subscriberÆs PrePaid account and will 559 authorize the subscriber taking into consideration the Access Device 560 PrePaid Client Capabilities. 562 Upon successful authorization, the PrePaid server will generate an 563 Access-Accept containing the PPAQ attribute, which contains the 564 following sub-attributes: 566 - The QUOTA-Id which is set by the PrePaid server to a unique value 567 that is used to correlate subsequent quota requests; 569 - Volume and/or Time Quotas, one of which is set to a value 570 representing a portion of the subscribers account; 572 - MAY contain a Time or Volume Threshold that controls when the 573 Access Device requests additional quota; 575 - The IP address of the Serving PrePaid Server and one or more 576 alternative PrePaid Servers. This is used by the HAAA to route 577 subsequent quota replenishing messages to the appropriate PrePaid 578 server(s). 580 Depending on site policies, upon unsuccessful authorization, the 581 PrePaid server will generate an Access-Reject or an Access-Accept 582 and set the Filter-Id(11) or the Ascend-Data-Filter (if supported) 583 attribute and the Session-Timeout(27) attribute such that the 584 PrePaid subscriber could get access to a restricted set of locations 585 for a short duration to allow them to replenish their account, or 586 create an account; or to browse free content. 588 Upon receiving the Access-Accept from the PrePaid Server, the HAAA 589 will append the usual service attributes and forward the packet to 590 the Access Device. The HAAA SHALL NOT append or overwrite any 591 attributes already set by the PrePaid server. If the HAAA, receives 592 an Access-Reject message, it will simply forward the packet to its 593 client. Depending on site policies, if the HAAA fails to receive an 594 Access-Accept or Access-Reject message from the PrePaid server it 595 MAY do nothing or send an Access-Reject or an Access-Accept message 596 back to its client. 598 4.3 Session Start Operation 600 The real start of the session is indicated by the arrival of 601 Accounting-Request(Start) packet. The Accounting-Request (Start) 602 MAY be routed to the PrePaid Server so that it can confirm the 603 initial quota allocation. 605 Note that the PrePaid Server role is not to record accounting 606 messages and therefore it SHOULD not respond with an Accounting 607 Response packet. 609 4.4 Mid-Session Operation 611 During the lifetime of a PrePaid data session the Access Device 612 SHOULD be configured to generate Accounting-Request (Interim) and 613 will request to replenish the quotas using Authorize Only Access- 614 Request messages. 616 Once the allocated quota has been reached or the threshold has been 617 reached, the Access Device MUST send an Access-Request with Service- 618 Type(6) set to a value of ôAuthorize Onlyö and the PPAQ attribute. 620 The Access Device MUST also include NAS identifiers, and Session 621 identifier attributes in the Authorize Only Access-Request. The 622 Session Identifier should be the same as those used during the 623 Access-Request. For example, if the User-Name(1) attribute was used 624 in the Access-Request it MUST be included in the Authorize Only 625 Access-Request especially if the User-Name(1) attribute is used to 626 route the Access-Request to the Home AAA server. 628 The Authorize Only Access-Request MUST not include either User 629 Password or Chap Password. In order to authenticate the message, 630 the Access Device must include the Message-Authenticator(80) 631 attribute. The Access Device will compute the value for the 632 Message-Authenticator based on [RFC2869]. 634 When the HAAA receives the Authorize-Only Access-Request that 635 contains a PPAQ, it SHALL validate the message using the Message- 636 Authenticator(80) as per [RFC2869]. If the HAAA receives an 637 Authorize Only Access-Request that contains a PPAQ but not a 638 Message-Authenticator(80) it SHALL silently discard the message. An 639 Authorize Only Access-Request message that does not contain a PPAQ 640 is either in error or belongs to another application (for example, a 641 Change of Authorization message [CHIBA]). In this case the 642 Authorize Only Access-Request will either be silently discarded or 643 handled by another application (not in scope of this document). 645 Once the Authorize Only Access-Request message is validated, the 646 HAAA SHALL forward the Authorize Only Access-Request to the 647 appropriate PrePaid Server. The HAAA MUST forward the Authorize 648 Only Access-Request to the PrePaid server specified in the PPAQ. 649 The HAAA MUST sign the message using the Message-Authenticator(80) 650 and the procedures in [RFC2869]. As with the Access-Request 651 message, the HAAA MAY modify the User-Name(1) attribute to a value 652 that represents the userÆs internal PrePaid account in the PrePaid 653 server. Note the PrePaid server could use the Quota-ID sub- 654 attribute contained within the PPAQ to locate the user account. 656 Upon receiving the Authorize Only Access-Request containing a PPAQ 657 attribute, the PrePaid server MUST validate the Message- 658 Authenticator(80) as prescribed in [RFC2869]. If the message is 659 invalid, the PrePaid server MUST silently discard the message. If 660 it received an Authorize Only Access-Request message that does not 661 contain a PPAQ it MUST silently discard the message. 663 The PrePaid server will lookup the PrePaid session by using the 664 PrePaid Quota Id contained within the PPAQ. The PrePaid Server 665 would, take the last allocated quota and subtract that from the 666 UserÆs balance. If there is remaining balance, the PrePaid server 667 re-authorizes the PrePaid session by allocate an additional quota. 668 The PrePaid server may want to calculate a different threshold 669 values as well. 671 Upon successful re-authorization, the PrePaid server will generate 672 an Access-Accept containing the PPAQ attribute. The Access-Accept 673 message MAY contain Service-Type(6) set to Authorize-Only and MAY 674 contain the Message-Authenticator(80). 676 Depending on site policies, upon unsuccessful authorization, the 677 PrePaid server will generate an Access-Reject or an Access-Accept 678 with Filter-Id(11) or Ascend-Data-Filter (if supported) attribute 679 and the Session-Timeout(27) attribute such that the PrePaid 680 subscriber could get access to a restricted set of locations for a 681 short duration to allow them to replenish their account, or create 682 an account; or to browse free content. 684 Upon receiving the Access-Accept from the PrePaid server, the HAAA 685 SHALL return the packet to its client. If the HAAA, receives an 686 Access-Reject message, it will forward the packet. Depending on 687 site policies, if the HAAA fails to receive an Access-Accept or an 688 Access-Reject message from the PrePaid server it MAY do nothing or 689 it MAY send an Access-Reject message back to its client. 691 Upon receiving an Access-Accept, the Access Device SHALL update its 692 quotas and threshold parameters with the values contained in the 693 PPAQ attribute. Note that the PrePaid server MAY update the 694 PrePaidServer attribute(s) and these may have to be saved as well. 696 Upon receiving an Access-Accept message containing either Filter- 697 Id(11) or Ascend-Data-Filter attributes, and or Session Timeout(27). 698 The Access Device SHALL restrict the subscriber session accordingly. 700 4.5 Dynamic Operations 702 The PrePaid server may want to take advantage of the dynamic 703 capabilities that are supported by the Access Device as advertised 704 in the Dynamic-Capabilities attribute during the initial Access- 705 Request. 707 There are two types of actions that the PrePaid server can perform: 708 it can request that the session be terminated; or it can request 709 that the filters associated with the session be modified. 711 Both of these actions require that the session be uniquely 712 identified at the Access Device. As a minimum the PrePaid server: 714 -MUST provide either the NAS-IP-Address(4) or NAS-Identifier(32) 715 -MUST provide at least one session identifier such as User-Name(1), 716 Framed-IP-Address(), the Accounting-Session-Id(44). 718 Other attributes could be used to uniquely identify a PrePaid data 719 session. 721 4.5.1 Unsolicited Session Termination Operation 723 This capability is described in detail in [CHIBA]. The PrePaid 724 server send a Disconnect Request packet that MUST contain 725 identifiers that uniquely identify the subscriberÆs data session and 726 the Access Device holding that session. 728 Upon receiving the Disconnect Request packet the HAAA will either 729 act on it or will proxy it to another AAA server until it is 730 received by the a AAA that is in the same network as the serving 731 Access Device. 733 Each AAA MUST route the Disconnect Request packet. How the routing 734 decision is made is an implementation detail. 736 Once the Disconnect Request packet reaches AAA that is in the same 737 network as the serving Access Device, if the Access Device supports 738 Disconnect-Request (as per [CHIBA]), it sends the message directly 739 to the Access Device; otherwise it uses other mechanisms such as 740 SNMP or Telnet to command the Access Device to terminate the 741 session. 743 If the Access Device receives a Disconnect-Request packet, it will 744 respond with either a Disconnect-ACK packet if it was able to 745 terminate the session or else it will respond with a Disconnect-NAK 746 packet. 748 If the AAA server is performing the disconnect operation, it MUST 749 respond with a Disconnect-ACK message if it successfully terminated 750 the session or a Disconnect-NAK message if it failed to terminate 751 the session. 753 If any AAA server is unable to route the Disconnect-Request it MUST 754 respond with a Disconnect-NAK packet. 756 4.5.2 Unsolicited Change of Authorization Operation 758 The PrePaid Server MAY send a Change-of-Authorization message as 759 described in [CHIBA] to restrict internet access when the subscriber 760 has no more balance. 762 The PrePaid server sends a Change-of-Authorization packet it MUST 763 contain identifiers that will uniquely identify the subscriber 764 session and the Access Device serving that session. 766 Upon receiving the Change-of-Authorization packet the HAAA will 767 either act on it or proxy it to another AAA server until it is 768 received by a AAA server that is in the same network as the serving 769 Access Device. 771 Each AAA must route the packet to the serving network. How the 772 routing decision is made is an implementation detail. 774 Once the Change-of-Authorization packet reaches a AAA that is in the 775 same network as the serving Access Device, if the Access Device 776 supports Change-of-Authorization message, it will forward the 777 message to the Access Device; otherwise, it will use other 778 mechanisms such as SNMP or Telnet to command the Access Device to 779 change its filters. 781 If the Access Device receives a Change-of-Authorization packet, it 782 will respond with either a Change-of-Authorization-ACK packet if it 783 was able to change the filter or else it will respond with a Change- 784 of-Authorization-NAK packet. 786 If the AAA server is performing the change of filter operation, it 787 MUST respond with a Change-of-Authorization-ACK message if it 788 successfully or a Change-of-Authorization-NAK packet if it failed to 789 change the filter. 791 If a AAA server was unable to route the Change-of-Authorization it 792 MUST respond with a Change-of-Authorization-NAK packet. 794 4.6 Termination Operation 796 The termination phase is initiated when either: the Subscriber logs 797 off; the quotas have been consumed, or when the Access Device 798 receives a Disconnect Message. In all of these instances, if the 799 session is a PrePaid data session, the Access Device will send an 800 Authorize-Only Access-Request message with a PPAQ Update-Reason 801 attribute set to either ôClient Service terminationö or ôRemote 802 Forced disconnectö and the currently used quota. 804 The BAAA MUST forward this packet to the next BAAA or the HAAA. 806 The HAAA MUST validate the Authorize Only Access-Request using the 807 Message-Authenticator(80) as per [RFC2869] and if valid, use the 808 PrePaidServer subtype in the PPAQ to forward the Authorize Only 809 Access-Request packet to the serving PrePaid Server or if needed, 810 its alternate. 812 The PrePaid Server MUST validate the Authorize Only Access Request 813 and use the information contained in the PPAQ attribute to adjust 814 the subscriberÆs balance and to close the session. The PrePaid 815 Server SHALL respond back with an Access-Accept message. 817 4.7 Mobile IP Operations 819 In roaming scenarios using mobile-ip, as the mobile subscriber roams 820 between networks, or between different types of networks such as 821 between WLAN and CDMA2000 networks, the PrePaid data session is 822 maintained transparently. 824 As the subscriber device associates with the new Access Device, the 825 Access Device sends a RADIUS Access-Request and the subscriber is 826 re-authenticated and reauthorized. If the Access Device has PrePaid 827 Client capabilities, it MUST include the PPCC attribute in the 828 RADIUS Access-Request. In this manner the procedure follows the 829 Authentication and Authorization procedure described earlier. 831 The Access-Request message is routed to the home network and MUST 832 reach the PrePaid System that is serving the PrePaid session. The 833 PrePaid system will then correlate the new authorization request 834 with the existing active session and will assign a quota to the new 835 request. Any outstanding quota at the old Access Device will be 836 returned to the PrePaid system due to the usual mobile-ip handoff 837 procedures. Specifically, the quota will be returned when the 838 Access Device sends the Authorize Only Access-Request with PPAQ 839 Update-Reason subtype set to either ôRemote Forced disconnectö or 840 ôClient Service terminationö. In order to trigger the sending of 841 this last Authorize Only Access-Request, the PrePaid system may 842 issue a Disconnect Message [CHIBA] to the Access Device. 844 If the subscriber has roamed to an Access Device that does not have 845 any PrePaid Capabilities, PrePaid data service may still be possible 846 by requesting the Home Agent (providing it has PrePaid Capabilities) 847 to assume responsibilities for metering the service. The procedure 848 for this scenario will be given in the next release of this draft. 850 4.8 Accounting Considerations 852 Accounting messages are not required to deliver PrePaid Data 853 Service. Accounting message will typically be generated for PrePaid 854 Data Service. This because accounting message are used for auditing 855 purposes as well as for bill generation. 857 Accounting messages associated with PrePaid Data Sessions should 858 include the PPAQ attribute. 860 4.9 Interoperability with Diameter 862 RADIUS PrePaid solutions need to interoperate with Diameter 863 protocol. Two possibilities exist: The AAA infrastructure is 864 Diameter based and the Access Device are RADIUS based; or the Access 865 Device is Diameter based and the AAA infrastructure is RADIUS based. 867 The Diameter Credit Control Application [DIAMETERCC] describes how 868 to implement a PrePaid using an all Diameter based infrastructure. 870 872 5. Attributes 874 As currently written, this draft is using the RADIUS [RFC2865] 875 namespace. 877 Subsequent version will probably be written to use VSAs. However, 878 the Vendor Identifier that would be proposed would be PrePaid 879 Application. 881 Note: as currently written, this draft proposes to use container 882 types, or attributes that contain sub-attributes, that will have 883 attributes from the PrePaid space and also attributes belonging to 884 RADIUS space. The technique for encoding such a structure will be 885 identified in future release of this document. 887 Note: The attributes presented in this version of the draft, 888 represent the bare minimum attributes required to implement a 889 PrePaid solution. The use of the ôAuthorize Onlyö Pattern allows 890 the ability to extend PrePaid by adding additional PrePaid VSA in 891 the future. 893 5.1 PPCC attribute 894 The PPCC at tribute is sent in the Access-Request message and is 895 used to describe the Access Devices PrePaid capabilities. The 896 attribute is encrypted using the procedures defined in [RFC2868 ] 897 section 3.5. 899 0 1 2 3 900 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | VALUE (Event-Timestamp) | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | SUB-TYPE 2 | LENGTH | VALUE (PP-capabilities) | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 TYPE: value of PPCC 912 LENGTH: 14 914 SUB-TYPE 1: 55 915 LENGTH: 6 916 DESCRIPTION: 917 The Event-Timestamp as defined by [RFC2869] 919 SUB-TYPE 2: value of PP-capabilities 920 LENGTH: 4 921 DESCRIPTION: 922 BIT-MAP with the following values: 923 1 Time metering 924 2 Volume metering 925 >2 Reserved 927 5.2 Dynamic-Capabilities attribute 929 The Dynamic Capabilities attribute is sent in the Access-Request and 930 describes the capabilities of the Access Device. Mainly it 931 describes the method for support for unsolicited session termination 932 and the method for support of unsolicited change of filters. 934 Subtype: Session-Termination-Methods 1 935 -None 936 -Disconnect-Message [CHIBA] 937 -Telnet 938 -SNMP 940 Subtype: Dynamic-Authorization-Capabilities 1 941 -None 942 -CoA [CHIBA] 943 -Telenet 944 -SNMP 946 5.3 PPAQ Attribute 948 The PPAQ attribute is sent in Authorize Only Access-Request and 949 Access-Accept messages. In Authorize Only Access-Request messages 950 it is used to report usage and request further quota; in an Access- 951 Accept message it is used to allocate the quota (initial quota and 952 subsequent quotas). 954 The attribute consists of a number of subtypes. Subtypes not used 955 are omitted in the message. 957 Type: 26 958 Length: variable, greater than 8 959 Vendor-ID: 5535 960 Vendor-Type: 90 961 Vendor-Length: variable, greater than 2 963 Sub-Type (=1): Sub-Type for QuotaIDentifier attribute 964 Length: length of QuotaIDentifier attribute (= 6 octets) 965 QuotaIDentifier (QID): 967 The QuotaIDentifier Sub-Type is generated by the PrePaid server 968 at allocation of a Volume and/or Duration Quota. The on-line 969 quota update RADIUS Access-Request message sent from the Access 970 Device to the PPS shall include a previously received 971 QuotaIDentifier. 973 Sub-Type (=2): Sub-Type for VolumeQuota attribute 974 Length: length of VolumeQuota attribute (= 6 octets) 975 VolumeQuota (VQ): 977 The optional VolumeQuota Sub-Type is only present if Volume Based 978 charging is used. In RADIUS Access-Accept message (PPS to Access 979 Device direction), it indicates the Volume (in octets) allocated 980 for the session by the PrePaid server. In RADIUS Authorize Only 981 Access-Request message (Access Device to PPS direction), it 982 indicates the total used volume (in octets) for both forward and 983 reverse traffic applicable to PrePaid accounting. 985 Sub-Type (=3): Sub-Type for VolumeQuotaOverflow 986 Length: length of VolumeQuotaOverflow attribute (= 4 octets) 987 VolumeQuotaOverflow (VQO): 989 The optional VolumeQuotaOverflow Sub-Type is used to indicate how 990 many times the VolumeQuota counter has wrapped around 2^32 over 991 the course of the service being provided. 993 Sub-Type (=4): Sub-Type for VolumeThreshold attribute 994 Length: length of VolumeThreshold attribute (= 6 octets) 995 VolumeThreshold (VT): 997 The VolumeThreshold Sub-Type shall always be present if 998 VolumeQuota is present in a RADIUS Access-Accept message (PPS to 999 Access Device direction). It is generated by the PrePaid server 1000 and indicates the volume (in octets) that shall be used before 1001 requesting quota update. This threshold should not be larger than 1002 the VolumeQuota. 1004 Sub-Type (=5): Sub-Type for VolumeThresholdOverflow 1005 Length: length of VolumeThresholdOverflow attribute (= 4 octets) 1006 VolumeThresholdOverflow (VTO): 1008 The optional VolumeThresholdOverflow Sub-Type is used to indicate 1009 how many times the VolumeThreshold counter has wrapped around 1010 2^32 over the course of the service being provided. 1012 Sub-Type (=6): Sub-Type for DurationQuota attribute 1013 Length: length of DurationQuota attribute (= 6 octets) 1014 DurationQuota (DQ): 1016 The optional DurationQuota Sub-Type is only present if Duration 1017 Based charging is used. In RADIUS Access-Accept message (PPS to 1018 Access Device direction), it indicates the Duration (in seconds) 1019 allocated for the session by the PrePaid server. In on-line 1020 RADIUS Access-Accept message (PPC to PPS direction), it indicates 1021 the total Duration (in seconds) since the start of the accounting 1022 session related to the QuotaID. 1024 Sub-Type (=7): Sub-Type for DurationThreshold attribute 1025 Length: length of DurationThreshold attribute (= 6 octets) 1026 DurationThreshold (DT): 1028 The DurationThreshold Sub-Type shall always be present if 1029 DurationQuota is present in a RADIUS Access-Accept message (PPS 1030 to Access Device direction). It represents the duration (in 1031 seconds) that shall be used by the session before requesting 1032 quota update. This threshold should not be larger than the 1033 DurationQuota and shall always be sent with the DurationQuota. 1035 Sub-Type (=8): Sub-Type for Update-Reason attribute 1036 Length: length of Update-Reason attribute (= 4 octets) 1037 Update-Reason attribute (UR): 1039 The Update-Reason Sub-Type shall be present in the on-line RADIUS 1040 Access-Request message (Access Device to PPS direction). It 1041 indicates the reason for initiating the on-line quota update 1042 operation. Update reasons 4, 5, 6, 7 and 8 indicate that the 1043 associated resources are released at the client side, and 1044 therefore the PPS shall not allocate a new quota in the RADIUS 1045 Access_Accept message. 1047 1. Pre-initialization 1048 2. Initial request 1049 3. Threshold reached 1050 4. Quota reached 1051 5. Remote Forced disconnect 1052 6. Client Service termination 1053 7. Main SI released 1054 8. Service Instance not established 1056 Sub-Type (=9): Sub-Type for PrePaidServer attribute 1057 Length: Length of PrePaidServer (IPv4 = 6 octets, IPv6= 18 octets 1058 PrePaidServer: 1060 The optional, multi-value PrePaidServer indicates the address of 1061 the serving PrePaid System. If present, the Home RADIUS server 1062 uses this address to route the message to the serving PrePaid 1063 Server. The attribute may be sent by the Home RADIUS server. If 1064 present in the incoming RADIUS Access-Accept message, the PDSN 1065 shall send this attribute back without modifying it in the 1066 subsequent RADIUS Access-Request message, except for the first 1067 one. If multiple values are present, the PDSN shall not change 1068 the order of the attributes. 1070 NOTES: 1072 Either Volume-Quota or Time-Quota MUST appear in the attribute. 1073 Volume Threshold may only appear if Volume Quota appears 1074 If the Access Device can measure time, and if Time-Threshold appears 1075 with Volume Quota, then the Access device should trigger a quota 1076 replenishment when the Current Time >= Time-Threshold. 1078 5.4 Table of Attributes 1080 TO BE COMPLETED. 1082 Request Accept Reject Challenge # Attribute 1084 Authorize_Only Request Accept Reject 1086 6. Security Considerations 1088 The protocol exchanges described are susceptible to the same 1089 vulnerabilities as RADIUS and it is recommended that IPsec be 1090 employed to afford better security. 1092 If IPsec is not available the protocol in this draft improves the 1093 security of RADIUS. The various security enhancements are explained 1094 in the following sections. 1096 6.1 Authentication and Authorization 1098 RADIUS is susceptible to replay attacks during the Authentication 1099 and Authorization procedures. A successful replay of the initial 1100 Access-Request could result in an allocation of an initial quota. 1102 To thwart such an attack... 1104 6.2 Replenishing Procedure 1106 A successful replay attacks of the Authorize Only Access-Request 1107 could deplete the subscribers prepaid account. 1109 To be completed. 1111 7. IANA Considerations 1113 To be completed. 1115 This draft does create RADIUS attributes. However, the authors 1116 recognize that it may not be possible to obtain such attributes. 1117 Therefore, in subsequent drafts it will be proposed to use a Vendor 1118 space as an Application Space. 1120 8. Normative References 1122 [RFC2026] Bradner, S., "The Internet Standards Process -- 1123 Revision 3", RFC 2026, October 1996. 1124 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1125 Requirement Levels", RFC 2119, March 1997. 1126 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, 1127 "Remote Authentication Dial In User Server 1128 (RADIUS)", RFC 2865, June 2000. 1130 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 1131 2000. 1133 [RFC2869] Rigney, C., Willats, W., Calhoun, P., "RADIUS 1134 Extensions", RFC 2869, June 2000. 1136 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., 1137 Holdrege, M., Goyret, I., "RADIUS Attributes for 1138 Tunnel Protocol Support" , RFC 2868, June 2000. 1139 [CHIBA] Chiba, M., Dommety, G., Eklund, M., Mitton, D., 1140 Aboba, B., "Dynamic Authorization Extensions to 1141 Remote Authentication Dial-In User Service 1142 (RADIUS)", Internet Draft (work in progress), draft- 1143 chiba-radius-dynamic-authorization-07.txt, February 1144 2003. 1146 [DIAMETERCC] Work in Progress. 1148 Acknowledgments 1150 Author's Addresses 1152 Avi Lior Parviz Yegani, Ph.D. 1153 Bridgewater Systems Mobile Wireless Group 1154 303 Terry Fox Drive Cisco Systems 1155 Suite 100 3625 Cisco Way 1156 Ottawa Ontario San Jose, CA 95134 1157 Canada USA 1158 avi@bridgewatersystems.com pyegani@cisco.com 1160 Kuntal Chowdhury Lila Madour 1161 Nortel Networks Ericsson Canada 1162 2221, Lakeside Blvd, 5400 Decarie, TMR 1163 Richardson, TX-75082 Quebec, Canada 1164 chowdury@nortelnetworks.com Lila.madour@ericsson.ca 1166 Yong Li 1167 Bridgewater Systems 1168 303 Terry Fox Drive 1169 Suite 100 1170 Ottawa Ontario 1171 Canada 1172 Yong.li@bridgewatersystems.com 1174 Intellectual Property Statement 1176 The IETF takes no position regarding the validity or scope of any 1177 intellectual property or other rights that might be claimed to 1178 pertain to the implementation or use of the technology described in 1179 this document or the extent to which any license under such rights 1180 might or might not be available; neither does it represent that it 1181 has made any effort to identify any such rights. Information on the 1182 IETF's procedures with respect to rights in standards-track and 1183 standards-related documentation can be found in BCP-11. Copies of 1184 claims of rights made available for publication and any assurances 1185 of licenses to be made available, or the result of an attempt made 1186 to obtain a general license or permission for the use of such 1187 proprietary rights by implementers or users of this specification 1188 can be obtained from the IETF Secretariat. 1190 The IETF invites any interested party to bring to its attention any 1191 copyrights, patents or patent applications, or other proprietary 1192 rights which may cover technology that may be required to practice 1193 this standard. Please address the information to the IETF Executive 1194 Director. 1196 Full Copyright Statement 1198 Copyright (C) The Internet Society (2003). All Rights Reserved. 1199 This document and translations of it may be copied and furnished to 1200 others, and derivative works that comment on or otherwise explain it 1201 or assist in its implementation may be prepared, copied, published 1202 and distributed, in whole or in part, without restriction of any 1203 kind, provided that the above copyright notice and this paragraph 1204 are included on all such copies and derivative works. However, this 1205 document itself may not be modified in any way, such as by removing 1206 the copyright notice or references to the Internet Society or other 1207 Internet organizations, except as needed for the purpose of 1208 developing Internet standards in which case the procedures for 1209 copyrights defined in the Internet Standards process must be 1210 followed, or as required to translate it into languages other than 1211 English. The limited permissions granted above are perpetual and 1212 will not be revoked by the Internet Society or its successors or 1213 assigns. This document and the information contained herein is 1214 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1215 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1216 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1217 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1218 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1220 Expiration Date 1222 This memo is filed as , and will expire 30th December, 2003.