idnits 2.17.00 (12 Aug 2021) /tmp/idnits60981/draft-jones-radius-geopriv-00.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 11 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 25 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 269: '...he local network MUST resolve the refe...' RFC 2119 keyword, line 336: '...the home network MUST NOT distribute t...' RFC 2119 keyword, line 337: '...her. Per default MUST NOT distribute l...' RFC 2119 keyword, line 379: '...tion information MAY be provided to th...' RFC 2119 keyword, line 382: '... information, it MUST forward it to th...' (26 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [1], but that reference does not seem to mention RFC 2119 either. -- 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 (January 2003) is 7059 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' == Outdated reference: draft-ietf-geopriv-threat-analysis has been published as RFC 3694 ** Downref: Normative reference to an Informational draft: draft-ietf-geopriv-threat-analysis (ref. '2') == Outdated reference: draft-ietf-geopriv-reqs has been published as RFC 3693 ** Downref: Normative reference to an Informational draft: draft-ietf-geopriv-reqs (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 3579 (ref. '4') == Outdated reference: draft-ietf-geopriv-pidf-lo has been published as RFC 4119 == Outdated reference: draft-ietf-geopriv-policy has been published as RFC 6772 == Outdated reference: draft-ietf-pana-pana has been published as RFC 5191 == Outdated reference: draft-ietf-impp-cpim-pidf has been published as RFC 3863 == Outdated reference: draft-ietf-simple-xcap has been published as RFC 4825 == Outdated reference: draft-ietf-geopriv-dhcp-civil has been published as RFC 4676 Summary: 9 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Radius EXT M. Jones 3 Internet-Draft Bridgewater Systems Corporation 4 Expires: July 2, 2003 H. Tschofenig 5 J. Cuellar 6 Siemens 7 January 2003 9 GEOPRIV support for RADIUS 10 draft-jones-radius-geopriv-00 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on July 2, 2003. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 Network access servers are increasingly capable of providing user and 41 device location information to AAA servers. This enables the AAA 42 server to make additional authorization decisions based on the 43 location of the user or access device. The home or visited network 44 may also use the location information for other purposes (e.g., 45 acting as a location server). This document provides guidelines for 46 the encoding and transport of location information using the RADIUS 47 protocol which are compliant with the Geopriv requirements for 48 security and privacy. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Framework and Scenarios . . . . . . . . . . . . . . . . . . . 5 55 3.1 Location information about a network . . . . . . . . . . . . . 7 56 3.2 Location information about an end user . . . . . . . . . . . . 7 57 3.3 Visited and Home network as a Location Server . . . . . . . . 8 58 3.4 Default privacy-sensitive policy . . . . . . . . . . . . . . . 9 59 4. RADIUS Usage Scenarios . . . . . . . . . . . . . . . . . . . . 10 60 4.1 Home Network Access . . . . . . . . . . . . . . . . . . . . . 10 61 4.2 Visited Network Access . . . . . . . . . . . . . . . . . . . . 11 62 4.3 Visited Network Access via Broker . . . . . . . . . . . . . . 12 63 5. Location Information . . . . . . . . . . . . . . . . . . . . . 15 64 5.1 Civil Location . . . . . . . . . . . . . . . . . . . . . . . . 15 65 5.2 Geospatial Location . . . . . . . . . . . . . . . . . . . . . 16 66 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 67 7. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 21 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 69 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 25 70 Normative References . . . . . . . . . . . . . . . . . . . . . 26 71 Informative References . . . . . . . . . . . . . . . . . . . . 27 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 73 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28 74 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 75 Intellectual Property and Copyright Statements . . . . . . . . 30 77 1. Introduction 79 Location information needs to be protected against unauthorized 80 access to preserve privacy of the owner of the location information. 81 The GEOPRIV working group has defined a protocol-independent model 82 for access to geographic information. The model includes a location 83 generator (LG) that produces location information, a location server 84 (LS) that authorizes access to location information, a location 85 recipient (LR) that requests and receives information, and a 86 rulemaker (RM) that provides policy rules to the LS which enforce 87 access control policies on access to a target. 89 The GEOPRIV working group provided mainly two results. [6] provides 90 the building blocks for the Location Object (LO) itself which 91 contains location information and authorization policies. Two policy 92 rule namespaces have been defined. The first basic rule set, which 93 can be found in [6], can restrict how long the receiver can retain 94 location information and it can prohibit any further distribution. 95 More sophisticated authorization policy rules can be attached to the 96 LO itself (by value or by reference). Location server evaluate these 97 rules to restrict access to location information. GEOPRIV does not 98 reinvent a new location information format. Instead, a subset of 99 GMLv3 is used to provide a rich and flexible mechanisms for 100 representing location information.Section 5 and [6] provide more 101 details on location information encoding using XML in GMLv3. [7] 102 gives details on authorization policies. 104 Network access servers are increasingly capable of providing user and 105 device location information to AAA servers. This enables the AAA 106 server to make additional authorization decisions based on the 107 location of the user or access device. The home or visited network 108 may also use the location information for other purposes (e.g. acting 109 as a location server). The privacy issues discussed in GEOPRIV are 110 especially applicable to the transport of Location Objects between 111 administrative domains using the RADIUS protocol [5] . This document 112 describes the types of location information available to RADIUS 113 clients and servers. It also analyses the various RADIUS usage 114 scenarios with a view to providing security and privacy 115 recommendations for the transport of location information. Finally, 116 the document provides recommendations for the encoding of location 117 and rule set information in the RADIUS protocol. The GEOPRIV 118 requirements [3] will be the guiding document for these 119 recommendations. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [1]. 127 This document reuses the terminology of [3] for Geopriv specific 128 terms such as location server (LS), location recipient (LR), target, 129 using protocol, rule maker (RM) and location object (LO). 131 3. Framework and Scenarios 133 This section describes different models on how location information 134 is retrieved and for which entity location information is requested. 135 Requesting and using location information of a user certainly has 136 privacy implications. In many cases the location information of the 137 network might also reveal the current location of the user with a 138 certain degree of precision depending on the mechanism used, to 139 determine the location, update frequence, where the location was 140 generated, size of the network and other mechanism (such as movement 141 traces or interpolation). 143 We distinguish the case where location information of the visited 144 network is desired whereas the location information of the end host 145 is requested. The latter case can be distinguished from the former by 146 considering the usage of this information. If location information is 147 used for a purpose related to a user then we think it is 148 inappropriate to ignore privacy aspects. In some usage scenarios the 149 network access authentication procedure can be tighly coupled with 150 the transfer of location information. This easily allows to 151 correleate the authenticated user identity and its location 152 information. 154 +------+ 155 +-------------------+ AAA +-----------------+ 156 | |Broker| | 157 +----------+-----------+ +------+ +---------+------------+ 158 | +---+--+ | | +--+---+ | 159 | |Local | | | | Home | | 160 | | AAA +--------+----------------------+------+ AAA | | 161 | |Server| | | |Server| | 162 | +---+--+ | | +------+ | 163 | | | | | 164 | Visited Network | | User's Home Network | 165 | | | | | 166 | +---+----+ | +----------------------+ 167 | | Network| | 168 +------+ Access +------+ 169 | Server | 170 +---+----+ 171 | 172 +---+----+ 173 | Network| 174 | Access | 175 | Client | 176 +---+----+ 177 | 178 O 179 /|\ 180 / \ 181 User 183 Figure 1: Framework 185 Figure 1 shows the different entities participating the various 186 scenarios and note that they might have multiple roles in the Geopriv 187 architecture. For example, the location generator might be the 188 network access client, the user, the local AAA server or another 189 entity in the network. The location server at the local network might 190 be co-located with the AAA server but might also be a physically 191 separated entity. 193 A future version of this document will include a discussion of a more 194 fine-grain differentiation for location requests. The home AAA server 195 is able to request the location object for a particular user or of 196 the visited network. 198 Two variants can be considered. First, the Location Object is 199 requested implicitly, i.e., the Location Object is attached during 200 the network authentication exchange. Second, the home AAA server 201 requests the LO explicitly. This has implications on how a query has 202 to be constructed (i.e., how does the home AAA server request the 203 location object for a particular user). 205 Currently, we assume that the Location Object is sent from the 206 visited AAA server to the home AAA server during or after a 207 successful the network access authentication procedure. 209 Both RADIUS and DIAMETER have the ability to provide interim updates 210 on network usage. Hence, this functionality can be used to 211 periodically transmit uptodate location information. The interval of 212 these updates is typically dictated by the home network when the 213 session is authorized. 215 3.1 Location information about a network 217 The home AAA server requests location information about the visited 218 network itself. In some cases (with a large visited network) it might 219 be difficult to imply the location of a particular user (at least 220 with a certain granularity). GMLv3 provides mechanisms describe the 221 irregular shape of a network. 223 This scenario is useful particularly in cases where the network is 224 non-stationary (such as trains, ships, busses) or where a 225 relationship between the home network and the visited network is 226 dynamically established and the visited network is, to some extend, 227 not known to the home network. 229 If a user is authenticated/authorized only once by the Home AAA 230 server for the use of the entire visited network, the Home AAA server 231 may want to know the extent of the visited network prior to 232 authorizing the usage. It may even return an authorized shape such 233 that re-authorization is required if the user moves outside the 234 specified shape. 236 From a privacy point of view this scenario is certainly simpler since 237 the network is able to control disclosure of its own location 238 information and is able to restrict its distribution (and its 239 granularity). Still GEOPRIV is useful since both the location 240 information format and mechanisms for authorization policy handling 241 can be used. If location information is bundled with a particular 242 user (or used in the context of a particular user) then the authors 243 argue that privacy concerns are applicable. This leads us to the 244 second usage scenario. 246 3.2 Location information about an end user 248 The home AAA server requests (or automatically receives) the location 249 object of a particular user. This assumes that the location of the 250 user is known to the visited network with a certain precision. The 251 exchange might be combined with the initial network access 252 authentication request or even with a later service request. In the 253 latter case it is possible that the target (i.e., user) was already 254 able to transfer some authorization policies to the access network to 255 prevent unlimited distribution of location information. In the former 256 case it is difficult for the end host to provide some rules to the 257 visited network. 259 Additionally, it might even possible that the end host itself 260 provides location information to the local network. From a protocol 261 point of view this message exchange might be outside of scope of this 262 document. However, the consequence of such an exchange is that the 263 network is able to retrieve highly accurate information and also 264 policy rules which might allow disclosure of location information in 265 many ways. Note that the end host might also provide incorrect 266 information (i.e., lie about its current location) to the visited 267 network which can only be prevented to a certain extend. Rules can be 268 included per-value or per-reference. In case that rules are provided 269 per-reference then the local network MUST resolve the reference 270 before responding to redistributing it. For the purpose of providing 271 location information to the home network the end host acts as 272 location generator (LG) and most likely as rule maker (RM) and the 273 local network acts as a location recipient (LR) with regard to 274 location information relevant for the local network itself. However, 275 to provide location information to the home network the local network 276 itself acts as a location server (LS). 278 3.3 Visited and Home network as a Location Server 280 Although not immediately applicable to Radius as a using protocol for 281 Geopriv, the authors think that this issue desires a short 282 discussion. Both the visited and the home network might not be the 283 final consumer of the location information itself. Once the 284 infrastructure is deployed and useful applications are available 285 there might be a strong desire to use location information for other 286 purposes as well (such as location aware applications). Geopriv 287 authorization rules are tailored for this environment as well. 289 As described in previous sections no ideal protocol is available for 290 communication between the end host and the visited network to obtain 291 location information of the end host. If the location itself is known 292 then the user would have to communicate policies for disclosure of 293 location information. Geopriv does not mandate a particular mechanism 294 for carrying policies other than with the Location Object itself (per 295 value and per reference). Many different protocols might be used to 296 create, update or delete policies at a LS in the visited network. 297 PANA [8] might be a protocol for carrying location objects between 298 the end host and the visited network or even for providing a URL to 299 policies (the policies might be stored at the home network, for 300 example). Since PANA does not provide confidentiality protection it 301 is necessary to protect the Loation Object with S/MIME which might 302 lead to IP fragmentation. If authorization policies itself should be 303 delivered to the network then XCAP [10] could be used. 305 The scenario for having the location server at the home network is 306 much simple since a strong trust relationship between the user and 307 the home network is available. With the subscription of the user 308 default policies can be configured. 310 3.4 Default privacy-sensitive policy 312 This section talks about the default configuration for distributing 313 location objects. 315 Two types of entities act as location servers in the configuration 316 shown in Figure 1: 318 Entity in the visited network (e.g., visited AAA server): In this 319 scenario it might be difficult to have policies retrieved from the 320 end host (or user). In this case we have to assume that the 321 visited network does not allow unrestricted distribution of 322 location information. Hence, as a simplification we can assume 323 that per default only the home network is allowed to receive 324 location information. 326 Entity in the home network (e.g., home AAA server): An entity in the 327 home network serves two purposes: First, it might be an ideal 328 place for storing authorization policies and additionally it could 329 store the user's location information for further distribution. In 330 the latter case the home AAA server (or a similar entity) acts as 331 a location server to respond to queries from location recipients. 332 If the end host provides a location object then it might not 333 always want to transport policies along with them. Instead it 334 might be desireable to provide a reference to those object stored 335 at the home location server. As a default policy we specify that 336 the home network MUST NOT distribute the users location 337 information for other. Per default MUST NOT distribute location 338 information of a user to networks other than the user's home 339 network. 341 4. RADIUS Usage Scenarios 343 4.1 Home Network Access 345 +----------------+ 346 | Home Network | 347 | | 348 | +--------+ | 349 | | Home | | 350 | | AAA | | 351 | | Server | | 352 | +----+---+ | 353 | | | 354 | | | 355 | +----+---+ | 356 | | Network| | 357 | | Access | | 358 | | Server | | 359 | +----+---+ | 360 | | | 361 +--------+-------+ 362 | 363 +----+---+ 364 | Network| 365 | Access | 366 | Client | 367 +--------+ 368 O 369 /|\ 370 / \ 371 User 373 Figure 2: Home Network Access 375 In Figure 2, the user is requesting access to his or her home 376 network. The RADIUS protocol is used to communicate the user's 377 identity and credentials from the NAS to the Home AAA Server. The NAS 378 may also be in possession of location information at the time of 379 authentication and this location information MAY be provided to the 380 Home AAA Server in the Access-Request packet. If the NAS also 381 determines the ruleset (or ruleset reference) which applies to the 382 location information, it MUST forward it to the Home AAA server along 383 with the location information. 385 In this scenario, the NAS is considered to operate in the role of a 386 Location Generator and NOT a Location Server. Consequently, RADIUS is 387 NOT considered a 'Using Protocol' and the transport of the location 388 and/or ruleset between NAS and Home AAA Server are not subject to the 389 GEOPRIV security and privacy requirements. 391 Note that Home AAA MAY also be capable of functioning as a Location 392 Server but the protocol between such a Location Server and the 393 Location Recipient is out of the scope of this draft. 395 Even though RADIUS does not serve as a Geopriv using protocol it is 396 still useful to reuse results of the Geopriv working group with 397 regard to the location information format. Using GMLv3 prevents to 398 reinvent a new location format. 400 4.2 Visited Network Access 402 +----------------+ +----------------+ 403 | Visited Network| | Home Network | 404 | | | | 405 | +--------+ | | +--------+ | 406 | | Visited| | | | Home | | 407 | | AAA +---+-----+---+ AAA | | 408 | | Server | | | | Server | | 409 | +----+---+ | | +--------+ | 410 | | | | | 411 | | | +----------------+ 412 | +----+---+ | 413 | | Network| | 414 | | Access | | 415 | | Server | | 416 | +----+---+ | 417 | | | 418 +--------+-------+ 419 | 420 +----+---+ 421 | Network| 422 | Access | 423 | Client | 424 +--------+ 425 O 426 /|\ 427 / \ 428 User 430 Figure 3: Visited Network Access 432 In Figure 3, the user is attempting to access a partner network. The 433 RADIUS protocol is used to communicate the user's identity and 434 credentials from the NAS to the Visited AAA Server and subsequently 435 onto the Home AAA Server. In this scenario, the Visited AAA Server 436 can be considered as acting in the role of Location Server whether or 437 not the location information is explicitly requested by the Home AAA 438 Server. The Home AAA server is acting in the role of Location 439 Recipient. 441 If the Visited AAA Server has determined both the location and 442 applicable ruleset, it MUST evaluate the ruleset prior to 443 communicating the location information to the Home AAA. If the rules 444 allow forwarding, the Visited AAA Server MUST forward the ruleset 445 along with the location information to the Home AAA Server. 447 If, however, the Visited AAA Server is unable to determine the 448 applicable ruleset, it MUST advertise availability of the location 449 information to the Home AAA Server and request the appropriate 450 ruleset. If the Home AAA Server does not return the requested 451 ruleset, the Visited AAA server MUST discard the location 452 information. 454 4.3 Visited Network Access via Broker 455 +----------------+ +----------------+ 456 | Visited Network| | Home Network | 457 | | | | 458 | +--------+ | +--------+ | +--------+ | 459 | | Visited| | | Broker | | | Home | | 460 | | AAA +---+--+ AAA +--+---+ AAA | | 461 | | Server | | | Server | | | Server | | 462 | +----+---+ | +--------+ | +--------+ | 463 | | | | | 464 | | | +----------------+ 465 | +----+---+ | 466 | | Network| | 467 | | Access | | 468 | | Server | | 469 | +----+---+ | 470 | | | 471 +--------+-------+ 472 | 473 +----+---+ 474 | Network| 475 | Access | 476 | Client | 477 +--------+ 478 O 479 /|\ 480 / \ 481 User 483 Figure 4: Visited Network Access via Broker 485 In Figure 4, the Visited and Home Network do not have a direct 486 roaming agreement and so roaming is facilitated by an intermediary 487 called a broker. The Broker AAA Server is responsible for routing AAA 488 requests to the appropriate Home AAA Server and returning the results 489 to the Visited AAA Server. The RADIUS protocol is used to communicate 490 the user's identity and credentials from the NAS to Visited AAA 491 Server to Broker AAA Server and finally onto the Home AAA Server. As 492 in the previous section, the Visited AAA Server MUST NOT provide 493 location information to the Broker AAA Server without first 494 evaluating the rule set governing the usage of the information. 496 If the Visited AAA Server has determined both the location and 497 applicable ruleset, it MUST evaluate the ruleset prior to 498 communicating the location information to the Broker AAA Server. If 499 the rules allow forwarding, the Visited AAA Server MUST forward the 500 ruleset along with the location information to the Broker AAA Server. 501 In turn, the Broker AAA Server MUST also evaluate the ruleset prior 502 to communicating the location information and ruleset to the Home AAA 503 Server. 505 If the Visited AAA Server is unable to determine the ruleset, it MUST 506 advertise availability of the location information to the Broker AAA 507 Server and request the appropriate ruleset. If the Broker AAA Server 508 is able to determine the ruleset, it MUST return the ruleset to the 509 Visited AAA Server on request. If the Broker AAA Server is unable to 510 determine the ruleset, the Broker AAA Server MUST forward the 511 advertisement of the availability of the location information to the 512 Home AAA Server and request the appropriate ruleset. The Broker AAA 513 server MUST NOT modify the ruleset returned by the Home AAA server 514 prior to returning it to the Visited AAA server. 516 On receipt of the ruleset, the Visited AAA Server MUST evaluate it 517 and only forward the location information to the Broker AAA server if 518 permitted by the ruleset. In turn, the Broker AAA Server MUST also 519 evaluate the ruleset prior to forwarding the location information and 520 ruleset to the Home AAA Server. The ruleset MUST always accompany the 521 forwarded location information and MUST NOT be modified in transit. 523 5. Location Information 525 Geopriv defines both civil and geo-spatial location information which 526 is useful in this context. Since GMLv3 does not provide civil 527 location information the civil location format of [6] is used. 529 5.1 Civil Location 531 Civil location is a popular way to describe the location of an 532 entity. Using an unstructured (as a text string) or a custom format 533 for civil location format is dangerous since the automatic processing 534 capabilities are limited. 536 The civil location format includes a number of fields, including the 537 timezone, the country (expressed as a two-letter ISO 3166 code), and 538 the administrative units of [11] A1 through A6. This designation 539 offers street-level precision. 541 The description below is only included for completeness. A more 542 detailed description can be found in [6]. 544 The following civil location elements are defined: 546 +----------------------+----------------------+---------------------+ 547 | Label | Description | Example | 548 +----------------------+----------------------+---------------------+ 549 | country | The country is | US | 550 | | identified by the | | 551 | | two-letter ISO 3166 | | 552 | | code. | | 553 | | | | 554 | A1 | national | New York | 555 | | subdivisions (state, | | 556 | | region, province, | | 557 | | prefecture) | | 558 | | | | 559 | A2 | county, parish, gun | King's County | 560 | | (JP), district (IN) | | 561 | | | | 562 | A3 | city, township, shi | New York | 563 | | (JP) | | 564 | | | | 565 | A4 | city division, | Manhattan | 566 | | borough, city | | 567 | | district, ward, chou | | 568 | | (JP) | | 569 | | | | 570 | A5 | neighborhood, block | Morningside Heights | 571 | | | | 572 | A6 | street | Broadway | 573 | | | | 574 | PRD | Leading street | N, W | 575 | | direction | | 576 | | | | 577 | POD | Trailing street | SW | 578 | | suffix | | 579 | | | | 580 | STS | Street suffix | Avenue, Platz, | 581 | | | Street | 582 | | | | 583 | HNO | House number, | 123 | 584 | | numeric part only. | | 585 | | | | 586 | HNS | House number suffix | A, 1/2 | 587 | | | | 588 | LMK | Landmark or vanity | Low Library | 589 | | address | | 590 | | | | 591 | LOC | Additional location | Room 543 | 592 | | information | | 593 | | | | 594 | FLR | Floor | 5 | 595 | | | | 596 | NAM | Name (residence, | Joe's Barbershop | 597 | | business or office | | 598 | | occupant) | | 599 | | | | 600 | PC | Postal code | 10027-0401 | 601 +----------------------+----------------------+---------------------+ 603 Table 1 605 An example of a civil location XML fragment is shown below: 607 US 608 NJ 609 Bergen 610 Leonia 611 Westview 613 5.2 Geospatial Location 615 Geospatial location information is purely based on the capabilities 616 offered by GMLv3. 618 The Geography Markup Language (GML) as defined by OASIS provides 619 powerful capabilities and is a flexible system for modelling 620 topologies and for describing the location of an object. GML makes 621 use of XML and [6] uses the 'feature.xsd' schema. 623 Location information based on GML is only one information element 624 within PIDF-LO (defined in [6]). Location information is, as a 625 'location-info' element, encapsulated within the XML-based Presence 626 Information Data Format (PIDF) (see [9]) which provides additional 627 information such as a 'timestamp' element which shows the creation 628 time of the PIDF document or the 'presence' element pointing to the 629 URI of the entity whose location information the PIDF object 630 describes. 632 Subsequently we provide some examples for location information. These 633 examples are meant to illustrate the capability of GMLv3 634 'feature.xsd'. 636 The first example of a geospatial location XML fragment with the 637 'gml:Envelope' element. The Envelope element allows to define pairs 638 of positions with opposite corners in arbitrary dimensions. 640 641 642 140. -35. 643 1. 33. 644 645 647 The second example shows the 'gmL:EnvelopeWithTimePeriod' element 648 which is an Envelope element that includes also a temporal extent. 649 Including a time period is useful to indicate the duration in which 650 the indicated location is valid. 652 653 654 12 655 656 657 22 658 659 660 2002-11-25T13:20:20 661 662 2002-11-25T13:25:20 663 665 The next few examples show more sophisticated structures such as the 666 'gml:Polygon' or the 'gml:LinearRing' element. A LinearRing is 667 defined by four or more coordinate tuples, with linear interpolation 668 between them; the first and last coordinates must be coincident. A 669 Polygon is a special surface that is defined by a single surface 670 patch. The boundary of this patch is coplanar and the polygon uses 671 planar interpolation in its interior. It is backwards compatible with 672 the Polygon of GML 2, GM_Polygon of ISO 19107 is implemented by 673 PolygonPatch. 675 676 1 1 677 2 2 678 3 3 679 680 681 4 7 682 683 684 686 687 688 689 10,10 20,10 30, 690 10 30,20 10,20 10,10 691 692 693 695 Please note that the geographic position might be indicated using 696 different coordinate reference systems. GMLv3 defines a number of 697 commonly used onces but allows the system to be extended to support 698 other reference systems. 700 Encoding of location information within the 'gml:LocationString' 701 element, which is a member of the locator attribute in the 702 'gml:Location' element, MUST NOT be used within Geopriv. Encoding of 703 unstructured location information as a opaque string prevents 704 interoperatability and makes automatic processing difficult. If this 705 type of location information is desired then civil location 706 information should be used instead (see Section 5.1). 708 6. Example 710 This section provides a complete example of location information 711 based on PIDF [9] and PIDF-LO [6] including a basic ruleset (defined 712 in PIDF-LO). Please note that the namespaces currently not yet 713 registered and therefore we point to local files. An example with the 714 more flexible authorization rules as defined with [7] will be 715 provided in a future version of this document. 717 718 731 733 734 735 736 737 US 738 New York 739 New York 740 Broadway 741 123 742 Suite 75 743 10027-0401 744 745 746 747 yes 748 2004-06-23T04:57:29Z 749 750 751 752 2003-06-22T20:57:29Z 753 754 756 The "entity" XML element which is part of every PIDF document 757 signifies the URI of the entity whose presence the document 758 describes. This value of this attributes indicates the target of that 759 location information. The "tuple id" element uniquely identify the 760 PIDF segment which allow easy tracking over time. The "timestamp" 761 element designates the time at which the PIDF document was created 762 and it corresponds to the sighting time as stated in requirement 2.7a 763 of [3]. 765 Based on the description in Section 5 it can be seen that civil 766 location is embedded within the PDIF-LO and PIDF document. PIDF 767 provides elements (such as timestamp) and also contains XML elements 768 offered by PIDF-LO (for example the basic authorization rules 769 'retention-expiry' and 'retransmission-allowed'). PIDF-LO offers 770 support for civil and gespatial location information. 772 7. Packet Formats 774 In a previous section, it was stated that the Visited AAA MUST NOT 775 forward the location information to the Broker or Home AAA prior to 776 evaluating the governing rule set. This is accomplished by the 777 Visited AAA including a RuleSetRequest attribute in the RADIUS 778 Access-Request packet. The value of this attribute can be used to 779 indicate whether the originator is capable of processing a RuleSet 780 and/or RuleSet reference. A LocationOriginatorRealm attribute is also 781 included in the RADIUS Access-Request in order to identify who is 782 requesting the RuleSet. 784 The RuleSet or RuleSet reference is returned to the Visited AAA in 785 either an Access-Accept or Access-Reject. It is returned in an 786 Access-Accept if the location is NOT required by the Home AAA in 787 order to complete the authorization for the session. It is returned 788 in an Access-Reject if the location is required by the Home AAA in 789 order to complete the authorization for the session. In the later 790 case, the Visited AAA MUST resubmit the Access-Request after 791 evaluating the RuleSet. 793 +-------------------------+---------+---------+--------+--------+ 794 | Attribute Name | Type | Request | Accept | Reject | 795 +-------------------------+---------+---------+--------+--------+ 796 | LocationOriginatorRealm | text | 0-1 | 0 | 0 | 797 | | | | | | 798 | RulesetRequest | integer | 0-1 | 0 | 0 | 799 | | | | | | 800 | LocationObject | text | 0-1 | 0 | 0 | 801 | | | | | | 802 | RuleSet | text | 0-1 | 0-1 | 0-1 | 803 +-------------------------+---------+---------+--------+--------+ 805 Table 2 807 o 0 This attribute MUST NOT be present in packet. 809 o 0+ Zero or more instances of this attribute MAY be present in 810 packet. 812 o 0-1 Zero or one instance of this attribute MAY be present in 813 packet. 815 o 1 Exactly one instance of this attribute MUST be present in 816 packet. 818 TBD: Add packet size considerations. 820 TBD: Add attribute descriptions, encodings and types. 822 TBD: Need IANA considerations section for new attribute types. 824 8. Security Considerations 826 The Geopriv requirements draft [3] addresses the minimal security 827 protection required for the Location Object: Mutual end-point 828 authentication, data object integrity, data object confidentiality 829 and replay protection. These security properties are implemented via 830 S/MIME and between elements. Protection for the LO includes any 831 attached authorization rules. 833 To capture the different scenarios we need to address them 834 individually: 836 If location information of the visited network is requested by the 837 home network then the visited network acts as a location server (LS) 838 and as a location generator (LG). As such the visited network is able 839 to restrict the distribution of location information. 841 If location information of the user is requested by the home network 842 then the extensions to RADIUS defined in this draft suggest to use it 843 as a using protocol. The protocol capabilities make RADIUS a 844 non-classic using protocol since the initial network access 845 authentication procedure might serve the purpose of attaching 846 location information to the exchange. Additionally, RADIUS can be 847 used to request location information periodically to keep the 848 Location Server at the home network uptodate with the current 849 location of the end user and its movement patterns. 851 If location information (either of the user, visited network or home 852 network) is requested then the results of Geopriv are applicable. 853 Although this communication exchange is not directly applicable for 854 Radius itself it is useful to consider it in the larger context of 855 privacy considerations. 857 Protection needs to be protected in two fashions. First, it is 858 necessary to use authorization policies to prevent the unauthorized 859 distribution of location information. Second, it is necessary to 860 fulfill the security requirements of the Geopriv requirements draft. 861 These requirements are inline with the Geopriv threats draft (see 862 [2]). [6] proposes S/MIME to protect the Location Object against 863 modifications and against eavesdropping. To provide mutual 864 authentication confidentiality protection and a digital signature is 865 necessary. Furthermore, to offer replay protection a gurantee of 866 freshness is necessary (for example, based on timestamps). 868 The security of S/SIME is based on public key cryptography which 869 raises some performance and deployment questions. Encryption requires 870 that the local AAA server knows the recipients (i.e., home AAA 871 servers) public key. Some sort of public key infrastructure is 872 therefore required to obtain the public key (at the visited network) 873 and to verify the digital signature (at the home network). Providing 874 per-object cryptographic protection is, both at the home and at the 875 visited network, quite expensive. 877 To overcome this limitation an alternative approach is suggested. Two 878 security mechanisms are proposed for RADIUS: 880 o [5] proposes the usage of a static key which is not appropriate 881 for protection of location information due to the missing dynamic 882 key management and absent confidentiality protection. If no 883 authentication, integrity and replay protection between the 884 participating entities are provided then an adversaries can spoof 885 and modify transmitted AVPs. 887 o RADIUS over IPsec [4] allows to run standard key management 888 mechanisms, such as KINK, IKE and IKEv2, to establish IPsec 889 security associations. Confidentiality protection MUST be used to 890 prevent eavesdropper gaining access to location information. 891 Confidentiality protection is not only a property required by this 892 document, it is also required for the transport of keying material 893 in the context of EAP authentication and authorization. Hence, 894 this requirement is, in many environments, already fulfilled. 895 Mutual authentication must be provided between the local AAA 896 server and the home AAA server to prevent man-in-the-middle 897 attacks. This is another requirement raised in the area of key 898 transport with RADIUS and does not represent a deployment 899 obstacle. The performance advantages a superior compared to the 900 usage of S/MIME and object security since the expensive 901 authentication and key exchange protocol run needs to be provided 902 only once (at for a long time). Symmetric channel security with 903 IPsec is highly efficient. Since IPsec protection is suggested as 904 a mechanism to protect RAIDUS already no additional considerations 905 need to be addressed beyond those described in [4]. 907 IPsec protection therefore seems to be adequate. 909 Where an untrusted AAA intermediary is present, the Location Object 910 MUST NOT be provided to the intermediary. This can be avoided by use 911 of re-directs or by using S/MIME encryption. 913 9. Open Issues 915 This section lists some open issues which have been identified while 916 working on this approach: 918 o The size of the Location Object might be large when encoded in 919 XML. A discussion of possible approaches for 'compressing' the 920 location object needs to be provided in a future version of this 921 document. 923 o Tentative open issue: Packet formats 925 o DIAMETER is also a good (or even a better) candiate to carry 926 Location Object as described in this document. The authors decided 927 to start with RADIUS but there are not reasons why the same 928 mechanism should not be supported by DIAMETER. 930 Normative References 932 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 933 Levels", March 1997. 935 [2] Danley, M., "Threat Analysis of the geopriv Protocol", 936 draft-ietf-geopriv-threat-analysis-01 (work in progress), 937 September 2003, 938 . 940 [3] Cuellar, J., Morris, J., Mulligan, D., Peterson, D. and D. Polk, 941 "Geopriv requirements", draft-ietf-geopriv-reqs-04 (work in 942 progress), October 2003, . 944 [4] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In 945 User Service) Support For Extensible Authentication Protocol 946 (EAP)", RFC 3579, September 2003. 948 [5] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 949 Authentication Dial In User Service (RADIUS)", RFC 2865, June 950 2000. 952 [6] Peterson, J., "A Presence-based GEOPRIV Location Object Format", 953 draft-ietf-geopriv-pidf-lo-00 (work in progress), January 2004, 954 . 956 [7] Tschofenig, H., Morris, J., Cuellar, J., Polk, J. and H. 957 Schulzrinne, "Policy Rules for Disclosure and Modification of 958 Geographic Information", draft-ietf-geopriv-policy-00 (work in 959 progress), November 2003, 960 . 962 Informative References 964 [8] Forsberg, D., "Protocol for Carrying Authentication for Network 965 Access (PANA)", draft-ietf-pana-pana-02 (work in progress), 966 October 2003, . 968 [9] Sugano, H. and S. Fujimoto, "Presence Information Data Format 969 (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May 970 2003, . 972 [10] Rosenberg, J., "The Extensible Markup Language (XML) 973 Configuration Access Protocol (XCAP)", 974 draft-ietf-simple-xcap-01 (work in progress), October 2003, 975 . 977 [11] Schulzrinne, H., "DHCP Option for Civil Location", 978 draft-ietf-geopriv-dhcp-civil-00 (work in progress), July 2003, 979 . 981 Authors' Addresses 983 Mark Jones 984 Bridgewater Systems Corporation 985 303 Terry Fox Drive 986 Ottawa, Ontario K2K 3J1 987 CANADA 989 EMail: mark.jones@bridgewatersystems.com 991 Hannes Tschofenig 992 Siemens 993 Otto-Hahn-Ring 6 994 Munich, Bayern 81739 995 Germany 997 EMail: Hannes.Tschofenig@siemens.com 999 Jorge R. Cuellar 1000 Siemens 1001 Otto-Hahn-Ring 6 1002 Munich, Bayern 81739 1003 Germany 1005 EMail: Jorge.Cuellar@siemens.com 1007 Appendix A. Contributors 1009 Add your name here. 1011 Appendix B. Acknowledgments 1013 This document is partially based on the discussions within the IETF 1014 GEOPRIV working group. 1016 Some parts of this document are based on other Geopriv documents (for 1017 obvious reasons). For editorial reaons some paragraphs are included 1018 in this draft but might be replaced by a reference in a future 1019 version. The authors thank Henning Schulzrinne, James Polk and John 1020 Morris for their work they have done in the Geopriv working group. 1021 Henning additionally provided the civil location content found in 1022 this draft. 1024 Furthermore, we also have to thank Allison Mankin , 1025 Randall Gellens , Andrew Newton 1026 , Ted Hardie , Jon 1027 Peterson for their time discussing a 1028 number of details with us. It was fun to work with them. 1030 Finally, we would like to thank Hongkun Jiang for 1031 this assistance with GMLv3. 1033 Intellectual Property Statement 1035 The IETF takes no position regarding the validity or scope of any 1036 intellectual property or other rights that might be claimed to 1037 pertain to the implementation or use of the technology described in 1038 this document or the extent to which any license under such rights 1039 might or might not be available; neither does it represent that it 1040 has made any effort to identify any such rights. Information on the 1041 IETF's procedures with respect to rights in standards-track and 1042 standards-related documentation can be found in BCP-11. Copies of 1043 claims of rights made available for publication and any assurances of 1044 licenses to be made available, or the result of an attempt made to 1045 obtain a general license or permission for the use of such 1046 proprietary rights by implementors or users of this specification can 1047 be obtained from the IETF Secretariat. 1049 The IETF invites any interested party to bring to its attention any 1050 copyrights, patents or patent applications, or other proprietary 1051 rights which may cover technology that may be required to practice 1052 this standard. Please address the information to the IETF Executive 1053 Director. 1055 Full Copyright Statement 1057 Copyright (C) The Internet Society (2003). All Rights Reserved. 1059 This document and translations of it may be copied and furnished to 1060 others, and derivative works that comment on or otherwise explain it 1061 or assist in its implementation may be prepared, copied, published 1062 and distributed, in whole or in part, without restriction of any 1063 kind, provided that the above copyright notice and this paragraph are 1064 included on all such copies and derivative works. However, this 1065 document itself may not be modified in any way, such as by removing 1066 the copyright notice or references to the Internet Society or other 1067 Internet organizations, except as needed for the purpose of 1068 developing Internet standards in which case the procedures for 1069 copyrights defined in the Internet Standards process must be 1070 followed, or as required to translate it into languages other than 1071 English. 1073 The limited permissions granted above are perpetual and will not be 1074 revoked by the Internet Society or its successors or assignees. 1076 This document and the information contained herein is provided on an 1077 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1078 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1079 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1080 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1081 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1083 Acknowledgment 1085 Funding for the RFC Editor function is currently provided by the 1086 Internet Society.