idnits 2.17.1 draft-ietf-geopriv-radius-lo-24.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (May 7, 2009) is 5465 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) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 3825 (Obsoleted by RFC 6225) ** Downref: Normative reference to an Informational RFC: RFC 5176 == Outdated reference: A later version (-27) exists of draft-ietf-geopriv-policy-20 -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV H. Tschofenig, Ed. 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Standards Track F. Adrangi 5 Expires: November 8, 2009 Intel 6 M. Jones 7 A. Lior 8 Bridgewater 9 B. Aboba 10 Microsoft Corporation 11 May 7, 2009 13 Carrying Location Objects in RADIUS and Diameter 14 draft-ietf-geopriv-radius-lo-24.txt 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on November 8, 2009. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents in effect on the date of 46 publication of this document (http://trustee.ietf.org/license-info). 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. 50 Abstract 52 This document describes procedures for conveying access network 53 ownership and location information based on a civic and geospatial 54 location format in Remote Authentication Dial In User Service 55 (RADIUS) and Diameter. 57 The distribution of location information is a privacy sensitive task. 58 Dealing with mechanisms to preserve the user's privacy is important 59 and addressed in this document. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Delivery Methods for Location Information . . . . . . . . . . 6 66 3.1. Location Delivery based on Out-of-Band Agreements . . . . 6 67 3.2. Location Delivery based on Initial Request . . . . . . . . 7 68 3.3. Location Delivery based on Mid-Session Request . . . . . . 8 69 3.4. Location Delivery in Accounting Messages . . . . . . . . . 12 70 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 4.1. Operator-Name Attribute . . . . . . . . . . . . . . . . . 14 72 4.2. Location-Information Attribute . . . . . . . . . . . . . . 17 73 4.3. Location-Data Attribute . . . . . . . . . . . . . . . . . 19 74 4.3.1. Civic Location Profile . . . . . . . . . . . . . . . . 20 75 4.3.2. Geospatial Location Profile . . . . . . . . . . . . . 21 76 4.4. Basic-Location-Policy-Rules Attribute . . . . . . . . . . 21 77 4.5. Extended-Location-Policy-Rules Attribute . . . . . . . . . 23 78 4.6. Location-Capable Attribute . . . . . . . . . . . . . . . . 25 79 4.7. Requested-Location-Info Attribute . . . . . . . . . . . . 28 80 5. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 34 81 6. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 36 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 38 83 7.1. Communication Security . . . . . . . . . . . . . . . . . . 38 84 7.2. Privacy Considerations . . . . . . . . . . . . . . . . . . 39 85 7.2.1. RADIUS Client . . . . . . . . . . . . . . . . . . . . 40 86 7.2.2. RADIUS Server . . . . . . . . . . . . . . . . . . . . 40 87 7.2.3. RADIUS Proxy . . . . . . . . . . . . . . . . . . . . . 41 88 7.3. Identity Information and Location Information . . . . . . 41 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 90 8.1. New Registry: Operator Namespace Identifier . . . . . . . 43 91 8.2. New Registry: Location Profiles . . . . . . . . . . . . . 44 92 8.3. New Registry: Location-Capable Attribute . . . . . . . . . 45 93 8.4. New Registry: Entity Types . . . . . . . . . . . . . . . . 46 94 8.5. New Registry: Privacy Flags . . . . . . . . . . . . . . . 46 95 8.6. New Registry: Requested-Location-Info Attribute . . . . . 46 96 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 98 10.1. Normative References . . . . . . . . . . . . . . . . . . . 50 99 10.2. Informative References . . . . . . . . . . . . . . . . . . 50 100 Appendix A. Matching with Geopriv Requirements . . . . . . . . . 53 101 A.1. Distribution of Location Information at the User's 102 Home Network . . . . . . . . . . . . . . . . . . . . . . . 53 103 A.2. Distribution of Location Information at the Visited 104 Network . . . . . . . . . . . . . . . . . . . . . . . . . 54 105 A.3. Requirements matching . . . . . . . . . . . . . . . . . . 55 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61 108 1. Introduction 110 This document defines attributes within RADIUS and Diameter that can 111 be used to convey location-related information within authentication 112 and accounting exchanges. 114 Location information may be useful in a number of scenarios. 115 Wireless networks (including wireless LAN) are being deployed in 116 public places such as airports, hotels, shopping malls, and coffee 117 shops by a diverse set of operators such as cellular network 118 operators, Wireless Internet Service Providers (WISPs), and fixed 119 broadband operators. In these situations, the home network may need 120 to know the location of the user, in order to enable location-aware 121 billing, location-aware authorization, or other location-aware 122 services. Location information can also prove useful in other 123 situations (such as wired networks) where operator network ownership 124 and location information may be needed by the home network. 126 In order to preserve user privacy, location information needs to be 127 protected against unauthorized access and distribution. Requirements 128 for access to location information are defined in [RFC3693]. The 129 model includes a Location Generator (LG) that creates location 130 information, a Location Server (LS) that authorizes access to 131 location information, a Location Recipient (LR) that requests and 132 receives information, and a Rule Maker (RM) that provides 133 authorization policies to the LS which enforces access control 134 policies on requests to location information. In Appendix A the 135 requirements for a GEOPRIV Using Protocol are compared to the 136 functionality provided by this document. 138 2. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 RADIUS specific terminology is borrowed from [RFC2865] and [RFC2866]. 146 Terminology related to privacy issues, location information and 147 authorization policy rules is taken from [RFC3693]. 149 3. Delivery Methods for Location Information 151 The following exchanges show how location information is conveyed in 152 RADIUS. In describing the usage scenarios, we assume that privacy 153 policies allow location to be conveyed in RADIUS; however, as noted 154 in Section 6 similar exchanges can also take place within Diameter. 155 Privacy issues are discussed in Section 7.2. 157 3.1. Location Delivery based on Out-of-Band Agreements 159 Figure 1 shows an example message flow for delivering location 160 information during the network access authentication and 161 authorization procedure. Upon a network authentication request from 162 an access network client, the Network Access Server (NAS) submits a 163 RADIUS Access-Request message that contains location information 164 attributes among other required attributes. In this scenario 165 location information is attached to the Access-Request message 166 without an explicit request from the RADIUS server. Note that such 167 an approach with a prior agreement between the RADIUS client and the 168 RADIUS server is only applicable in certain environments, such as in 169 situations where the RADIUS client and server are within the same 170 administrative domain. The Basic-Location-Policy-Rules Attribute is 171 populated based on the defaults described in Section 4.4, unless it 172 has been explicitly configured otherwise. 174 +---------+ +---------+ +---------+ 175 | | | Network | | RADIUS | 176 | User | | Access | | Server | 177 | | | Server | | | 178 +---------+ +---------+ +---------+ 179 | | | 180 | Authentication phase | | 181 | begin | | 182 |---------------------->| | 183 | | | 184 | | Access-Request | 185 | | + Location-Information | 186 | | + Location-Data | 187 | | + Basic-Location-Policy-Rules| 188 | | + Operator-Name | 189 | |----------------------------->| 190 | | | 191 | | Access-Accept | 192 | |<-----------------------------| 193 | Authentication | | 194 | Success | | 195 |<----------------------| | 196 | | | 198 Figure 1: Location Delivery based on out-of-band Agreements 200 3.2. Location Delivery based on Initial Request 202 If the RADIUS client provides a Location-Capable Attribute in the 203 Access-Request, then the RADIUS server MAY request the RADIUS client 204 for location information if it requires that information for 205 authorization, and location information was not provided in Access- 206 Request. This exchange is shown in Figure 2. The inclusion of the 207 Location-Capable Attribute in an Access-Request message indicates 208 that the NAS is capable of providing location data in response to an 209 Access-Challenge. The subsequent Access-Challenge message sent from 210 the RADIUS server to the NAS provides a hint regarding the type of 211 desired location information attributes. The NAS treats the Basic- 212 Location-Policy-Rules and Extended-Location-Policy-Rules Attributes 213 as opaque data (e.g., it echoes these rules provided by the server 214 within the Access-Challenge back in the Access-Request). In the 215 shown message flow the location attributes are then provided in the 216 subsequent Access-Request message. When evaluating this Access- 217 Request message the authorization procedure at the RADIUS server 218 might be based on a number of criteria, including the newly defined 219 attributes listed in Section 4. 221 +---------+ +---------+ +---------+ 222 | | | Network | | RADIUS | 223 | User | | Access | | Server | 224 | | | Server | | | 225 +---------+ +---------+ +---------+ 226 | | | 227 | Authentication phase | | 228 | begin | | 229 |---------------------->| | 230 | | | 231 | | Access-Request | 232 | | + Location-Capable | 233 | |--------------------------------->| 234 | | | 235 | | Access-Challenge | 236 | | + Basic-Location-Policy-Rules | 237 | | + Extended-Location-Policy-Rules| 238 | | + Requested-Location-Info | 239 | |<---------------------------------| 240 | | | 241 | | Access-Request | 242 | | + Location-Information | 243 | | + Location-Data | 244 | | + Basic-Location-Policy-Rules | 245 | | + Extended-Location-Policy-Rules| 246 | |--------------------------------->| 247 | | | 248 : : : 249 : Multiple Protocol Exchanges to perform : 250 : Authentication, Key Exchange and Authorization : 251 : ...continued... : 252 : : : 253 | | | 254 | | Access-Accept | 255 | |<---------------------------------| 256 | Authentication | | 257 | Success | | 258 |<----------------------| | 259 | | | 261 Figure 2: Location Delivery based on Initial Request 263 3.3. Location Delivery based on Mid-Session Request 265 The on-demand mid-session location delivery method utilizes the 266 Change of Authorization Request (CoA-Request) message and the CoA- 267 NAK, defined in [RFC5176]. At any time during the session the 268 Dynamic Authorization Client MAY send a CoA-Request containing 269 session identification attributes to the NAS (i.e., Dynamic 270 Authorization Server). 272 In order to enable the on-demand mid-session location delivery 273 method, the RADIUS server MUST return an instance of the Requested- 274 Location-Info Attribute with the 'FUTURE_REQUESTS' flag set and 275 instances of the Basic-Location-Policy-Rules and Extended-Location- 276 Policy-Rules Attributes in the Access-Accept message for the session. 277 Upon receipt of a CoA-Request message containing a Service-Type 278 Attribute with value "Authorize Only" for the same session, the NAS 279 MUST include location information and echo the previously received 280 Basic-Location-Policy-Rules and Extended-Location-Policy-Rules 281 Attributes in the subsequent Access-Request message. 283 Upon receiving the Access-Request message containing the Service-Type 284 Attribute with a value of Authorize-Only from the NAS, the RADIUS 285 server responds with either an Access-Accept or an Access-Reject 286 message. 288 The use of dynamic authorization [RFC5176] is necessary when location 289 information is needed on-demand and cannot be obtained from 290 accounting information in a timely fashion. 292 Figure 3 shows the above-described approach graphically. 294 +---------------+ +---------------+ +------+ 295 | Dynamic | | Dynamic | |RADIUS| 296 | Authorization | | Authorization | |Server| 297 | Server/NAS | | Client | | | 298 +---------------+ +---------------+ +------+ 299 | | | 300 | Access-Request | | 301 | + Location-Capable | | 302 |----------------------------------------------------------->| 303 | | | 304 | Access-Challenge | | 305 | + Basic-Location-Policy-Rules | | 306 | + Extended-Location-Policy-Rules | | 307 | + Requested-Location-Info | | 308 |<-----------------------------------------------------------| 309 | | | 310 | Access-Request | | 311 | + Location-Information | | 312 | + Location-Data | | 313 | + Basic-Location-Policy-Rules | | 314 | + Extended-Location-Policy-Rules | | 315 |----------------------------------------------------------->| 316 | | | 317 | | | 318 : | : 319 : Multiple Protocol Exchanges to perform : 320 : Authentication, Key Exchange and Authorization : 321 : ...continued... | : 322 : | : 323 | | | 324 | | | 325 | Access-Accept | | 326 | + Requested-Location-Info | | 327 (FUTURE_REQUESTS,...) | | 328 | + Basic-Location-Policy-Rules | | 329 | + Extended-Location-Policy-Rules | | 330 |<-----------------------------------------------------------| 331 | | | 332 : : : 333 : <> : : 334 : : : 335 | | | 336 | CoA + Service-Type "Authorize Only" + State | | 337 |<--------------------------------------------| | 338 | | | 339 | CoA NAK + Service-Type "Authorize Only" | | 340 | + State | | 341 | + Error-Cause "Request Initiated" | | 342 |-------------------------------------------->| | 343 | | | 344 | Access-Request | | 345 | + Service-Type "Authorize Only" | | 346 | + State | | 347 | + Location-Information | | 348 | + Location-Data | | 349 | + Basic-Location-Policy-Rules | | 350 | + Extended-Location-Policy-Rules | | 351 |----------------------------------------------------------->| 352 | Access-Accept | | 353 |<-----------------------------------------------------------| 354 | | | 356 Figure 3: Location Delivery based on CoA with Service-Type 'Authorize 357 Only' 359 When the Dynamic Authorization Client wants to change the values of 360 the requested location information, or set the values of the 361 requested location information for the first time, it may do so 362 without triggering a reauthorization. Assuming that the NAS had 363 previously sent an Access-Request containing a Location-Capable 364 Attribute, the DAC can send a CoA-Request to the NAS without a 365 Service-Type Attribute, but including the NAS Identifiers and Session 366 identifiers as per [RFC5176] and the Requested-Location-Info, Basic- 367 Location-Policy-Rules and Extended-Location-Policy-Rules Attributes. 368 The Requested-Location-Info, Basic-Location-Policy-Rules and 369 Extended-Location-Policy-Rules Attributes MUST NOT be used for 370 session identification. 372 Figure 4 shows this approach graphically. 374 +---------------+ +---------------+ +------+ 375 | Dynamic | | Dynamic | |RADIUS| 376 | Authorization | | Authorization | |Server| 377 | Server/NAS | | Client | | | 378 +---------------+ +---------------+ +------+ 379 | | | 380 | | | 381 | Access-Request | | 382 | + Location-Capable | | 383 |----------------------------------------------------------->| 384 | | | 385 | Access-Challenge | | 386 | + Basic-Location-Policy-Rules | | 387 | + Extended-Location-Policy-Rules | | 388 | + Requested-Location-Info | | 389 |<-----------------------------------------------------------| 390 | | | 391 | Access-Request | | 392 | + Location-Information | | 393 | + Location-Data | | 394 | + Basic-Location-Policy-Rules | | 395 | + Extended-Location-Policy-Rules | | 396 |----------------------------------------------------------->| 397 | | | 398 | | | 399 : | : 400 : Multiple Protocol Exchanges to perform : 401 : Authentication, Key Exchange and Authorization : 402 : ...continued... | : 403 : | : 404 | | | 405 | | | 406 | Access-Accept | | 407 | + Requested-Location-Info | | 408 | + Basic-Location-Policy-Rules | | 409 | + Extended-Location-Policy-Rules | | 410 |<-----------------------------------------------------------| 411 | | | 412 : : : 413 : <> : : 414 : : : 415 | | | 416 | CoA | | 417 | + Requested-Location-Info | | 418 | + Basic-Location-Policy-Rules | | 419 | + Extended-Location-Policy-Rules | | 420 |<--------------------------------------------| | 421 | | | 422 | CoA ACK | | 423 |-------------------------------------------->| | 424 | | | 425 : : : 426 : <> : : 427 : : : 429 Figure 4: Location Delivery based on CoA 431 3.4. Location Delivery in Accounting Messages 433 Location Information may also be reported in accounting messages. 434 Accounting messages are generated when the session starts, when the 435 session stops and periodically during the lifetime of the session. 436 Accounting messages may also be generated when the user roams during 437 handoff. 439 Accounting information may be needed by the billing system to 440 calculate the user's bill. For example, there may be different 441 tariffs or tax rates applied based on the location. 443 If the RADIUS server needs to obtain location information in 444 accounting messages then it needs to include a Requested-Location- 445 Info Attribute to the Access-Accept message. The Basic-Location- 446 Policy-Rules and the Extended-Location-Policy-Rules Attributes are to 447 be echoed in the Accounting-Request if indicated in the Access- 448 Accept. 450 Figure 5 shows the message exchange. 452 +---------+ +---------+ +---------+ 453 | | | Network | | RADIUS | 454 | User | | Access | | Server | 455 | | | Server | | | 456 +---------+ +---------+ +---------+ 457 | | | 458 : : : 459 : Initial Protocol Interaction : 460 : (details omitted) : 461 : : : 462 | | | 463 | | Access-Accept | 464 | | + Requested-Location-Info | 465 | | + Basic-Location-Policy-Rules | 466 | | + Extended-Location-Policy-Rules| 467 | |<---------------------------------| 468 | Authentication | | 469 | Success | | 470 |<----------------------| | 471 | | | 472 | | Accounting-Request | 473 | | + Location-Information | 474 | | + Location-Data | 475 | | + Basic-Location-Policy-Rules | 476 | | + Extended-Location-Policy-Rules| 477 | |--------------------------------->| 478 | | | 479 | | Accounting-Response | 480 | |<---------------------------------| 481 | | | 483 Figure 5: Location Delivery in Accounting Messages 485 4. Attributes 487 It is important to note that the location specific parts of the 488 attributes defined below are not meant to be processed by the RADIUS 489 server. Instead, a location server specific component used in 490 combination with the RADIUS server is responsible for receiving, 491 processing and further distributing location information (in 492 combination with proper access control and privacy protection). As 493 such, from a RADIUS server point of view location information is 494 treated as opaque data. 496 4.1. Operator-Name Attribute 498 This attribute carries the operator namespace identifier and the 499 operator name. The operator name is combined with the namespace 500 identifier to uniquely identify the owner of an access network. The 501 value of the Operator-Name is a non-NULL terminated string whose 502 length MUST NOT exceed 253 bytes. 504 The Operator-Name Attribute SHOULD be sent in Access-Request, and 505 Accounting-Request messages where the Acc-Status-Type is set to 506 Start, Interim, or Stop. 508 A summary of the Operator-Name Attribute is shown below. 510 0 1 2 3 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Type | Length | Text ... 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Text (cont.) ... 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 Type: 520 To Be Assigned by IANA - Operator-Name 522 Length: 524 >= 4 526 Text: 528 The format is shown below. The data type of this field is 529 string. All fields are transmitted from left to right: 531 0 1 2 3 532 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 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Namespace ID | Operator-Name ... 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Operator-Name ... 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 Namespace ID: 541 The value within this field contains the 542 operator namespace identifier. The Namespace ID value 543 is encoded in ASCII. 545 Example: '1' (0x31) for REALM 547 Operator-Name: 549 The text field of variable length contains an 550 Access Network Operator Name. 551 This field is a RADIUS base data type of Text. 553 The Namespace ID field provides information about the operator 554 namespace. This document defines four values for this attribute that 555 are listed below. Additional namespace identifiers must be 556 registered with IANA (see Section 8.1) and must be associated with an 557 organization responsible for managing the namespace. 559 TADIG ('0' (0x30)): 561 This namespace can be used to indicate operator names based on 562 Transferred Account Data Interchange Group (TADIG) codes, as 563 defined in [GSM]. TADIG codes are assigned by the TADIG Working 564 Group within the GSM Association. The TADIG Code consists of two 565 fields, with a total length of five ASCII characters consisting of 566 a three-character country code and a two-character alphanumeric 567 operator (or company) ID. 569 REALM ('1' (0x31)): 571 The REALM operator namespace can be used to indicate operator 572 names based on any registered domain name. Such names are 573 required to be unique and the rights to use a given realm name are 574 obtained coincident with acquiring the rights to use a particular 575 Fully Qualified Domain Name (FQDN). Since this operator is 576 limited to ASCII, any registered domain name which contains non- 577 ASCII characters must be converted to ASCII. The Punycode 578 encoding [RFC3492] is used for this purpose. 580 E212 ('2' (0x32)): 582 The E212 namespace can be used to indicate operator names based on 583 the Mobile Country Code (MCC) and Mobile Network Code (MNC) 584 defined in [ITU212]. The MCC/MCC values are assigned by the 585 Telecommunications Standardization Bureau (TSB) within the ITU-T 586 and designated administrators in different countries. The E212 587 value consists of three ASCII digits containing the MCC, followed 588 by two or three ASCII digits containing the MNC. 590 ICC ('3' (0x33)): 592 The ICC namespace can be used to indicate operator names based on 593 International Telecommunication Union (ITU) Carrier Codes (ICC) 594 defined in [ITU1400]. ICC values are assigned by national 595 regulatory authorities and are coordinated by the 596 Telecommunication Standardization Bureau (TSB) within the ITU 597 Telecommunication Standardization Sector (ITU-T). When using the 598 ICC namespace, the attribute consists of three uppercase ASCII 599 characters containing a three-letter alphabetic country code, as 600 defined in [ISO], followed by one to six uppercase alphanumeric 601 ASCII characters containing the ICC itself. 603 4.2. Location-Information Attribute 605 The Location-Information Attribute MAY be sent in Access-Request and 606 in Accounting-Request messages. For the Accounting-Request message 607 the Acc-Status-Type may be set to Start, Interim or Stop. 609 The Location-Information Attribute provides meta-data about the 610 location information, such as sighting time, time-to-live, location 611 determination method, etc. 613 The format is shown below. 615 0 1 2 3 616 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 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Type | Length | String ... 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | String (cont.) ... 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 Type: 625 To Be Assigned by IANA - Location-Information 627 Length: 629 >= 23 631 String: 633 The format is shown below. The data type of this field is 634 string. All fields are transmitted from left to right: 636 0 1 2 3 637 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 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Index | Code | Entity | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Sighting Time ~ 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Sighting Time | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Time-to-Live ... 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Time-to-Live | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Method ... 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 Index (16 bits): 655 The 16-bit unsigned integer value allows this attribute to provide 656 information relating to the information included in the Location- 657 Data Attribute to which it refers (via the Index). 659 Code (8 bits): 661 This field indicates the content of the location profile carried 662 in the Location-Data Attribute. Two profiles are defined in this 663 document, namely one civic location profile (see Section 4.3.1) 664 that uses value (0) and a geospatial location profile (see 665 Section 4.3.2) that uses the value (1). 667 Entity (8 bits): 669 This field encodes which location this attribute refers to as an 670 unsigned 8-bit integer value. Location information can refer to 671 different entities. This document registers two entity values, 672 namely: 674 Value (0) describes the location of the user's client device 676 Value (1) describes the location of the RADIUS client 678 The registry used for these values is established by this 679 document, see Section 8.4. 681 Sighting Time (64 bits) 683 This field indicates when the Location Information was accurate. 684 The data type of this field is a string and and the content is 685 expressed in the 64 bit Network Time Protocol (NTP) timestamp 686 format [RFC1305]. 688 Time-to-Live (64 bits): 690 This field gives a hint until when location information should be 691 considered current. The data type of this field is a string and 692 the content is expressed in the 64 bit Network Time Protocol (NTP) 693 timestamp format [RFC1305]. Note that the time-to-live field is 694 different than Retention Expires field used in the Basic-Location- 695 Policy-Rules Attribute, see Section 4.4. Retention expires 696 indicates the time the recipient is no longer permitted to possess 697 the location information. 699 Method (variable): 701 Describes the way that the location information was determined. 702 This field MUST contain the value of exactly one IANA-registered 703 'method' token [RFC4119]. 705 The length of the Location-Information Attribute MUST NOT exceed 253 706 octets. 708 4.3. Location-Data Attribute 710 The Location-Data Attribute MAY be sent in Access-Request and in 711 Accounting-Request messages. For the Accounting-Request message the 712 Acc-Status-Type may be set to Start, Interim or Stop. 714 The format is shown below. 716 0 1 2 3 717 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 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Type | Length | String ... 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | String (cont.) ... 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 Type: 726 To Be Assigned by IANA - Location-Data 728 Length: 730 >= 5 732 String: 734 The format is shown below. The data type of this field is 735 string. All fields are transmitted from left to right: 737 0 1 2 3 738 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 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Index | Location ... 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Location ... 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 Index (16 bits): 747 The 16-bit unsigned integer value allows to associate 748 the Location-Data Attribute with the 749 Location-Information Attributes. 751 Location (variable): 753 The format of the location data depends on the location 754 profile. This document defines two location profiles. 755 Details of the location profiles is described below. 757 4.3.1. Civic Location Profile 759 Civic location is a popular way to describe the location of an 760 entity. This section defines the civic location information profile 761 corresponding to the value (0) indicated in the Code field of the 762 Location-Information Attribute. The location format is based on the 763 encoding format defined in Section 3.1 of [RFC4776] whereby the first 764 3 octets (i.e., the code for this DHCP option, the length of the DHCP 765 option, and the 'what' element are not included) are not put into the 766 Location field of the above-described RADIUS Location-Data Attribute. 768 4.3.2. Geospatial Location Profile 770 This section defines the geospatial location information profile 771 corresponding to the value (1) indicated in the Code field of the 772 Location-Information Attribute. Geospatial location information is 773 encoded as an opaque object whereby the format is reused from the 774 Section 2 of RFC 3825 Location Configuration Information (LCI) format 775 [RFC3825] starting with the third octet (i.e., the code for the DHCP 776 option and the length field is not included). 778 4.4. Basic-Location-Policy-Rules Attribute 780 The Basic-Location-Policy-Rules Attribute MAY be sent in an Access- 781 Request, Access-Accept, an Access-Challenge, a Change-of- 782 Authorization and in an Accounting-Request message. 784 Policy rules control the distribution of location information. The 785 obligation with respect to understanding and processing of the Basic- 786 Location-Policy-Rules Attribute for RADIUS clients is to utilize a 787 default value of Basic-Location-Policy-Rules unless explicitly 788 configured otherwise, and also for clients to echo the Basic- 789 Location-Policy-Rules Attribute that they receive from a server. As 790 a default, the note-well field does not carry a pointer to human 791 readable privacy policies, the retransmission-allowed is set to zero 792 (0), i.e., further distribution is not allowed, and the retention- 793 expires field is set to 24 hours. 795 With regard to authorization policies this document reuses work done 796 in [RFC4119] and encodes them in a non-XML format. Two fields 797 ('sighting time' and 'time-to-live') are additionally included in the 798 Location-Information Attribute to conform to the GEOPRIV requirements 799 [RFC3693], Section 2.7. 801 The format of the Basic-Location-Policy-Rules Attribute is shown 802 below. 804 0 1 2 3 805 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 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Type | Length | String ... 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | String (cont.) ... 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 Type: 814 To Be Assigned by IANA - Basic-Location-Policy-Rules 816 Length: 818 >= 12 820 String: 822 The format is shown below. The data type of this field is 823 string. All fields are transmitted from left to right: 825 0 1 2 3 826 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 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | Flags | Retention Expires ... 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | Retention Expires ... 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | Retention Expires | Note Well ... 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Note Well ... 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 This document reuses fields of the RFC 4119 [RFC4119] 'usage-rules' 838 element. These fields have the following meaning: 840 Flags (16 bits): 842 The Flags field is a bit mask and only the first bit (R) is 843 defined in this document and corresponds to the retransmission- 844 allowed field: 846 0 1 847 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 |R|o o o o o o o o o o o o o o o| 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 R = retransmission-allowed 853 o = reserved. 855 All reserved bits MUST be zero. When the value of this field the 856 retransmission-allowed field is set to zero (0), then the 857 recipient of this Location Object is not permitted to share the 858 enclosed location information, or the object as a whole, with 859 other parties. The value of '1' allows to share the location 860 information with other parties by considering the extended policy 861 rules. 863 Retention Expires (64 bits): 865 This field specifies an absolute date at which time the Recipient 866 is no longer permitted to possess the location information. The 867 data type of this field is a string and the format is a 64 bit NTP 868 timestamp [RFC1305]. 870 Note Well (variable): 872 This field contains a URI that points to human readable privacy 873 instructions. The data type of this field is string. This field 874 is useful when location information is distributed to third party 875 entities, which can include humans in a location based service. 876 RADIUS entities are not supposed to process this field. 878 Whenever a Location Object leaves the RADIUS eco-system the URI in 879 the note-well attribute MUST be expanded to the human readable 880 text. For example, when the Location Object is transferred to a 881 SIP based environment then the human readable text is placed into 882 the 'note-well' element of the 'usage-rules' element contained in 883 the PIDF-LO document (see [RFC4119]). The note-well field may be 884 empty. 886 4.5. Extended-Location-Policy-Rules Attribute 888 The Extended-Location-Policy-Rules Attribute MAY be sent in an 889 Access-Request, an Access-Accept, an Access-Challenge, an Access- 890 Reject, an Change-of-Authorization and in an Accounting-Request 891 message. 893 The ruleset reference field of this attribute is of variable length. 894 It contains a URI that indicates where the richer ruleset can be 895 found. This URI SHOULD use the HTTPS URI scheme. As a deviation 896 from [RFC4119] this field only contains a reference and does not 897 carry an attached extended rule set. This modification is motivated 898 by the size limitations imposed by RADIUS. 900 Policy rules control the distribution of location information and, as 901 with the Basic Policy Rules Attribute the obligation with respect to 902 understanding and processing of the Extended-Location-Policy-Rules 903 Attribute for RADIUS clients is when they are explicitly configured 904 to attach the URI, and also for clients to echo the Extended- 905 Location-Policy-Rules Attribute that they receive from a server. 906 There is no expectation that RADIUS clients will need to retrieve 907 data at the URL specified in the attribute and to parse the XML 908 policies. 910 The format of the Extended-Location-Policy-Rules Attribute is shown 911 below. 913 0 1 2 3 914 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 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | Type | Length | String ... 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | String (cont.) ... 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 Type: 923 To Be Assigned by IANA - Extended-Location-Policy-Rules 925 Length: 927 >= 3 929 String: 931 This field is at least two octets in length, and the format 932 is shown below. The data type of this field is string. 933 The fields are transmitted from left to right: 935 0 1 2 3 936 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 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Ruleset Reference ... 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 Ruleset Reference: 943 This field contains a URI that points to the policy rules. 945 4.6. Location-Capable Attribute 947 The Location-Capable Attribute allows a NAS (or client function of a 948 proxy server) to indicate support for the functionality specified in 949 this document. The Location-Capable Attribute with the value for 950 'Location Capable' MUST be sent with the Access-Request messages, if 951 the NAS supports the functionality described in this document and is 952 capable of sending location information. A RADIUS server MUST NOT 953 challenge for location information unless the Location-Capable 954 Attribute has been sent to it. 956 0 1 2 3 957 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 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Type | Length | Integer | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | Integer (cont.) | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 Type: 966 To Be Assigned by IANA - Location-Capable Attribute 968 Length: 970 6 972 Integer: 974 The content of the Integer field encodes the 975 requested capabilities. 976 Each capability value represents a bit position. 978 This document specifies the following capabilities: 980 Name: 982 CIVIC_LOCATION 984 Description: 986 The RADIUS client uses the CIVIC_LOCATION to indicate that it is 987 able to return civic location based on the location profile 988 defined in Section 4.3.1. 990 Numerical Value: 992 A numerical value of this token is '1'. 994 Name: 996 GEO_LOCATION 998 Description: 1000 The RADIUS client uses the GEO_LOCATION to indicate that it is 1001 able to return geodetic location based on the location profile 1002 defined in Section 4.3.2. 1004 Numerical Value: 1006 A numerical value of this token is '2'. 1008 Name: 1010 USERS_LOCATION 1012 Description: 1014 The numerical value representing USERS_LOCATION indicates that the 1015 RADIUS client is able to provide a Location-Information attribute 1016 with the Entity attribute expressing the value of zero (0), i.e., 1017 the RADIUS client is capable of returning location information of 1018 the user's client device. 1020 Numerical Value: 1022 A numerical value of this token is '4'. 1024 Name: 1026 NAS_LOCATION 1028 Description: 1030 The numerical value representing NAS_LOCATION indicates that the 1031 RADIUS client is able to provide a Location-Information attribute 1032 that contains location information with the Entity attribute 1033 expressing the value of one (1), i.e., the RADIUS client is 1034 capable of returning location information of the NAS. 1036 Numerical Value: 1038 A numerical value of this token is '8'. 1040 4.7. Requested-Location-Info Attribute 1042 The Requested-Location-Info Attribute allows the RADIUS server to 1043 indicate what location information about which entity it wants to 1044 receive. The latter aspect refers to the entities that are indicated 1045 in the Entity field of the Location-Information Attribute. 1047 The Requested-Location-Info Attribute MAY be sent in an Access- 1048 Accept, in an Access-Challenge, or a Change of Authorization packet. 1050 If the RADIUS server wants to dynamically decide on a per-request 1051 basis to ask for location information from the RADIUS client then the 1052 following cases need to be differentiated. If the RADIUS client and 1053 the RADIUS server have agreed out-of-band to mandate the transfer of 1054 location information for every network access authentication request 1055 then the processing listed below is not applicable. 1057 o If the RADIUS server requires location information for computing 1058 the authorization decision and the RADIUS client does not provide 1059 it with the Access-Request message then the Requested-Location- 1060 Info Attribute is attached to the Access-Challenge with a hint 1061 about what is required. 1063 o If the RADIUS server does not receive the requested information in 1064 response to the Access-Challenge (including the Requested- 1065 Location-Info Attribute) then the RADIUS server may respond with 1066 an Access-Reject message with an Error-Cause Attribute (including 1067 the "Location-Info-Required" value). 1069 o If the RADIUS server would like location information in the 1070 Accounting-Request message but does not require it for computing 1071 an authorization decision then the Access-Accept message MUST 1072 include a Required-Info Attribute. This is typically the case 1073 when location information is used only for billing. The RADIUS 1074 client SHOULD attach location information, if available, to the 1075 Accounting-Request (unless authorization policies dictate 1076 something different). 1078 If the RADIUS server does not send a Requested-Location-Info 1079 Attribute then the RADIUS client MUST NOT attach location information 1080 to messages towards the RADIUS server. The user's authorization 1081 policies, if available, MUST be consulted by the RADIUS server before 1082 requesting location information delivery from the RADIUS client. 1084 Figure 6 shows a simple protocol exchange where the RADIUS server 1085 indicates the desire to obtain location information, namely civic 1086 location information of the user, to grant access. Since the 1087 Requested-Location-Info Attribute is attached to the Access-Challenge 1088 the RADIUS server indicates that location information is required for 1089 computing an authorization decision. 1091 +---------+ +---------+ 1092 | RADIUS | | RADIUS | 1093 | Client | | Server | 1094 +---------+ +---------+ 1095 | | 1096 | | 1097 | Access-Request | 1098 | + Location-Capable | 1099 | ('CIVIC_LOCATION', | 1100 | 'GEO_LOCATION', | 1101 | 'NAS_LOCATION', | 1102 | 'USERS_LOCATION') | 1103 |--------------------------------->| 1104 | | 1105 | Access-Challenge | 1106 | + Requested-Location-Info | 1107 | ('CIVIC_LOCATION', | 1108 | 'USERS_LOCATION') | 1109 | + Basic-Location-Policy-Rules | 1110 | + Extended-Location-Policy-Rules | 1111 |<---------------------------------| 1112 | | 1113 | Access-Request | 1114 | + Location-Information | 1115 | + Location-Data | 1116 | + Basic-Location-Policy-Rules | 1117 | + Extended-Location-Policy-Rules | 1118 |--------------------------------->| 1119 | | 1120 | .... | 1122 Figure 6: RADIUS server requesting location information 1124 The Requested-Location-Info Attribute MUST be sent by the RADIUS 1125 server, in the absence of an out-of-band agreement, if it wants the 1126 RADIUS client to return location information and if authorization 1127 policies permit it. This Requested-Location-Info Attribute MAY 1128 appear in the Access-Accept or in the Access-Challenge message. 1130 A summary of the attribute is shown below. 1132 0 1 2 3 1133 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 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 | Type | Length | Integer ... 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 | Integer (cont.) | 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 Type: 1142 To Be Assigned by IANA - Requested-Location-Info Attribute 1144 Length: 1146 6 1148 Integer: 1150 The content of the Integer field encodes the 1151 requested information attributes. 1152 Each capability value represents a bit position. 1154 This document specifies the following capabilities: 1156 Name: 1158 CIVIC_LOCATION 1160 Description: 1162 The RADIUS server uses the Requested-Location-Info Attribute with 1163 the value set to CIVIC_LOCATION to request specific location 1164 information from the RADIUS client. The numerical value 1165 representing CIVIC_LOCATION requires the RADIUS client to attach 1166 civic location attributes. CIVIC_LOCATION refers to the location 1167 profile defined in Section 4.3.1. 1169 Numerical Value: 1171 A numerical value of this token is '1'. 1173 Name: 1175 GEO_LOCATION 1177 Description: 1179 The RADIUS server uses the Requested-Location-Info Attribute with 1180 the value set to GEO_LOCATION to request specific location 1181 information from the RADIUS client. The numerical value 1182 representing GEO_LOCATION requires the RADIUS client to attach 1183 geospatial location attributes. GEO_LOCATION refers to the 1184 location profile described in Section 4.3.2. 1186 Numerical Value: 1188 A numerical value of this token is '2'. 1190 Name: 1192 USERS_LOCATION 1194 Description: 1196 The numerical value representing USERS_LOCATION indicates that the 1197 RADIUS client MUST sent a Location-Information attribute with the 1198 Entity attribute expressing the value of zero (0). Hence, there 1199 is a one-to-one relationship between USERS_LOCATION token and the 1200 value of zero (0) of the Entity attribute inside the Location- 1201 Information attribute. A value of zero indicates that the 1202 location information in the Location-Information attribute refers 1203 to the user's client device. 1205 Numerical Value: 1207 A numerical value of this token is '4'. 1209 Name: 1211 NAS_LOCATION 1213 Description: 1215 The numerical value representing NAS_LOCATION indicates that the 1216 RADIUS client MUST sent a Location-Information attribute that 1217 contains location information with the Entity attribute expressing 1218 the value of one (1). Hence, there is a one-to-one relationship 1219 between NAS_LOCATION token and the value of one (1) of the Entity 1220 attribute inside the Location-Information attribute. A value of 1221 one indicates that the location information in the Location- 1222 Information attribute refers to the RADIUS client. 1224 Numerical Value: 1226 A numerical value of this token is '8'. 1228 Name: 1230 FUTURE_REQUESTS 1232 Description: 1234 The numerical value representing FUTURE_REQUESTS indicates that 1235 the RADIUS client MUST provide future Access-Requests for the same 1236 session with the same type of information as returned in the 1237 initial Access-Request message. 1239 Numerical Value: 1241 A numerical value of this token is '16'. 1243 Name: 1245 NONE 1247 Description: 1249 The RADIUS server uses this token to request that the RADIUS 1250 client stops sending location information. 1252 Numerical Value: 1254 A numerical value of this token is '32'. 1256 If neither the NAS_LOCATION nor the USERS_LOCATION bit is set then 1257 per-default the location of the user's client device is returned (if 1258 authorization policies allow it). If both the NAS_LOCATION and the 1259 USERS_LOCATION bits are set then the returned location information 1260 has to be put into separate attributes. If neither the 1261 CIVIC_LOCATION nor the GEO_LOCATION bit is set in the Requested- 1262 Location-Info Attribute then no location information is returned. If 1263 both the CIVIC_LOCATION and the GEO_LOCATION bits are set then the 1264 location information has to be put into separate attributes. The 1265 value of NAS_LOCATION and USERS_LOCATION refers to the location 1266 information requested via CIVIC_LOCATION and via GEO_LOCATION. 1268 As an example, if the bits for NAS_LOCATION, USERS_LOCATION and 1269 GEO_LOCATION are set then location information of the RADIUS client 1270 and the users' client device are returned in a geospatial location 1271 format. 1273 5. Table of Attributes 1275 The following table provides a guide which attributes may be found in 1276 which RADIUS messages, and in what quantity. 1278 Request Accept Reject Challenge Accounting # Attribute 1279 Request 1280 0-1 0-1 0 0 0+ TBD Operator-Name 1281 0+ 0 0 0 0+ TBD Location-Information 1282 0+ 0 0 0 0+ TBD Location-Data 1283 0-1 0-1 0-1 0-1 0-1 TBD Basic-Location- 1284 Policy-Rules 1285 0-1 0-1 0-1 0-1 0-1 TBD Extended-Location- 1286 Policy-Rules 1287 0 0-1 0 0-1 0 TBD Requested-Location-Info 1288 0-1 0 0 0 0 TBD Location-Capable 1289 0 0 0-1 0 0 101 Error-Cause [note1] 1291 [note1] The Error-Cause attribute contains the value for the 1292 'Location-Info-Required' error. 1294 Change-of-Authorization Messages 1296 Request ACK NAK # Attribute 1297 0-1 0 0 TBD Basic-Location-Policy-Rules 1298 0-1 0 0 TBD Extended-Location-Policy-Rules 1299 0-1 0 0 TBD Requested-Location-Info 1301 Legend: 1303 0 This attribute MUST NOT be present. 1304 0+ Zero or more instances of this attribute MAY be present. 1305 0-1 Zero or one instance of this attribute MAY be present. 1306 1 Exactly one instance of this attribute MUST be present. 1307 1+ One or more of these attributes MUST be present. 1309 Figure 7: Table of Attributes 1311 The Error-Cause Attribute is defined in [RFC5176]. 1313 The Location-Information and the Location-Data Attribute MAY appear 1314 more than once. For example, if the server asks for civic and 1315 geospatial location information two Location-Information Attributes 1316 need to be sent. 1318 The attributes defined in this document are not used in any messages 1319 other than the ones listed in Figure 7. 1321 This document requests IANA to allocate a new value from the Error- 1322 Cause registry with the semantic of 'Location-Info-Required'. 1324 6. Diameter RADIUS Interoperability 1326 When used in Diameter, the attributes defined in this specification 1327 can be used as Diameter AVPs from the Code space 1-255 (RADIUS 1328 attribute compatibility space). No additional Diameter Code values 1329 are therefore allocated. The data types and flag rules, as defined 1330 in [RFC3588], for the Diameter AVPs are as follows: 1332 +---------------------+ 1333 | AVP Flag rules | 1334 +----+-----+------+-----+----+ 1335 | | |SHOULD| MUST| | 1336 Attribute Name Value Type |MUST| MAY | NOT | NOT|Encr| 1337 +---------------------------------+----+-----+------+-----+----+ 1338 |Operator-Name OctetString| | P | | V,M | Y | 1339 |Location-Information OctetString| | P | | V,M | Y | 1340 |Location-Data OctetString| | P | | V,M | Y | 1341 |Basic-Location- | | | | | | 1342 | Policy-Rules OctetString| | P | | V,M | Y | 1343 |Extended-Location- | | | | | | 1344 | Policy-Rules OctetString| | P | | V,M | Y | 1345 |Requested- | | | | | | 1346 | Location-Info OctetString| | P | | V,M | Y | 1347 |Location-Capable OctetString| | P | | V,M | Y | 1348 +---------------------------------+----+-----+------+-----+----+ 1350 The RADIUS attributes in this specification have no special 1351 translation requirements for Diameter to RADIUS or RADIUS to Diameter 1352 gateways; they are copied as is, except for changes relating to 1353 headers, alignment, and padding. See also Section 4.1 of [RFC3588] 1354 and Section 9 of [RFC4005]. 1356 What this specification says about the applicability of the 1357 attributes for RADIUS Access-Request packets applies in Diameter to 1358 AA-Request [RFC4005] or Diameter-EAP-Request [RFC4072]. What is said 1359 about Access-Challenge applies in Diameter to AA-Answer [RFC4005] or 1360 Diameter-EAP-Answer [RFC4072] with Result-Code AVP set to 1361 DIAMETER_MULTI_ROUND_AUTH. What is said about Access-Accept applies 1362 in Diameter to AA-Answer or Diameter-EAP-Answer messages that 1363 indicate success. Similarly, what is said about RADIUS Access-Reject 1364 packets applies in Diameter to AA-Answer or Diameter-EAP-Answer 1365 messages that indicate failure. 1367 What is said about CoA-Request applies in Diameter to Re-Auth-Request 1368 [RFC4005]. 1370 What is said about Accounting-Request applies to Diameter Accounting- 1371 Request [RFC4005] as well. 1373 Note that these AVPs may be used by Diameter applications other than 1374 RFC 4005 [RFC4005] and RFC 4072 [RFC4072]. The above-mentioned 1375 applications are, however, likely to be relevant in the context of 1376 this document. 1378 7. Security Considerations 1380 A number of security aspects are relevant for the distribution of 1381 location information via RADIUS. These aspects are discussed in 1382 separate sub-sections. 1384 7.1. Communication Security 1386 Requirements for the protection of a Location Object are defined in 1387 [RFC3693], namely mutual end-point authentication, data object 1388 integrity, data object confidentiality and replay protection. 1390 If no authentication, integrity and replay protection between the 1391 participating RADIUS entities is provided then adversaries can spoof 1392 and modify transmitted attributes. Two security mechanisms are 1393 proposed for RADIUS: 1395 o [RFC2865] proposes the usage of a static key that raised concerns 1396 regarding the lack dynamic key management. At the time of 1397 writing, work is ongoing to address some shortcomings of [RFC2865] 1398 attribute security protection. 1400 o RADIUS over IPsec [RFC3579] enables the use of standard key 1401 management mechanisms, such as KINK, IKE and IKEv2 [RFC4306], to 1402 establish IPsec security associations. Confidentiality protection 1403 MUST be used to prevent eavesdropper gaining access to location 1404 information. Confidentiality protection already present for other 1405 reasons in many environments, such as for the transport of keying 1406 material in the context of EAP authentication and authorization. 1407 Hence, this requirement is, in many environments, already 1408 fulfilled. Mutual authentication MUST be provided between 1409 neighboring RADIUS entities to prevent man-in-the-middle attacks. 1410 Since mutual authentication is already required for key transport 1411 within RADIUS messages it does not represent a deployment 1412 obstacle. Since IPsec protection is suggested as a mechanism to 1413 protect RADIUS already no additional considerations need to be 1414 addressed beyond those described in [RFC3579]. 1416 In case that IPsec protection is not available for some reason and 1417 RADIUS specific security mechanisms have to be used then the 1418 following considerations apply. The Access-Request message is not 1419 integrity protected. This would allow an adversary to change the 1420 contents of the Location Object or to insert, modify and delete 1421 attributes or individual fields. To address these problems the 1422 Message-Authenticator (80) can be used to integrity protect the 1423 entire Access-Request packet. The Message-Authenticator (80) is also 1424 required when EAP is used and hence is supported by many modern 1425 RADIUS servers. 1427 Access-Request packets including location attribute(s) without a 1428 Message-Authenticator(80) Attribute SHOULD be silently discarded by 1429 the RADIUS server. A RADIUS server supporting location attributes 1430 MUST calculate the correct value of the Message-Authenticator(80) and 1431 MUST silently discard the packet if it does not match the value sent. 1433 Access-Accept, including location attribute(s) without a Message- 1434 Authenticator(80) Attribute SHOULD be silently discarded by the NAS. 1435 A NAS supporting location attributes MUST calculate the correct value 1436 of a received Message-Authenticator(80) and MUST silently discard the 1437 packet if it does not match the value sent. 1439 RADIUS and Diameter make some assumptions about the trust between 1440 traversed RADIUS entities in the sense that object level security is 1441 not provided by neither RADIUS nor Diameter. Hence, some trust has 1442 to be placed on the RADIUS entities to behave according to the 1443 defined rules. Furthermore, the RADIUS protocol does not involve the 1444 user in their protocol interaction except for tunneling 1445 authentication information (such as EAP messages) through their 1446 infrastructure. RADIUS and Diameter have even become a de-facto 1447 protocol for key distribution for network access authentication 1448 applications. Hence, in the past there were some concerns about the 1449 trust placed into the infrastructure particularly from the security 1450 area when it comes to keying. The EAP keying infrastructure is 1451 described in [RFC4282]. 1453 7.2. Privacy Considerations 1455 This section discusses privacy implications for the distribution of 1456 location information within RADIUS. Note also that it is possible 1457 for the RADIUS server to obtain some amount of location information 1458 from the NAS identifier. This document, however, describes 1459 procedures to convey more accurate location information about the end 1460 host and/or the network. In a number of deployment environments 1461 location information about the network also reveals the current 1462 location of the user with a certain degree of precision depending on 1463 the location determination mechanism used, update frequency, the size 1464 of the network and other factors, such as movement traces. 1466 Three types of use cases have to be differentiated: 1468 o RADIUS server does not want to receive location information from 1469 the RADIUS client. 1471 o In case there is an out-of-band agreement between the entity 1472 responsible for the NAS and the entity operating the RADIUS server 1473 then location information may be sent without an explicit request 1474 from the RADIUS server. 1476 o The RADIUS server dynamically requests location information from 1477 the NAS. 1479 7.2.1. RADIUS Client 1481 The RADIUS client MUST behave according to the following guidelines: 1483 o If neither an out-of-band agreement exists nor location 1484 information is requested by the RADIUS server then location 1485 information is not disclosed by the RADIUS client. 1487 o The RADIUS client MUST pass location information to other entities 1488 (e.g., when information is written to a local database or to the 1489 log files) only together with the policy rules. The entity 1490 receiving the location information (together with the policies) 1491 MUST follow the guidance given with these rules. 1493 o A RADIUS client MUST include Basic-Location-Policy-Rules and 1494 Extended-Location-Policy-Rules Attributes that are configured 1495 within an Access-Request packet. 1497 o NAS implementations supporting this specification, which are 1498 configured to provide location information, MUST echo Basic- 1499 Location-Policy-Rules and Extended-Location-Policy-Rules 1500 Attributes unmodified within a subsequent Access-Request packet. 1501 In addition, an Access-Request packet sent with a Service-Type 1502 value of "Authorize Only" MUST include Basic-Location-Policy-Rules 1503 or Extended-Location-Policy-Rules Attributes received in a 1504 previous Access-Accept if the FUTURE_REQUESTS flag was set in the 1505 Requested-Location-Info Attribute. 1507 7.2.2. RADIUS Server 1509 The RADIUS server is a natural place for storing authorization 1510 policies since the user typically has some sort of trust relationship 1511 with the entity operating the RADIUS server. Once the infrastructure 1512 is deployed and location aware applications are available then there 1513 might be a strong desire to use location information for other 1514 purposes as well. 1516 The Common Policy framework [RFC4745] that was extended for 1517 geolocation privacy [I-D.ietf-geopriv-policy] are tailored for 1518 this purpose. The Extensible Markup Language (XML) Configuration 1519 Access Protocol (XCAP) [RFC4825] gives users the ability to change 1520 their privacy policies using a standardized protocol. These 1521 policies are an important tool for limiting further distribution 1522 of the user's location to other location based services. 1524 The RADIUS server MUST behave according to the following guidelines: 1526 o The RADIUS server MUST attach available rules to the Access- 1527 Accept, the Access-Reject or the Access-Challenge message when the 1528 RADIUS client is supposed to provide location information. 1530 o When location information is made available to other entities 1531 (e.g., writing to stable storage for latter billing processing) 1532 then the RADIUS server MUST attach the privacy rules to location 1533 information. 1535 7.2.3. RADIUS Proxy 1537 A RADIUS proxy, behaving as a combined RADIUS client and RADIUS 1538 server, MUST follow the rules described in Section 7.2.1 and 1539 Section 7.2.2. 1541 7.3. Identity Information and Location Information 1543 For the envisioned usage scenarios, the identity of the user and his 1544 device is tightly coupled to the transfer of location information. 1545 If the identity can be determined by the visited network or RADIUS 1546 brokers, then it is possible to correlate location information with a 1547 particular user. As such, it allows the visited network and brokers 1548 to learn movement patterns of users. 1550 The user's identity can be "leaked" to the visited network or RADIUS 1551 brokers in a number of ways: 1553 o The user's device may employ a fixed MAC address, or base its IP 1554 address on such an address. This enables the correlation of the 1555 particular device to its different locations. Techniques exist to 1556 avoid the use of an IP address that is based on MAC address 1557 [RFC3041]. Some link layers make it possible to avoid MAC 1558 addresses or change them dynamically. 1560 o Network access authentication procedures, such as PPP CHAP 1561 [RFC1994] or EAP [RFC4282], may reveal the user's identity as a 1562 part of the authentication procedure. Techniques exist to avoid 1563 this problem in EAP methods, for instance by employing private 1564 Network Access Identifiers (NAIs) in the EAP Identity Response 1565 message [RFC4187] and by method-specific private identity exchange 1566 in the EAP method (e.g., [RFC4187], [RFC5281] 1567 [I-D.josefsson-pppext-eap-tls-eap], [RFC5106]). Support for 1568 identity privacy within CHAP is not available. 1570 o RADIUS may return information from the home network to the visited 1571 in a manner that makes it possible to either identify the user or 1572 at least correlate his session with other sessions, such as the 1573 use of static data in a Class Attribute [RFC2865] or in some 1574 accounting attribute usage scenarios [RFC4372]. 1576 o Mobility protocols may reveal some long-term identifier, such as a 1577 home address. 1579 o Application layer protocols may reveal other permanent 1580 identifiers. 1582 To prevent the correlation of identities with location information it 1583 is necessary to prevent leakage of identity information from all 1584 sources, not just one. 1586 Unfortunately, most users are not educated about the importance of 1587 identity confidentiality and some protocols lack support for identity 1588 privacy mechanisms. This problem is made worse by the fact that 1589 users may be unable to choose particular protocols, as the choice is 1590 often dictated by the type of network operator they use, by the type 1591 of network they wish to access, the kind of equipment they have, or 1592 the type of authentication method they are using. 1594 A scenario where the user is attached to the home network is, from a 1595 privacy point of view, simpler than a scenario where a user roams 1596 into a visited network since the NAS and the home RADIUS server are 1597 in the same administrative domain. No direct relationship between 1598 the visited and the home network operator may be available and some 1599 RADIUS brokers need to be consulted. With subscription-based network 1600 access as used today the user has a contractual relationship with the 1601 home network provider that could (theoretically) allow higher privacy 1602 considerations to be applied (including policy rules stored at the 1603 home network itself for the purpose of restricting further 1604 distribution). 1606 In many cases it is necessary to secure the transport of location 1607 information along the RADIUS infrastructure. Mechanisms to achieve 1608 this functionality are discussed in Section 7.1. 1610 8. IANA Considerations 1612 The authors request that the Attribute Types, and Attribute Values 1613 defined in this document be registered by the Internet Assigned 1614 Numbers Authority (IANA) from the RADIUS name spaces as described in 1615 the "IANA Considerations" section of RFC 3575 [RFC3575], in 1616 accordance with BCP 26 [RFC2434]. Additionally, the Attribute Type 1617 should be registered in the Diameter name space. For RADIUS 1618 attributes and registries created by this document IANA is requested 1619 to place them at http://www.iana.org/assignments/radius-types. 1621 This document defines the following attributes: 1623 Operator-Name 1624 Location-Information 1625 Location-Data 1626 Basic-Location-Policy-Rules 1627 Extended-Location-Policy-Rules 1628 Location-Capable 1629 Requested-Location-Info 1631 Please refer to Section 5 for the registered list of numbers. 1633 This document also instructs IANA to assign a new value for the 1634 Error-Cause Attribute [RFC5176], of "Location-Info-Required". 1636 Additionally, IANA is requested to create the following new 1637 registries listed in the subsections below. 1639 8.1. New Registry: Operator Namespace Identifier 1641 This document also defines an operator namespace identifier registry 1642 (used in the Namespace ID field of the Operator-Name Attribute). 1643 Note that this document requests IANA only to maintain a registry of 1644 existing namespaces for use in this identifier field, and not to 1645 establish any namespaces nor to place any values within namespaces. 1647 IANA is requested to add the following values to the operator 1648 namespace identifier registry using a numerical identifier (allocated 1649 in sequence), a token for the operator namespace and a contact person 1650 for the registry. 1652 +----------+--------------------+------------------------------------+ 1653 |Identifier| Operator Namespace | Contact Person | 1654 | | Token | | 1655 +----------+--------------------+------------------------------------+ 1656 | 0x30 | TADIG | TD.13 Coordinator | 1657 | | | (td13@gsm.org) | 1658 | 0x31 | REALM | IETF O&M Area Directors | 1659 | | | (ops-ads@ietf.org) | 1660 | 0x32 | E212 | ITU Director | 1661 | | | (tsbdir@itu.int) | 1662 | 0x33 | ICC | ITU Director | 1663 | | | (tsbdir@itu.int) | 1664 +----------+--------------------+------------------------------------+ 1666 Note that the above identifier values represent the ASCII value '0' 1667 (decimal 48 or hex 0x30), '1' (decimal 49, or hex 0x31), '2' (decimal 1668 50, or hex 0x32) and '3' (decimal 51, or hex 0x33). This encoding 1669 was chosen to simplify parsing. 1671 Requests to IANA for a new value for a Namespace ID, i.e., values 1672 from 0x34 to 0xFE, will be approved by Expert Review. A designated 1673 expert will be appointed by the IESG. 1675 The Expert Reviewer should ensure that a new entry is indeed required 1676 or could fit within an existing database, e.g., whether there is a 1677 real requirement to provide a token for an Namespace ID because one 1678 is already up and running, or whether the REALM identifier plus the 1679 name should recommended to the requester. In addition, the Expert 1680 Reviewer should ascertain to some reasonable degree of diligence that 1681 a new entry is a correct reference to an Operator Namespace, when a 1682 new one is registered. 1684 8.2. New Registry: Location Profiles 1686 Section 4.2 defines the Location-Information Attribute and a Code 1687 field that contains 8 bit integer value. Two values, zero and one, 1688 are defined in this document, namely: 1690 Value (0): Civic location profile described in Section 4.3.1 1692 Value (1): Geospatial location profile described in Section 4.3.2 1694 The remaining values are reserved for future use. 1696 Following the policies outline in [RFC3575] the available bits with a 1697 description of their semantic will be assigned after the expert 1698 review process. Updates can be provided based on expert approval 1699 only. Based on expert approval it is possible to mark entries as 1700 "deprecated". A designated expert will be appointed by the IESG. 1702 Each registration must include the value and the corresponding 1703 semantic of the defined location profile. 1705 8.3. New Registry: Location-Capable Attribute 1707 Section 4.6 defines the Location-Capable Attribute that contains a 1708 bit map. 32 bits are available whereby a 5 bits are defined by this 1709 document. This document creates a new IANA registry for the 1710 Requested-Location-Info Attribute. IANA is requested to add the 1711 following values to this registry: 1713 +----------+----------------------+ 1714 | Value | Capability Token | 1715 +----------+----------------------+ 1716 | 1 | CIVIC_LOCATION | 1717 | 2 | GEO_LOCATION | 1718 | 4 | USERS_LOCATION | 1719 | 8 | NAS_LOCATION | 1720 +----------+----------------------+ 1722 Following the policies outline in [RFC3575] the available bits with a 1723 description of their semantic will be assigned after the expert 1724 review process. Updates can be provided based on expert approval 1725 only. Based on expert approval it is possible to mark entries as 1726 "deprecated". A designated expert will be appointed by the IESG. 1728 Each registration must include: 1730 Name: 1732 Capability Token (i.e., an identifier of the capability) 1734 Description: 1736 Brief description indicating the meaning of the info element. 1738 Numerical Value: 1740 A numerical value that is placed into the Capability Attribute 1741 representing a bit in the bit-string of the Requested-Location- 1742 Info Attribute. 1744 8.4. New Registry: Entity Types 1746 Section 4.2 defines the Location-Information Attribute that contains 1747 an 8 bit Entity field. Two values are registered by this document, 1748 namely: 1750 Value (0) describes the location of the user's client device 1752 Value (1) describes the location of the RADIUS client 1754 All other values are reserved for future use. 1756 Following the policies outline in [RFC3575] the available bits with a 1757 description of their semantic will be assigned after the expert 1758 review process. Updates can be provided based on expert approval 1759 only. Based on expert approval it is possible to mark entries as 1760 "deprecated". A designated expert will be appointed by the IESG. 1762 Each registration must include the value and a corresponding 1763 description. 1765 8.5. New Registry: Privacy Flags 1767 Section 4.4 defines the Basic-Location-Policy-Rules Attribute that 1768 contains flags indicating privacy settings. 16 bits are available 1769 whereby a single bit, bit (0), indicating 'retransmission allowed' is 1770 defined by this document. Bits 1-15 are reserved for future use. 1772 Following the policies outline in [RFC3575] the available bits with a 1773 description of their semantic will be assigned after the expert 1774 review process. Updates can be provided based on expert approval 1775 only. Based on expert approval it is possible to mark entries as 1776 "deprecated". A designated expert will be appointed by the IESG. 1778 Each registration must include the bit position and the semantic of 1779 the bit. 1781 8.6. New Registry: Requested-Location-Info Attribute 1783 Section 4.7 defines the Requested-Location-Info Attribute that 1784 contains a bit map. 32 bits are available whereby a 5 bits are 1785 defined by this document. This document creates a new IANA registry 1786 for the Requested-Location-Info Attribute. IANA is requested to add 1787 the following values to this registry: 1789 +----------+----------------------+ 1790 | Value | Capability Token | 1791 +----------+----------------------+ 1792 | 1 | CIVIC_LOCATION | 1793 | 2 | GEO_LOCATION | 1794 | 4 | USERS_LOCATION | 1795 | 8 | NAS_LOCATION | 1796 | 16 | FUTURE_REQUESTS | 1797 | 32 | NONE | 1798 +----------+----------------------+ 1800 The semantic of these values is defined in Section 4.7. 1802 Following the policies outline in [RFC3575] new Capability Tokens 1803 with a description of their semantic for usage with the Requested- 1804 Location-Info Attribute will be assigned after the expert review 1805 process. Updates can be provided based on expert approval only. 1806 Based on expert approval it is possible to mark entries as 1807 "deprecated". A designated expert will be appointed by the IESG. 1809 Each registration must include: 1811 Name: 1813 Capability Token (i.e., an identifier of the capability) 1815 Description: 1817 Brief description indicating the meaning of the info element. 1819 Numerical Value: 1821 A numerical value that is placed into the Capability Attribute 1822 representing a bit in the bit-string of the Requested-Location- 1823 Info Attribute. 1825 9. Acknowledgments 1827 The authors would like to thank the following people for their help 1828 with an initial version of this draft and for their input: Chuck 1829 Black, Paul Congdon, Jouni Korhonen, Sami Ala-luukko, Farooq Bari, Ed 1830 Van Horne, Mark Grayson, Jukka Tuomi, Jorge Cuellar, and Christian 1831 Guenther. 1833 Henning Schulzrinne provided the civic location information content 1834 found in this draft. The geospatial location information format is 1835 based on work done by James Polk, John Schnizlein and Marc Linsner. 1836 The authorization policy format is based on the work done by Jon 1837 Peterson. 1839 The authors would like to thank Victor Lortz, Anthony Leibovitz, Jose 1840 Puthenkulam, Bernrad Aboba, Jari Arkko, Parviz Yegani, Serge Manning, 1841 Kuntal Chowdury, Pasi Eronen, Blair Bullock and Eugene Chang for 1842 their feedback to an initial version of this draft. We would like to 1843 thank Jari Arkko for his text contributions. Lionel Morand provided 1844 detailed feedback on numerous issues. His comments helped to improve 1845 the quality of this document. Jouni Korhonen, Victor Fajardo, Tolga 1846 Asveren and John Loughney helped us with the Diameter RADIUS 1847 interoperability section. Andreas Pashalidis reviewed a later 1848 version document and provided a number of comments. Alan DeKok, 1849 Lionel Morand, Jouni Korhonen, David Nelson and Emile van Bergen 1850 provided guidance on the Requested-Location-Info Attribute and 1851 participated in the capability exchange discussions. Allison Mankin, 1852 Jouni Korhonen and Pasi Eronen provided text for the operator 1853 namespace identifier registry. Jouni Korhonen interacted with the 1854 GSMA to find a contact person for the TADIG operator namespace and 1855 Scott Bradner consulted the ITU-T to find a contact person for the 1856 E212 and the ICC operator namespace. 1858 This document is based on the discussions within the IETF GEOPRIV 1859 working group. Therefore, the authors thank Henning Schulzrinne, 1860 James Polk, John Morris, Allison Mankin, Randall Gellens, Andrew 1861 Newton, Ted Hardie, Jon Peterson for their time to discuss a number 1862 of issues with us. We thank Stephen Hayes for aligning this work 1863 with 3GPP activities. 1865 We would like to thank members of the Wimax Forum Global Roaming 1866 Working Group (GRWG) for their feedback on the Operator-Name 1867 attribute. Ray Jong Kiem helped us with his detailed description to 1868 correct the document. 1870 The RADEXT working group chairs, David Nelson and Bernard Aboba, 1871 provided several draft reviews and we would like to thank them for 1872 the help and their patience. 1874 Finally, we would like to thank Dan Romascanu, Glen Zorn, Russ 1875 Housley, Jari Arkko, Ralph Droms, Adrial Farrel, Tim Polk, and Lars 1876 Eggert for the IETF Last Call comments, Derek Atkins for his security 1877 area directorate review and Yoshiko Chong for spotting a bug in the 1878 IANA consideration section. 1880 10. References 1882 10.1. Normative References 1884 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1885 Requirement Levels", BCP 14, RFC 2119, March 1997. 1887 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1888 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1889 October 1998. 1891 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1892 "Remote Authentication Dial In User Service (RADIUS)", 1893 RFC 2865, June 2000. 1895 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 1896 for Internationalized Domain Names in Applications 1897 (IDNA)", RFC 3492, March 2003. 1899 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1900 Authentication Dial In User Service)", RFC 3575, 1901 July 2003. 1903 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1904 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1906 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 1907 Configuration Protocol Option for Coordinate-based 1908 Location Configuration Information", RFC 3825, July 2004. 1910 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 1911 (DHCPv4 and DHCPv6) Option for Civic Addresses 1912 Configuration Information", RFC 4776, November 2006. 1914 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 1915 Aboba, "Dynamic Authorization Extensions to Remote 1916 Authentication Dial In User Service (RADIUS)", RFC 5176, 1917 January 2008. 1919 10.2. Informative References 1921 [GMLv3] "Open Geography Markup Language (GML) Implementation 1922 Specification", OGC 02-023r4, 1923 http://www.opengis.org/techno/implementation.htm", , 1924 January 2003. 1926 [GSM] "TADIG Naming Conventions, Version 4.1", GSM Association 1927 Official Document TD.13", , June 2006. 1929 [I-D.ietf-geopriv-policy] 1930 Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 1931 and J. Polk, "Geolocation Policy: A Document Format for 1932 Expressing Privacy Preferences for Location Information", 1933 draft-ietf-geopriv-policy-20 (work in progress), 1934 February 2009. 1936 [I-D.josefsson-pppext-eap-tls-eap] 1937 Josefsson, S., Palekar, A., Simon, D., and G. Zorn, 1938 "Protected EAP Protocol (PEAP) Version 2", 1939 draft-josefsson-pppext-eap-tls-eap-10 (work in progress), 1940 October 2004. 1942 [ISO] "Codes for the representation of names of countries and 1943 their subdivisions - Part 1: Country codes, ISO 3166-1", 1944 , 1997. 1946 [ITU1400] "Designations for interconnections among operators' 1947 networks, ITU-T Recommendation M.1400", , January 2004. 1949 [ITU212] "The international identification plan for mobile 1950 terminals and mobile users, ITU-T Recommendation E.212", 1951 , May 2004. 1953 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 1954 Specification, Implementation", RFC 1305, March 1992. 1956 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 1957 Protocol (CHAP)", RFC 1994, August 1996. 1959 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1961 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 1962 Stateless Address Autoconfiguration in IPv6", RFC 3041, 1963 January 2001. 1965 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1966 Dial In User Service) Support For Extensible 1967 Authentication Protocol (EAP)", RFC 3579, September 2003. 1969 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, D., and 1970 D. Polk, "Geopriv Requirements", RFC 3693, February 2004. 1972 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 1973 "Diameter Network Access Server Application", RFC 4005, 1974 August 2005. 1976 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1977 Authentication Protocol (EAP) Method Requirements for 1978 Wireless LANs", RFC 4017, March 2005. 1980 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 1981 Authentication Protocol (EAP) Application", RFC 4072, 1982 August 2005. 1984 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 1985 Format", RFC 4119, December 2005. 1987 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 1988 Protocol Method for 3rd Generation Authentication and Key 1989 Agreement (EAP-AKA)", RFC 4187, January 2006. 1991 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1992 Network Access Identifier", RFC 4282, December 2005. 1994 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1995 RFC 4306, December 2005. 1997 [RFC4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, 1998 "Chargeable User Identity", RFC 4372, January 2006. 2000 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 2001 Polk, J., and J. Rosenberg, "Common Policy: A Document 2002 Format for Expressing Privacy Preferences", RFC 4745, 2003 February 2007. 2005 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 2006 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 2008 [RFC5106] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., 2009 and F. Bersani, "The Extensible Authentication Protocol- 2010 Internet Key Exchange Protocol version 2 (EAP-IKEv2) 2011 Method", RFC 5106, February 2008. 2013 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 2014 Protocol Tunneled Transport Layer Security Authenticated 2015 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. 2017 Appendix A. Matching with Geopriv Requirements 2019 This section compares the requirements for a GEOPRIV Using Protocol, 2020 described in [RFC3693], against the approach of distributing Location 2021 Objects with RADIUS. 2023 In Appendix A.1 and Appendix A.2 we discuss privacy implications when 2024 RADIUS entities make location information available to other parties. 2025 In Appendix A.3 the requirements are matched against these two 2026 scenarios. 2028 A.1. Distribution of Location Information at the User's Home Network 2030 When location information is conveyed from the RADIUS client to the 2031 RADIUS server then it might subsequently be made available for 2032 different purposes. This section discusses the privacy implication 2033 for making location information available to other entities. 2035 To use a more generic scenario we assume that the visited RADIUS and 2036 the home RADIUS server belong to different administrative domains. 2037 The Location Recipient obtains location information about a 2038 particular Target via protocols specified outside the scope of this 2039 document (e.g., SIP, HTTP or an API). 2041 The subsequent figure shows the interacting entities graphically. 2043 visited network | home network 2044 | 2045 | +----------+ 2046 | | Rule | 2047 | | Holder | 2048 | +----+-----+ 2049 | | 2050 | rule|interface 2051 +----------+ | V +----------+ 2052 |Location | | +----------+ notification |Location | 2053 |Generator | | |Location |<------------->|Recipient | 2054 +----------+ publication |Server | interface | | 2055 |RADIUS |<------------->+----------+ +----------+ 2056 |Client | interface |RADIUS | E.g., SIP/HTTP 2057 +----------+ | |Server | 2058 | +----------+ 2059 E.g., NAS RADIUS 2060 | 2061 | 2063 Figure 8: Location Server at the Home Network 2065 The term 'Rule Holder' in Figure 8 denotes the entity that creates 2066 the authorization rule set. 2068 A.2. Distribution of Location Information at the Visited Network 2070 This section describes a scenario where location information made 2071 available to Location Recipients by a Location Server in the visited 2072 network. Some identifier needs to be used as an index within the 2073 location database. One possible identifier is the Network Access 2074 Identifier. RFC 4282 [RFC4282] and RFC 4372 [RFC4372] provide 2075 background whether entities in the visited network can obtain the 2076 user's NAI in cleartext. 2078 The visited network provides location information to a Location 2079 Recipient (e.g., via SIP or HTTP). This document enables the NAS to 2080 obtain the user's privacy policy via the interaction with the RADIUS 2081 server. Otherwise only default policies, which are very restrictive, 2082 are available. This allows the Location Server in the visited 2083 network to ensure act according to the user's policies. 2085 The subsequent figure shows the interacting entities graphically. 2087 visited network | home network 2088 | 2089 +----------+ | 2090 |Location | | 2091 |Recipient | | 2092 | | | 2093 +----------+ | 2094 ^ | +----------+ 2095 | | | Rule | 2096 notification | | Holder | 2097 interface | | | 2098 | | +----+-----+ 2099 | | | 2100 | | rule|interface 2101 v | | 2102 +----------+ | | 2103 |Location | | v 2104 |Server | | +----------+ 2105 +----------+ Rule Transport|RADIUS | 2106 |RADIUS |<------------->|Server | 2107 |Client | RADIUS +----------+ 2108 +----------+ | 2109 |Location | | 2110 |Generator | 2111 +----------+ 2113 Figure 9: Location Server at the Visited Network 2115 Location information always travels with privacy policies. This 2116 document enables the RADIUS client to obtain these policies. The 2117 Location Server can subsequently act according to these policies to 2118 provide access control using the Extended-Location-Policy-Rules and 2119 to adhere the privacy statements in the Basic-Location-Policy-Rules. 2121 A.3. Requirements matching 2123 Section 7.1 of [RFC3693] details the requirements of a "Location 2124 Object". We discuss these requirements in the subsequent list. 2126 Req. 1. (Location Object generalities): 2128 * Regarding requirement 1.1, the syntax and semantic of the 2129 location object is taken from the [RFC3825] and [RFC4776]. It 2130 is furthermore possible to convert it to the format used in 2131 GMLv3 [GMLv3], as used with PIDF-LO [RFC4119]. 2133 * Regarding requirement 1.2, a number of fields in the civic 2134 location information format are optional. 2136 * Regarding requirement 1.3, the inclusion of type of place item 2137 (CAtype 29) used in the DHCP civic format gives a further 2138 classification of the location. This attribute can be seen as 2139 an extension. 2141 * Regarding requirement 1.4, this document does not define the 2142 format of the location information. 2144 * Regarding requirement 1.5, location information is only sent 2145 from the RADIUS client to the RADIUS server. 2147 * Regarding requirement 1.6, the Location Object contains both 2148 location information and privacy rules. Location information 2149 is described in Section 4.2, in Section 4.3.1 and in 2150 Section 4.3.2. The corresponding privacy rules are detailed in 2151 Section 4.4 and in Section 4.5. 2153 * Regarding requirement 1.7, the Location Object is usable in a 2154 variety of protocols. The format of the object is reused from 2155 other documents as detailed in Section 4.2, Section 4.3.1, 2156 Section 4.3.2 Section 4.4 and in Section 4.5). 2158 * Regarding requirement 1.8, the encoding of the Location Object 2159 has an emphasis on a lightweight encoding format to be used 2160 with RADIUS. 2162 Req. 2. (Location Object fields): 2164 * Regarding requirement 2.1, the Target Identifier is carried 2165 within the network access authentication protocol (e.g., within 2166 the EAP-Identity Response when EAP is used and/or within the 2167 EAP method itself). As described in Section 7.2 it has a 2168 number of advantages if this identifier is not carried in 2169 clear. This is possible with certain EAP methods whereby the 2170 identity in the EAP-Identity Response only contains information 2171 relevant for routing the response to the user's home network. 2172 The user identity is protected by the authentication and key 2173 exchange protocol. 2175 * Regarding requirement 2.2, the Location Recipient is in the 2176 main scenario the home RADIUS server. For a scenario where the 2177 Location Recipient is obtaining Location Information from the 2178 Location Server via HTTP or SIP the respective mechanisms 2179 defined in these protocols are used to identify the recipient. 2180 The Location Generator cannot, a priori, know the recipients if 2181 they are not defined in this protocol. 2183 * Regarding requirement 2.3, the credentials of the Location 2184 Recipient are known to the RADIUS entities based on the 2185 security mechanisms defined in the RADIUS protocol itself. 2186 Section 7 describes these security mechanisms offered by the 2187 RADIUS protocol. The same is true for requirement 2.4. 2189 * Regarding requirement 2.5, Section 4.2, Section 4.3.1 and 2190 Section 4.3.2 describe the content of the location fields. 2191 Since the location format itself is not defined in this 2192 document motion and direction vectors as listed in requirement 2193 2.6 are not defined. 2195 * Regarding requirement 2.6, this document provides the 2196 capability for the RADIUS server to indicate what type of 2197 location information it would like to see from the RADIUS 2198 client. 2200 * Regarding requirement 2.7, timing information is provided with 2201 'sighting time' and 'time-to-live' field defined in 2202 Section 4.2. 2204 * Regarding requirement 2.8, a reference to an external (more 2205 detailed rule set) is provided with the Extended-Location- 2206 Policy-Rules attribute Section 4.5 . 2208 * Regarding requirement 2.9, security headers and trailers are 2209 provided as part of the RADIUS protocol or even as part of 2210 IPsec. 2212 * Regarding requirement 2.10, a version number in RADIUS is 2213 provided with the IANA registration of the attributes. New 2214 attributes are assigned a new IANA number. 2216 Req. 3. (Location Data Types): 2218 * Regarding requirement 3.1, this document reuses civic and 2219 geospatial location information as described in Section 4.3.2 2220 and in Section 4.3.1. 2222 * With the support of civic and geospatial location information 2223 support requirement 3.2 is fulfilled. 2225 * Regarding requirement 3.3, the geospatial location information 2226 used by this document only refers to absolute coordinates. 2227 However, the granularity of the location information can be 2228 reduced with the help of the AltRes, LoRes, LaRes fields 2229 described in [RFC3825]. 2231 * Regarding requirement 3.4, further Location Data Types can be 2232 added via new coordinate reference systems (CRSs) (see Datum 2233 field in [RFC3825]) and via extensions to [RFC3825] and 2234 [RFC4776]. 2236 Section 7.2 of [RFC3693] details the requirements of a "Using 2237 Protocol". These requirements are listed below: 2239 Req. 4.: The using protocol has to obey the privacy and security 2240 instructions coded in the Location Object regarding the 2241 transmission and storage of the LO. This document requires that 2242 entities that aim to make location information available to third 2243 parties are required to obey the privacy instructions. 2245 Req. 5.: The using protocol will typically facilitate that the keys 2246 associated with the credentials are transported to the respective 2247 parties, that is, key establishment is the responsibility of the 2248 using protocol. Section 7 specifies how security mechanisms are 2249 used in RADIUS and how they can be reused to provide security 2250 protection for the Location Object. Additionally, the privacy 2251 considerations (see Section 7.2) are also relevant for this 2252 requirement. 2254 Req. 6. (Single Message Transfer): In particular, for tracking of 2255 small target devices, the design should allow a single message/ 2256 packet transmission of location as a complete transaction. The 2257 encoding of the Location Object is specifically tailored towards 2258 the inclusion into a single message that even respects the (Path) 2259 MTU size. 2261 Section 7.3 of [RFC3693] details the requirements of a "Rule based 2262 Location Data Transfer". These requirements are listed below: 2264 Req. 7. (LS Rules): With the scenario shown in Figure 8 the 2265 decision of a Location Server to provide a Location Recipient 2266 access to location information is based on Rule Maker-defined 2267 Privacy Rules that are stored at the home network. With regard to 2268 the scenario shown in Figure 9 the Rule Maker-defined Privacy 2269 Rules are sent from the RADIUS server to the NAS (see Section 4.4, 2270 Section 4.5 and Section 7.2 for more details). 2272 Req. 8. (LG Rules): For all usage scenario it is possible to 2273 consider the privacy rule before transmitting location information 2274 from the NAS to the RADIUS server or even to third parties. In 2275 the case of an out-of-band agreement between the owner of the NAS 2276 and the owner of the RADIUS server privacy might be applied on a 2277 higher granularity. For the scenario shown in Figure 8 the 2278 visited network is already in possession of the users location 2279 information prior to the authentication and authorization of the 2280 user. A correlation between the location and the user identity 2281 might, however, still not be possible for the visited network (as 2282 explained in Section 7.2). A Location Server in the visited 2283 network has to evaluate available rulesets. 2285 Req. 9. (Viewer Rules): The Rule Maker might define (via mechanisms 2286 outside the scope of this document) which policy rules are 2287 disclosed to other entities. 2289 Req. 10. (Full Rule language): Geopriv has defined a rule language 2290 capable of expressing a wide range of privacy rules which is 2291 applicable in the area of the distribution of Location Objects. A 2292 basic ruleset is provided with the Basic-Location-Policy-Rules 2293 Attribute Section 4.4. A reference to the extended ruleset is 2294 carried in Section 4.5. The format of these rules are described 2295 in [RFC4745] and [I-D.ietf-geopriv-policy]. 2297 Req. 11. (Limited Rule language): A limited (or basic) ruleset is 2298 provided by the Policy-Information Attribute Section 4.4 (and as 2299 introduced with PIDF-LO [RFC4119]). 2301 Section 7.4 of [RFC3693] details the requirements of a "Location 2302 Object Privacy and Security". These requirements are listed below: 2304 Req. 12 (Identity Protection): Support for unlinkable pseudonyms is 2305 provided by the usage of a corresponding authentication and key 2306 exchange protocol. Such protocols are available, for example, 2307 with the support of EAP as network access authentication methods. 2308 Some EAP methods support passive user identity confidentiality 2309 whereas others even support active user identity confidentiality. 2310 This issue is further discussed in Section 7. The importance for 2311 user identity confidentiality and identity protection has already 2312 been recognized as an important property (see, for example, a 2313 document on 'EAP Method Requirements for Wireless LANs' 2314 [RFC4017]). 2316 Req. 13. (Credential Requirements): As described in Section 7 2317 RADIUS signaling messages can be protected with IPsec. This 2318 allows a number of authentication and key exchange protocols to be 2319 used as part of IKE, IKEv2 or KINK. 2321 Req. 14. (Security Features): Geopriv defines a few security 2322 requirements for the protection of Location Objects, such as 2323 mutual end-point authentication, data object integrity, data 2324 object confidentiality and replay protection. As described in 2325 Section 7 these requirements are fulfilled with the usage of IPsec 2326 if mutual authentication refers to the RADIUS entities (acting as 2327 various Geopriv entities) which directly communicate with each 2328 other. 2330 Req. 15. (Minimal Crypto): A minimum of security mechanisms are 2331 mandated by the usage of RADIUS. Communication security for 2332 Location Objects between RADIUS infrastructure elements is 2333 provided by the RADIUS protocol (including IPsec and its dynamic 2334 key management framework) rather than on relying on object 2335 security via S/SIME (which is not available with RADIUS). 2337 Authors' Addresses 2339 Hannes Tschofenig (editor) 2340 Nokia Siemens Networks 2341 Linnoitustie 6 2342 Espoo 02600 2343 Finland 2345 Phone: +358 (50) 4871445 2346 Email: Hannes.Tschofenig@gmx.net 2347 URI: http://www.tschofenig.priv.at 2349 Farid Adrangi 2350 Intel Corporatation 2351 2111 N.E. 25th Avenue 2352 Hillsboro OR 2353 USA 2355 Email: farid.adrangi@intel.com 2357 Mark Jones 2358 Bridgewater Systems Corporation 2359 303 Terry Fox Drive 2360 Ottawa, Ontario K2K 3J1 2361 CANADA 2363 Email: mark.jones@bridgewatersystems.com 2365 Avi Lior 2366 Bridgewater Systems Corporation 2367 303 Terry Fox Drive 2368 Ottawa, Ontario K2K 3J1 2369 CANADA 2371 Email: avi@bridgewatersystems.com 2373 Bernard Aboba 2374 Microsoft Corporation 2375 One Microsoft Way 2376 Redmond, WA 98052 2377 US 2379 Email: bernarda@microsoft.com