idnits 2.17.00 (12 Aug 2021) /tmp/idnits63474/draft-tschofenig-geopriv-radius-lo-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1258. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1235. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1242. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1248. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1264), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (July 12, 2004) is 6515 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) == Unused Reference: 'I-D.adrangi-radius-bandwidth-capability' is defined on line 1107, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-geopriv-common-rules' is defined on line 1124, but no explicit reference was found in the text == Outdated reference: draft-ietf-geopriv-dhcp-civil has been published as RFC 4676 == Outdated reference: draft-ietf-geopriv-dhcp-lci-option has been published as RFC 3825 ** Downref: Normative reference to an Informational RFC: RFC 2866 ** Obsolete normative reference: RFC 3576 (Obsoleted by RFC 5176) == Outdated reference: A later version (-01) exists of draft-adrangi-radius-bandwidth-capability-00 == Outdated reference: draft-arkko-pppext-eap-aka has been published as RFC 4187 == Outdated reference: A later version (-02) exists of draft-arkko-roamops-rfc2486bis-00 -- No information found for draft-ietf-common-rules - is the name correct? == Outdated reference: draft-ietf-geopriv-reqs has been published as RFC 3693 -- No information found for draft-ietf-common-rules - is the name correct? -- Duplicate reference: draft-ietf-common-rules, mentioned in 'I-D.ietf-geopriv-rules', was also mentioned in 'I-D.ietf-geopriv-common-rules'. == Outdated reference: draft-ietf-geopriv-threat-analysis has been published as RFC 3694 == Outdated reference: draft-ietf-ipsec-ikev2 has been published as RFC 4306 == Outdated reference: draft-ietf-kink-kink has been published as RFC 4430 == Outdated reference: draft-ietf-simple-rpid has been published as RFC 4480 == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-07 == Outdated reference: draft-tschofenig-eap-ikev2 has been published as RFC 5106 -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) Summary: 8 errors (**), 0 flaws (~~), 16 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Geopriv H. Tschofenig 2 Internet-Draft Siemens 3 Expires: January 10, 2005 F. Adrangi 4 Intel 5 A. Lior 6 M. Jones 7 Bridgewater 8 July 12, 2004 10 Carrying Location Objects in RADIUS 11 draft-tschofenig-geopriv-radius-lo-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 10, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 This document describes RADIUS attributes for conveying the Access 45 Network's operational ownership and location information based on a 46 civil and geospatial location location format. 48 The distribution of location information is privacy sensitive. 50 Dealing with mechanisms to preserve the user's privacy is important 51 and addressed in this document. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Delivery Methods for Location Information . . . . . . . . . . 5 58 3.1 Authentication/Authorization Phase Delivery . . . . . . . 5 59 3.2 Mid-session Delivery . . . . . . . . . . . . . . . . . . . 6 60 4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 4.1 Use Case 1 - Use of Location Information in AAA . . . . . 8 62 4.2 Scenario 2 - Use of Location Information for other 63 Services . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 5.1 Operator-Name Attribute . . . . . . . . . . . . . . . . . 10 66 5.2 Location-Information Attribute . . . . . . . . . . . . . . 10 67 5.2.1 Civil Location Information . . . . . . . . . . . . . . 11 68 5.2.2 Geospatial Location Information . . . . . . . . . . . 12 69 6. Policy-Information Attribute . . . . . . . . . . . . . . . . . 14 70 7. Location-Type Attribute . . . . . . . . . . . . . . . . . . . 15 71 8. Billing-Description Attribute . . . . . . . . . . . . . . . . 16 72 9. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 9.1 Operator-Name Attribute . . . . . . . . . . . . . . . . . 17 74 9.2 Location-Information Attribute . . . . . . . . . . . . . . 17 75 9.3 Policy-Information Attribute . . . . . . . . . . . . . . . 20 76 9.4 Location-Type Attribute . . . . . . . . . . . . . . . . . 21 77 9.5 Billing-Description Attribute . . . . . . . . . . . . . . 21 78 10. Table of Attributes . . . . . . . . . . . . . . . . . . . . 23 79 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 80 12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 25 81 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 82 14. Security Considerations . . . . . . . . . . . . . . . . . . 30 83 15. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 32 84 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 33 85 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 86 17.1 Normative References . . . . . . . . . . . . . . . . . . . . 34 87 17.2 Informative References . . . . . . . . . . . . . . . . . . . 34 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 36 89 Intellectual Property and Copyright Statements . . . . . . . . 38 91 1. Introduction 93 Wireless LAN (WLAN) Access Networks (AN) are being deployed in public 94 places such as airports, hotels, shopping malls, and coffee shops by 95 a diverse set of incumbent operators such as cellular carriers (GSM 96 and CDMA), Wireless Internet Service Providers (WISP), and fixed 97 broadband operators. 99 When an end host authenticates itself to such a network, information 100 about the location and operational ownership of this network needs to 101 be conveyed to the users's home network to which the user has a 102 contractal relationship. The main intent of this document is to 103 enable location aware billing (e.g., determine the appropriate tariff 104 and taxation), location aware subscriber authentication and 105 authorization for roaming environments and to enable location aware 106 services. 108 This document describes AAA attributes that are used by a AAA client 109 or a local AAA server in an access network for conveying 110 location-related information to the user's home AAA server. This 111 document defines attributes for RADIUS [RFC2865]. 113 Although the proposed attributes in this draft are intended for 114 wireless LAN deployments, they can also be used in other wireless and 115 wired networks where location-aware services are required. 117 Location information needs to be protected against unauthorized 118 access and distribution to preserve privacy of the owner of the 119 location information. With [I-D.ietf-geopriv-reqs] requirements for 120 a protocol-independent model for the access to geographic location 121 information was defined. The model includes a Location Generator 122 (LG) that creates Location Information, a Location Server (LS) that 123 authorizes access to Location Information, a Location Recipient (LR) 124 that requests and receives information, and a Rule Maker (RM) that 125 provides authorization policies to the LS which enforce access 126 control policies on access to a target. 128 2. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 RADIUS specific terminology is reused from [RFC2865] and [RFC2866]. 136 Terminology related to privacy issues, location information and 137 authorization policy rules are taken from [I-D.ietf-geopriv-reqs]. 139 3. Delivery Methods for Location Information 141 Location Infomation Objects defined in this document are transported 142 over RADIUS protocol from visited access network to the AAA server. 143 The information can be delivered to the RADIUS server during the 144 authentication/authorization phase described in Section 3.1, or in 145 the mid-session using the dynamic authorization protocol framework 146 described in Section 3.2. This section describes message flow for 147 both delivery methods. 149 3.1 Authentication/Authorization Phase Delivery 151 Figure 1 shows an example message flow for delivering Location 152 Information during the network access authentication/authorization 153 procedure. Upon a network authentication request from an access 154 network client, the NAS submits a RADIUS Access-Request message which 155 contains location information attributes among other required 156 attributes. The authentication and/or authorization procedure is 157 completed based on a number of criteria, including the newly defined 158 Location-Information, Operator-Name, Location-Type, 159 Policy-Information attributes. A RADIUS Accounting Request message 160 is again allowed to carry location specific attributes. 162 +---------+ +---------+ +---------+ 163 | Access | | Network | | AAA | 164 | Network | | Access | | Server | 165 | Client | | Server | | | 166 +---------+ +---------+ +---------+ 167 | | | 168 | Authentication phase | | 169 | begin | | 170 |---------------------->| | 171 | | | 172 | | | 173 | | RADIUS | 174 | | Access-Request | 175 | | + Location-Information | 176 | | attributes | 177 | |----------------------------->| 178 | | | 179 : : : 180 : Multiple Protocol Exchanges to perform : 181 : Authentication, Key Exchange and Authorization : 182 : : : 183 : ...continued... : 184 : | | 185 | | RADIUS | 186 | | Access-Accept | 187 | | + Rule set Information | 188 | |<-----------------------------| 189 | Authentication | | 190 | Accept | | 191 |<----------------------| | 192 | | | 193 | | RADIUS | 194 | | Accounting Request | 195 | | + Location-Information | 196 | | attributes | 197 | |----------------------------->| 198 | | | 200 Figure 1: Message Flow: Authentication/Authorization Phase Delivery 202 3.2 Mid-session Delivery 204 Mid-session delivery method uses the Change of Authorization (COA) 205 message as defined in [RFC3576]. In accordance to [RFC3576], at 206 anytime during the session the AAA server may send the access network 207 a COA message containing session identification attributes (see 208 [RFC3576] for the possible options). The COA message may instruct 209 the access network to generate an Authorize-Only Access-Request 210 (Access-Request with Service-Type set to "Authorize-Only") in which 211 case it is instructing the access network to send the location 212 information attributes. 214 Figure 2 shows the approach graphically. 216 Access network AAA server 217 | | 218 | COA + Service-Type "Authorize Only" | 219 |<----------------------------------------------| 220 | | 221 | COA NAK + Service-Type "Authorize Only" | 222 | + Error-Cause "Request Initiated" | 223 |---------------------------------------------->| 224 | | 225 | Access-Request + Service-Type "Authorize Only"| 226 | + Location Information attributes | 227 | + Location Information policy | 228 |---------------------------------------------->| 229 | | 230 | Access-Accept | 231 |<----------------------------------------------| 232 | | 234 Figure 2: Message Flow: Mid-session Delivery 236 Upon receiving the Authorize-Only message from the Access network, 237 the AAA server MUST respond with either an Access-Accept message or 238 an Access-Reject message. 240 4. Scenarios 242 In the following subsections we describe two scenarios for use of 243 location information. The location infomration may refer to network 244 or user location information which in some cases may be identical. 245 How the network obtains the user's location information is out of 246 scope of this document. There are two consumers of the location 247 information: the AAA servers and other location-based services. The 248 privacy implications of these scenarios are described in Section 13. 250 4.1 Use Case 1 - Use of Location Information in AAA 252 An Operator requires Location Informaion for Authorization and 253 Billing purposes. The operator may deny service if Location 254 Information is not available. Or it may offer limited service. The 255 NAS delivers Location Information to the Home AAA server. 257 The user's location is transferred from the NAS to the RADIUS server 258 and the NAS and intermediaries (if any) are not allowed to use that 259 information other then to forward it to the home network. 261 The RADIUS server authenticates and authroizes the session. If the 262 user's location policies are available to the RADIUS server, the 263 RADIUS server may deliver those policies in an Access Accept. This 264 information may be needed if intermediaries or other elements want to 265 act as Location Servers (see Section 4.2). In the absence of 266 receiving the policies intermediaries MUST NOT divulge the location 267 information. 269 Location Information may also be reported in accouning messages. 270 Accounting messages are generated when the session starts, stops and 271 periodically. Accounting messages may also be generated when the 272 user roams during handoff. This information may be needed by the 273 billing system to calculate the users bill. For example, there may 274 be different tarrif rates applied based on the location and their 275 maybe different tax rates applied based on the location. Unless 276 otherwise specified, location information in the accounting stream 277 may not be transmitted to third parties. 279 The location information in the accounting stream MUST only be sent 280 in the proxy chain to the home network (unless specified otherwise). 282 4.2 Scenario 2 - Use of Location Information for other Services 284 Location Servers are entities that receive the user's location 285 information and transmit it to other entities. For the purpose of 286 this scenario Location servers are the NAS, and RADIUS servers. The 287 RADIUS servers are in the home network, in the visited network, or in 288 broker networks. 290 Unless otherwise specified, excluding the proxy chain from the NAS to 291 the Home RADIUS, the Location Server may not transmit the location 292 information to other parties. 294 Upon authentication and authorization, the Home RADIUS may transmit 295 the Rule set in an Access-Accept to the other Location Server 296 allowing them to transmit location information. Then and only then 297 they are allowed to share the information. 299 Note since the NAS is the source of all Location information that is 300 disimenated by RADIUS, the NAS could tag the location information 301 with the location rules or a reference for the location rules 302 received in an Access-Accept. All location information in the 303 Accounting Stream will now be tagged. 305 5. Overview 307 The location information and operational ownership of the access 308 network is conveyed in five AAA attributes which are: Operator-Name, 309 Location-Information, Location-Type , Policy-Information and 310 Billing-Description. Furthermore, basic authorization policy rules 311 are attached to the Location-Information attribute turning Location 312 Information into a Location Object as defined in 313 [I-D.ietf-geopriv-reqs]. 315 5.1 Operator-Name Attribute 317 This attribute contains an operator name which uniquely identifies 318 the ownership of an access network. The Attribute value is a 319 non-NULL terminated string whose Length MUST NOT exceed 253 bytes. 320 The attribute value is comprised of the prefix and the identity, 321 separated by a colon. The prefix identifies the operator type; 322 example: GSM, CDMA, and REALM. The identity uniquely identifies the 323 operator name within the scope of the operator type. 325 As an example consider the string 'GSM:TADIG' where GSM is a prefix 326 indicating an operator type and TADIC is a unique globally known GSM 327 operator ID. 329 This document defines three operator type prefixes which are: GSM, 330 CDMA, and REALM. The GSM prefix can be used to indicate operator 331 names based on GSMA TADIG codes. REALM can be used by any domain 332 name acquired from IANA. Possible forthcoming operator types MUST be 333 associated with an ogranization responsible for assigning/managing 334 operator names. 336 5.2 Location-Information Attribute 338 This document describes two formats for conveying location 339 information: civil and geospatial location information. Section 340 5.2.1 defines the civil location information format. Section 5.2.2 341 defines the geospatial location information format. 343 Additionally, the Precision field provides further information about 344 the location information provided via Radius. For large networks 345 information about the location of the user can be provided in 346 different degrees of accuracy. This field gives a hint. Ideally the 347 location of the user is returned to the home network but in some 348 cases it might not be available. It has to be noted that the user 349 does not provide the location information itself. 351 5.2.1 Civil Location Information 353 Civil location is a popular way to describe the location of an 354 entity. Using an unstructured (as a text string) or a custom format 355 for civil location format is dangerous since the automatic processing 356 capabilities are limited. 358 For this document we reuse the civil location format defined in 359 [I-D.ietf-geopriv-dhcp-civil]. 361 The civil location format includes a number of fields, including the 362 country (expressed as a two-letter ISO 3166 code) and the 363 administrative units of [I-D.ietf-geopriv-dhcp-civil] A1 through A6. 364 This designation offers street-level precision. 366 For completeness we include more detailed information from 367 [I-D.ietf-geopriv-dhcp-civil] with regard to the defined civil 368 location elements (A1 through A6): 370 +----------------------+----------------------+---------------------+ 371 | Label | Description | Example | 372 +----------------------+----------------------+---------------------+ 373 | country | The country is | US | 374 | | identified by the | | 375 | | two-letter ISO 3166 | | 376 | | code. | | 377 | | | | 378 | A1 | national | New York | 379 | | subdivisions (state, | | 380 | | region, province, | | 381 | | prefecture) | | 382 | | | | 383 | A2 | county, parish, gun | King's County | 384 | | (JP), district (IN) | | 385 | | | | 386 | A3 | city, township, shi | New York | 387 | | (JP) | | 388 | | | | 389 | A4 | city division, | Manhattan | 390 | | borough, city | | 391 | | district, ward, chou | | 392 | | (JP) | | 393 | | | | 394 | A5 | neighborhood, block | Morningside Heights | 395 | | | | 396 | A6 | street | Broadway | 397 | | | | 398 | PRD | Leading street | N, W | 399 | | direction | | 400 | | | | 401 | POD | Trailing street | SW | 402 | | suffix | | 403 | | | | 404 | STS | Street suffix | Avenue, Platz, | 405 | | | Street | 406 | | | | 407 | HNO | House number, | 123 | 408 | | numeric part only. | | 409 | | | | 410 | HNS | House number suffix | A, 1/2 | 411 | | | | 412 | LMK | Landmark or vanity | Low Library | 413 | | address | | 414 | | | | 415 | LOC | Additional location | Room 543 | 416 | | information | | 417 | | | | 418 | FLR | Floor | 5 | 419 | | | | 420 | NAM | Name (residence, | Joe's Barbershop | 421 | | business or office | | 422 | | occupant) | | 423 | | | | 424 | PC | Postal code | 10027-0401 | 425 +----------------------+----------------------+---------------------+ 427 Table 1 429 Additional CA types are defined in Section 3.4 of 430 [I-D.ietf-geopriv-dhcp-civil]. These types are useful to express 431 further information about the location, language specific settings 432 via the 'language' item and encoding information via the 'script' 433 item. Section 12 shows usage examples of this attribute. 435 All attributes are optional and can appear in any order. The values 436 are encoded using UTF-8 [RFC3629]. 438 5.2.2 Geospatial Location Information 440 This document reusing geospatial location information from 441 [I-D.ietf-geopriv-dhcp-lci-option] which defines latitude, longitude, 442 and altitude, with resolution indicators for each. The value in the 443 Altitude field either indicates meters or floors (via the Altitude 444 Type field). As a coordinate reference system Section 2.1 of 445 [I-D.ietf-geopriv-dhcp-lci-option] defines (via extensible mechanism 446 using IANA registration) three values in the Datum field: WGS 84, NAD 447 83 (with the associated vertical datum for the North American 448 Vertical Datum of 1988), NAD 83 (with the associated vertical datum 449 for the Mean Lower Low Water (MLLW). WGS 84 is used by the GPS 450 system. 452 During a protocol run it is possible to return Location-Information 453 attributes which provide both location information elements. If only 454 one location information element is provided then civil location MUST 455 be included in the request. Additionally, geospatial location MAY be 456 provided. 458 6. Policy-Information Attribute 460 In some environments it is possible for the user to attach 461 information about its privacy preferences. These preferences allow 462 the visited network, intermediate RADIUS proxies and the home network 463 to authorize the distribution of the user's location information. 465 Without the user providing authorization information two approaches 466 are possible: 468 o The user hides its location information from the access network 469 and from intermediate networks using the appropriate network 470 access authentication mechanism. Section 13 discusses these 471 issues in more details. 472 o The access network attaches default authorization policies which 473 prevents intermediate networks and the home network to distribute 474 the location information to other entities. Additionally, the 475 home network might have authorization policies which control 476 distribution of location information. Users can dynamically 477 change their policies using the authroization framework defined in 478 [I-D.ietf-geopriv-rules] and [I-D.ietf-geopriv-rules]. 480 With regard to authorization policies this document reuses work done 481 in [I-D.peterson-geopriv-pidf-lo] and encodes it in an non-XML 482 format. 484 7. Location-Type Attribute 486 This document defines a separate attribute for the type of the 487 location. Instead of the values of the 'type-of-place' attribute 488 defined in Section 4.6 of [I-D.ietf-simple-rpid] which is reused by 489 [I-D.ietf-geopriv-dhcp-civil] we define our own list of values for 490 the Location-Type attribute. The reason for this is given by the 491 size constraints of the attribute, dependence to other documents and 492 to the location names required for the RADIUS context. Consequently, 493 CA type '25' which equals the placetype is not used in the 494 Location-Information attribute as described in Section 5.2. 496 0 Reserved 497 1 Coffee Shop 498 2 Hotel 499 3 Airport 500 4 Mall 501 5 Restaurant 502 6 Bus 503 7 Library 504 8 Convention Center 505 9 School 506 10 Office 507 11 Airplane 508 12 Train 509 13 Ship 510 14 Educational Institute 511 15 Public Place 512 16 Other 514 Using these attribute types it is possible to describe the area in 515 more detail. 517 8. Billing-Description Attribute 519 The Billing-Description Attribute contains unstructured text to be 520 printed on the users bill. 522 9. Attributes 524 This section defines attributes for access network operational 525 ownership, Location Name, Location Information and Billing 526 Description. 528 9.1 Operator-Name Attribute 530 Operator-Name Attribute SHOULD be sent in Access-Request, and 531 Accounting-Request records where the Acc-Status-Type is set to Start, 532 Interim, or Stop. 534 A summary of the Operator-Name Attribute is shown below. 536 0 1 2 3 537 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 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Type | Length | Operator-Name ... 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 Type: 543 To Be Assigned by IANA - Operator-Name 545 Length: 546 >= 3 548 Operator-Name: 549 The text field contains an Access Network Operator Name in 550 prefix-based format as describe above. 551 Example: REALM:anyisp.com 553 9.2 Location-Information Attribute 555 Location-Information attribute SHOULD be sent in Access-Request, and 556 Accounting-Request records where the Acc-Status-Type is set to Start, 557 Interim or Stop if available. 559 The Location-Information Attribute has two variations depending on 560 civil or geospatial location information. The format is shown below. 562 0 1 2 3 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Type | Length | Code | Precision | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Location-Info ... 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 Type (8 bits): 571 To Be Assigned by IANA - Location-Information 573 Length (8 bits): 574 >= 3 576 Code (8 bits): 577 Describes which location format is carried in this attribute: 578 (0) describes civil location information 579 (1) describes geospatial location information 580 All other bites of the Code field is reserved 581 and required for alignment. 583 Precision (8 bits): 584 Describes which location this attribute refers to: 585 (0) describes the location of the NAS 586 (1) describes the location of the AAA server 587 (2) describes the location of the end host (user) 588 (3) describes the location of the network 590 Location-Info (variable): 591 Contains either civil or 592 geospatial location information attributes. 594 For civil location information the Location-Info field in the above 595 structure is defined as followed: 597 0 1 2 3 598 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 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Countrycode | Civic address elements ... 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 Countrycode (16 bits): 604 Two-letter ISO 3166 country code in capital ASCII leters. 606 Civic address elements (variable): 607 The text field contains location information element. 609 The format of the civic address elements is described in Section 3.3 610 of [I-D.ietf-geopriv-dhcp-civil] with a TLV pair (whereby the Type 611 and Length fields are one-octed long). An example is given in 612 Section 12. 614 For geospatial location information the Location-Info field is 615 defined as follows: 617 0 1 2 3 618 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 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | LaRes | Latitude + 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Latitude | LoRes | Longitude + 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Longitude | AT | AltRes | Altitude + 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Altitude | Datum | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 LaRes (6 bits): 630 Latitude resolution 632 Latitude (34 bits) 634 LoRes (6 bits): 635 Longitude resolution. 637 Longitude (34 bits) 639 Altitude (30 bits) 641 AltRes (6 bits)" 642 Altitude resolution 644 AT (4 bits): 645 Altitude Type for altitude. The following codes are defined: 647 (1) Meters 648 (2) Floors 650 Datum (8 bits): 651 Coordinate reference system 652 The following codes for the this field are defined: 654 (1) WGS 84 655 (2) NAD 83 656 (3) NAD 83 658 The length of the Location-Information Attribute MUST NOT exceed 253 659 octets. The length of the geospatial location information format is 660 fixed with 16 bytes plus a four byte header. 662 The Datum field contains an identifier for the coordinate system used 663 to interpret the values of Latitude, Longitude and Altitude. The 664 field with value (2) and the value (3) both represent the NAD 83 665 coordinate reference system but they differ from each other with 666 regard to their vertical datum representation as briefly noted in 667 Section 5.2.2 and described in more detail in 668 [I-D.ietf-geopriv-dhcp-lci-option]. 670 9.3 Policy-Information Attribute 672 Policy-Information attribute SHOULD be sent in Access-Request, and 673 Accounting-Request records where the Acc-Status-Type is set to Start, 674 Interim or Stop if available. 676 A summary of the Policy-Information attribute is shown below. 678 0 1 2 3 679 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 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Type | Length | Policy-Information ... 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 Type : 685 To Be Assigned by IANA - Policy-Information 687 Length: 688 >= 3 690 Policy-Information: 691 The text field contains information about the 'usage-rules' 692 element described below. Its length MUST NOT exceed 64 octets. 694 For this document we use the following fields of the 'usage-rules' 695 element, described in [I-D.peterson-geopriv-pidf-lo]: 697 o 'retransmission-allowed' (R): When the value of this element is 698 '0', then the recipient of this Location Object is not permitted 699 to share the enclosed Location Information, or the object as a 700 whole, with other parties. The value of '1' allows to share the 701 Location Information with other parties. 702 o 'retention-expires': This field specifies an absolute date at 703 which time the Recipient is no longer permitted to possess the 704 location information. The data type of this field is a string and 705 the format is a 64 bit NTP timestamp [RFC1305]. 706 o 'ruleset-reference': This field contains a URI that indicates 707 where a fuller ruleset of policies related to this object can be 708 found. As a deviation from [I-D.peterson-geopriv-pidf-lo] this 709 field only contains a reference and does not carry an attached 710 rule set. This modification is motivated by the size limitations 711 imposed by RADIUS. Per-default this field has a null-size. The 712 content of this field is of variable length. 714 We use the following encoding for the Policy-Information element. 715 The 'retransmission-allowed' flag consumes 1 bit, followed by 64 bits 716 for the NTP timestamp and a variable length 'ruleset-reference'. 718 We do not use the 'note-well' element since it contains a block of 719 text with generic privacy directives which are human-readable only. 721 9.4 Location-Type Attribute 723 Location-Type Attribute SHOULD be sent in Access-Request, and 724 Accounting-Request records where the Acc-Status-Type is set to Start, 725 Interim, or Stop if available. 727 A summary of the Location-Type Attribute is shown below. 729 0 1 2 3 730 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 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Type | Length | Loc-Type ... 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 Type (8 bits): 736 To Be Assigned by IANA - Location-Name 738 Length (8 bits): 739 >= 3 741 Loc-Type (variable): 742 The content of this field corresponds to the integer codes for 743 access network location type. 745 9.5 Billing-Description Attribute 747 The Billing-Description Attribute contains unstructured text to be 748 printed on the users bill. 750 0 1 2 3 751 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 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Type | Length | Billing-Text ... 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 Type (8 bits): 757 To Be Assigned by IANA - Billing-Description 759 Length (8 bits): 760 >= 3 762 Billing-Text (variable): 763 The content of this field contains text for billing purpose. 765 The length of the Billing-Description Attribute MUST NOT exceed 32 766 octets. 768 10. Table of Attributes 770 The following table provides a guide to which attributes may be found 771 in which kinds of packets, and in what quantity. 773 Request Accept Reject Challenge Accounting # Attribute 774 Request 775 0-1 0 0 0 0-1 TBD Operator-Name 776 0+ 0 0 0 0+ TBD Location-Information 777 0-1 0 0 0 0-1 TBD Policy-Information 778 0-1 0 0 0 0-1 TBD Location-Type 779 0-1 0 0 0 0 TBD Billing-Description 781 The Location-Information attribute may appear more than once. This 782 is useful if the size of one Location-Information attribute exceeds 783 the maximum size of an AVP. 785 11. IANA Considerations 787 This document requires the assignment of four new RADIUS attribute 788 numbers for the following attributes: 790 Operator-Name 791 Location-Information 792 Policy-Information 793 Location-Name 794 Billing-Description 796 Please refer to Section 10 for the registered list of numbers. 798 12. Example 800 This section provides an example for a civil location information 801 format within the Location-Information attribute. The size of the 802 geo-spatial location information object is fixed and well-described 803 examples can be found in the Appendix of 804 [I-D.ietf-geopriv-dhcp-lci-option]. 806 Due to the size limitations of the RADIUS attributes we give a more 807 detailed example borrowed from Section 4 of 808 [I-D.ietf-geopriv-dhcp-civil]. 810 +-------------+-----------+-------------------+ 811 | Type | Length | Value | 812 +-------------+-----------+-------------------+ 813 | Type | 8 bits | TBD | 814 | Length | 8 bits | 43 | 815 | Code | 16 bits | 1 | 816 | Precision | 8 bits | 2 | 817 | Countrycode | 16 bits | DE | 818 | CAtype | 8 bits | 1 | 819 | CAlength | 8 bits | 7 | 820 | CAvalue | 7 bytes | Bavaria | 821 | CAtype | 8 bits | 3 | 822 | CAlength | 8 bits | 6 | 823 | CAvalue | 6 byte | Munich | 824 | CAtype | 8 bits | 6 | 825 | CAlength | 8 bits | 11 | 826 | CAvalue | 11 bytes | Marienplatz | 827 | CAtype | 8 bits | 19 | 828 | CAlength | 8 bits | 1 | 829 | CAvalue | 1 byte | 8 | 830 | CAtype | 8 bits | 24 | 831 | CAlength | 8 bits | 5 | 832 | CAvalue | 5 bytes | 80331 | 833 +-------------+-----------+-------------------+ 835 The Length element provides the length of the entire payload minus 836 the length of the initial 'Type', the 'Length' and the 'Code' 837 attribute. The Precision field has a value of '2' which refers to 838 the location of the end host (user). The CountryCode is set to 'DE'. 839 Note that the subsequent attributes are in Type-Length-Value format. 840 Type '1' indicates the region of 'Bavaria', '3' refers to the city 841 'Munich', '6' to the street 'Marienplatz', the house number '8' is 842 indicated by the type '19' and the zip code of '80331' is of type 843 '24'. 845 The total sum of these attributes is 46 bytes. 847 13. Privacy Considerations 849 This section discusses privacy implications for the distribution of 850 location lnformation within RADIUS. 852 In many cases the location information of the network also reveals 853 the current location of the user with a certain degree of precision 854 depending on the mechanism used, to determine the location, update 855 frequence, where the location was generated, size of the network and 856 other mechanism (such as movement traces or interpolation). 858 Two entities act as location servers in the configuration shown in 859 Section 4: 861 Entity in the visited network (e.g., visited AAA server): In this 862 scenario it is be difficult to obtain authorization policies from 863 the end host (or user). In this case we have to assume that the 864 visited network does not allow unrestricted distribution of 865 location information. Hence, as a simplification we can assume 866 that per default only the home network is allowed to receive 867 location information. 868 Entity in the home network (e.g., home AAA server): The AAA server in 869 the home network might be an ideal place for storing authorization 870 policies. Once the infrastructure is deployed and useful 871 applications are available there might be a strong desire to use 872 location information for other purposes as well (such as location 873 aware applications). Authorization policy rules described in 874 [I-D.ietf-geopriv-rules] and in [I-D.ietf-geopriv-rules] are 875 tailored for this environment. The user typically has a 876 contractual relationship to his home network and hence the trust 877 relationship between them are higher. These policies might be 878 useful for preventing further distribution of the user's location 879 to other location based services. The home AAA server (or a 880 similar entity) thereby acts as a location server for access to 881 location services. As a default policy we specify that the home 882 network MUST NOT distribute the user's location information to 883 other entities. 885 For the envisioned usage scenarios the network access authentication 886 procedure is tighly coupled to the transfer of location information. 887 If the authentication mechanism allows the visited networks or 888 brokers to learn the user's identity then it is possible to 889 correleate location information with a particular user. This allows 890 the visited network and brokers to learn movement patterns of users. 892 A scenario where the user is attached to the home network is, from a 893 privacy point of view, simpler than a scenario where a user roams 894 into a visited network (where possibly no direct relationship between 895 the visited and the home network operator is available and some AAA 896 brokers need to be consulted) since the NAS and the home AAA are in 897 the same administrative domain. With subscription-based network 898 access as used today the user has a contractual relationship with the 899 home network provider which could allow higher privacy considerations 900 to be applied (including rules stored at the home network itself for 901 the purpose of restricting further distribution). 903 In many cases it is necessary to secure the transport of location 904 information along the RADIUS infrastructure. Mechanism to achieve 905 this functionality are discussed in Section 14. 907 One way to ensure that the visited network and intermediate networks 908 are incapable to learn the user identity is to use EAP methods which 909 hide the user identity either actively or passively. Some EAP 910 methods (such as [I-D.arkko-pppext-eap-aka]) protect the user's 911 identity against passive adversaries by utilizing temporal 912 identities. In some cases the visited network is still able to 913 retrieve the plaintext identity of the user and user identity 914 confidentiality is only provided against eavesdroppers at the 915 wireless link. Depending on the movement patters of the user, the 916 network topology and available roaming agreements it is possible that 917 a AAA broker is able to see both the plaintext user identity and 918 subsequent temporal identities. Associating location information and 919 the user identity is possible in these cases. 921 It is assumed that the true username is not carried within the 922 initial EAP-Identity Request/Response message exchange. Support for 923 username privacy is supported with [I-D.arkko-roamops-rfc2486bis]. 925 For stronger security and privacy protection active user identity 926 confidentiality is highly suggested. EAP methods such as 927 [I-D.josefsson-pppext-eap-tls-eap] or [I-D.tschofenig-eap-ikev2] 928 provide such a protection. 930 Unfortunately, most users are not educated about the importance of 931 user identity confidentiality and many EAP methods do not provide 932 active user identity confidentiality. User identity confidentiality 933 is often treated as an exotic features which mainly aims to prevent 934 eavesdroppers on the wireless link to learn the user identity of the 935 attached users. Awareness for this type of threat model does often 936 not exist. In many cases it is even not possible for users to freely 937 select their favorite authentication and key exchange protocol (based 938 on their security requirements). Instead the choice is often 939 predetermined by a given architecture. 941 It was noted that different granualrity of location information can 942 be provided to the home network. From a privacy point of view lower 943 granularity is preferrable. The user, however, has no control over 944 the granularity and cannot lie about its location. 946 14. Security Considerations 948 Requirements for the security protection of a Location Object is 949 defined in [I-D.ietf-geopriv-reqs]: Mutual end-point authentication, 950 data object integrity, data object confidentiality and replay 951 protection. The distribution of location information can be 952 restricted with the help of authorization policies. Basic 953 authorization policies are attached to the location information 954 itself, in the same fashion as described in 955 [I-D.peterson-geopriv-pidf-lo]. It is possible that the user was 956 already able to transfer some authorization policies to the access 957 network to restrict the distribution of location information. This 958 is, however, rather unlikely in case of roaming users. Hence, it 959 will be primarily the NAS creating the Location Object which also 960 sets the authorization policies. If no authorization information is 961 provided by the user then the visited network MUST set the 962 authorization policies to only allow the home AAA server to use the 963 provided location information. Other entities, such as the visited 964 network and possibly AAA brokers MUST NOT use the location 965 information for a purpose other than described in this document. 966 More extensible authorization policies can be stored at the user's 967 home network. These policies are useful when location information is 968 distributed to other entities in a location-based service. This 969 scenario is, however, outside the scope of this document. 971 It is necessary to use authorization policies to prevent the 972 unauthorized distribution of location information. The security 973 requirements which are created based on [I-D.ietf-geopriv-reqs] are 974 inline with threats which appear in the relationship with disclosure 975 of location information as described in 976 [I-D.ietf-geopriv-threat-analysis]. [I-D.peterson-geopriv-pidf-lo] 977 proposes S/MIME to protect the Location Object against modifications 978 and against eavesdropping. To provide mutual authentication 979 confidentiality protection and a digital signature is necessary. 980 Furthermore, to offer replay protection a gurantee of freshness is 981 necessary (for example, based on timestamps). 983 The security of S/SIME is based on public key cryptography which 984 raises performance, deployment and size considerations. Encryption 985 requires that the local AAA server knows the recipient's public key 986 (e.g., the public key of the home AAA server). Some sort of public 987 key infrastructure is therfore required to obtain the public key and 988 to verify the digital signature (at the home network). Providing 989 per-object cryptographic protection is, both at the home and at the 990 visited network, computationally expensive. 992 To overcome this limitation an alternative approach is suggested. 993 Two security mechanisms are proposed for RADIUS: 995 o [RFC2865] proposes the usage of a static key which is not 996 appropriate for protection of location information due to the 997 missing dynamic key management and absent confidentiality 998 protection. If no authentication, integrity and replay protection 999 between the participating entities are provided then an 1000 adversaries can spoof and modify transmitted AVPs. 1001 o RADIUS over IPsec [RFC3579] allows to run standard key management 1002 mechanisms, such as KINK [I-D.ietf-kink-kink], IKE and IKEv2 1003 [I-D.ietf-ipsec-ikev2], to establish IPsec security associations. 1004 Confidentiality protection MUST be used to prevent eavesdropper 1005 gaining access to location information. Confidentiality 1006 protection is not only a property required by this document, it is 1007 also required for the transport of keying material in the context 1008 of EAP authentication and authorization. Hence, this requirement 1009 is, in many environments, already fulfilled. Mutual 1010 authentication must be provided between the local AAA server and 1011 the home AAA server to prevent man-in-the-middle attacks. This is 1012 another requirement raised in the area of key transport with 1013 RADIUS and does not represent a deployment obstacle. The 1014 performance advantages a superior compared to the usage of S/MIME 1015 and object security since the expensive authentication and key 1016 exchange protocol run needs to be provided only once (at for a 1017 long time). Symmetric channel security with IPsec is highly 1018 efficient. Since IPsec protection is suggested as a mechanism to 1019 protect RAIDUS already no additional considerations need to be 1020 addressed beyond those described in [RFC3579]. Where an untrusted 1021 AAA intermediary is present, the Location Object MUST NOT be 1022 provided to the intermediary. 1024 15. Open Issues 1026 A future version of this document will describe the described Radius 1027 attributes work with Diameter. 1029 Furthermore, the scenarios described in Section 4 need to be 1030 described in more detail. 1032 16. Acknowledgments 1034 The authors would like to thank the following people for their help 1035 with a previous version of this draft and for their input: 1037 Chuck Black 1038 Paul Congdon 1039 Jouni Korhonen 1040 Sami Ala-luukko 1041 Farooq Bari 1042 Ed Van Horne 1043 Mark Grayson 1044 Jukkat Tuomi 1045 Jorge Cuellar 1046 Christian Guenther 1048 Henning Schulzrinne provided the civil location information content 1049 found in this draft. The geospatial location information format is 1050 based on work done by J. Polk, J. Schnizlein and M. Linsner. The 1051 authorization policy format is based on the work done by Jon 1052 Peterson. 1054 The authors would like to thank Victor Lortz, Jose Puthenkulam, 1055 Bernrad Aboba, Jari Arkko, Parviz Yegani, Serge Manning, Kuntal 1056 Chowdury, Pasi Eronen Blair Bullock and Eugene Chang for their 1057 feedback. 1059 This document is partially based on the discussions within the IETF 1060 GEOPRIV working group. Therefore, the authors thank Henning 1061 Schulzrinne, James Polk and John Morris for their work they have done 1062 in the Geopriv working group. 1064 Furthermore, we also have to thank Allison Mankin, Randall Gellens, 1065 Andrew Newton, Ted Hardie, Jon Peterson for their time discussing a 1066 number of details with us. 1068 17. References 1070 17.1 Normative References 1072 [I-D.ietf-geopriv-dhcp-civil] 1073 Schulzrinne, H., "Dynamic Host Configuration Protocol 1074 (DHCPv4 and DHCPv6) Option for Civic Addresses", 1075 draft-ietf-geopriv-dhcp-civil-02 (work in progress), March 1076 2004, . 1078 [I-D.ietf-geopriv-dhcp-lci-option] 1079 Polk, J., Schnizlein, J. and M. Linsner, "Dynamic Host 1080 Configuration Protocol Option for Coordinate-based 1081 Location Configuration Information", 1082 draft-ietf-geopriv-dhcp-lci-option-03 (work in progress), 1083 December 2003, 1084 . 1086 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1087 Requirement Levels", March 1997. 1089 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 1090 "Remote Authentication Dial In User Service (RADIUS)", RFC 1091 2865, June 2000. 1093 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000, 1094 . 1096 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. 1097 Aboba, "Dynamic Authorization Extensions to Remote 1098 Authentication Dial In User Service (RADIUS)", RFC 3576, 1099 July 2003, . 1101 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1102 10646", STD 63, RFC 3629, November 2003, 1103 . 1105 17.2 Informative References 1107 [I-D.adrangi-radius-bandwidth-capability] 1108 Adrangi, F., "Access Network Bandwidth Capability", 1109 draft-adrangi-radius-bandwidth-capability-00 (work in 1110 progress), February 2004, 1111 . 1113 [I-D.arkko-pppext-eap-aka] 1114 Arkko, J. and H. Haverinen, "EAP AKA Authentication", 1115 draft-arkko-pppext-eap-aka-11 (work in progress), October 1116 2003, . 1118 [I-D.arkko-roamops-rfc2486bis] 1119 Aboba, B., "The Network Access Identifier", 1120 draft-arkko-roamops-rfc2486bis-00 (work in progress), 1121 February 2004, 1122 . 1124 [I-D.ietf-geopriv-common-rules] 1125 Schulzrinne, H., Morris, J., Tschofenig, H. and J. Polk, 1126 "Geopriv Rules", draft-ietf-common-rules-00 (work in 1127 progress), January 2004, 1128 . 1130 [I-D.ietf-geopriv-reqs] 1131 Cuellar, J., Morris, J., Mulligan, D., Peterson, D. and D. 1132 Polk, "Geopriv requirements", draft-ietf-geopriv-reqs-04 1133 (work in progress), October 2003, 1134 . 1136 [I-D.ietf-geopriv-rules] 1137 Schulzrinne, H., Morris, J., Tschofenig, H., Polk, J. and 1138 J. Rosenberg, "Common Rules", draft-ietf-common-rules-00 1139 (work in progress), January 2004, 1140 . 1142 [I-D.ietf-geopriv-threat-analysis] 1143 Danley, M., "Threat Analysis of the Geopriv Protocol", 1144 draft-ietf-geopriv-threat-analysis-01 (work in progress), 1145 September 2003, 1146 . 1148 [I-D.ietf-ipsec-ikev2] 1149 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1150 draft-ietf-ipsec-ikev2-13 (work in progress), March 2004, 1151 . 1153 [I-D.ietf-kink-kink] 1154 Thomas, M. and J. Vilhuber, "Kerberized Internet 1155 Negotiation of Keys (KINK)", draft-ietf-kink-kink-05 (work 1156 in progress), January 2003, 1157 . 1159 [I-D.ietf-simple-rpid] 1160 Schulzrinne, H., Gurbani, V., Kyzivat, P. and J. 1161 Rosenberg, "RPID: Rich Presence: Extensions to the 1162 Presence Information Data Format (PIDF)", 1163 draft-ietf-simple-rpid-02 (work in progress), March 2004, 1164 . 1166 [I-D.josefsson-pppext-eap-tls-eap] 1167 Josefsson, S., Palekar, A., Simon, D. and G. Zorn, 1168 "Protected EAP Protocol (PEAP)", 1169 draft-josefsson-pppext-eap-tls-eap-07 (work in progress), 1170 October 2003, 1171 . 1173 [I-D.peterson-geopriv-pidf-lo] 1174 Peterson, J., "A Presence-based GEOPRIV Location Object 1175 Format", draft-peterson-geopriv-pidf-lo-02 (work in 1176 progress), October 2003, 1177 . 1179 [I-D.tschofenig-eap-ikev2] 1180 Tschofenig, H., Kroeselberg, D. and Y. Ohba, "EAP IKEv2 1181 Method (EAP-IKEv2)", draft-tschofenig-eap-ikev2-03 (work 1182 in progress), February 2004, 1183 . 1185 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 1186 Specification, Implementation", RFC 1305, March 1992, 1187 . 1189 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1190 Dial In User Service) Support For Extensible 1191 Authentication Protocol (EAP)", RFC 3579, September 2003. 1193 Authors' Addresses 1195 Hannes Tschofenig 1196 Siemens 1197 Otto-Hahn-Ring 6 1198 Munich, Bayern 81739 1199 Germany 1201 EMail: Hannes.Tschofenig@siemens.com 1203 F. Adrangi 1204 Intel Corporatation 1205 2111 N.E. 25th Avenue 1206 Hillsboro OR 1207 USA 1209 EMail: farid.adrangi@intel.com 1210 Avi Lior 1211 Bridgewater Systems Corporation 1212 303 Terry Fox Drive 1213 Ottawa, Ontario K2K 3J1 1214 CANADA 1216 EMail: avi@bridgewatersystems.com 1218 Mark Jones 1219 Bridgewater Systems Corporation 1220 303 Terry Fox Drive 1221 Ottawa, Ontario K2K 3J1 1222 CANADA 1224 EMail: mark.jones@bridgewatersystems.com 1226 Intellectual Property Statement 1228 The IETF takes no position regarding the validity or scope of any 1229 Intellectual Property Rights or other rights that might be claimed to 1230 pertain to the implementation or use of the technology described in 1231 this document or the extent to which any license under such rights 1232 might or might not be available; nor does it represent that it has 1233 made any independent effort to identify any such rights. Information 1234 on the procedures with respect to rights in RFC documents can be 1235 found in BCP 78 and BCP 79. 1237 Copies of IPR disclosures made to the IETF Secretariat and any 1238 assurances of licenses to be made available, or the result of an 1239 attempt made to obtain a general license or permission for the use of 1240 such proprietary rights by implementers or users of this 1241 specification can be obtained from the IETF on-line IPR repository at 1242 http://www.ietf.org/ipr. 1244 The IETF invites any interested party to bring to its attention any 1245 copyrights, patents or patent applications, or other proprietary 1246 rights that may cover technology that may be required to implement 1247 this standard. Please address the information to the IETF at 1248 ietf-ipr@ietf.org. 1250 Disclaimer of Validity 1252 This document and the information contained herein are provided on an 1253 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1254 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1255 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1256 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1257 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1258 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1260 Copyright Statement 1262 Copyright (C) The Internet Society (2004). This document is subject 1263 to the rights, licenses and restrictions contained in BCP 78, and 1264 except as set forth therein, the authors retain all their rights. 1266 Acknowledgment 1268 Funding for the RFC Editor function is currently provided by the 1269 Internet Society.