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