From aaa-doctors-bounces@ietf.org Fri Feb 02 04:08:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCuPc-0001eP-3L; Fri, 02 Feb 2007 04:08:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCuPa-0001dw-H5; Fri, 02 Feb 2007 04:08:50 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCuPX-0005yU-I1; Fri, 02 Feb 2007 04:08:50 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l1298j6b013119; Fri, 2 Feb 2007 04:08:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Feb 2007 11:08:44 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for February 8, 2007 Telechat Thread-Index: AcdGZKVRWCov5TIGQha8nSCvM1WA1AAQ9C3g From: "Romascanu, Dan \(Dan\)" To: "MIB Doctors \(E-mail\)" , , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: Subject: [AAA-DOCTORS] FW: PRELIMINARY Agenda and Package for February 8, 2007 Telechat X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: aaa-doctors-bounces@ietf.org Please see below for documents on the agenda for next IESG telechat. I = would appreciate if you can send me your issues and comments by = Wednesday February 7, 2007, COB.=20 Dan=20 ---------------------=20 =20 =20 =20 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item o draft-ietf-isis-admin-tags-03.txt A Policy Control Mechanism is IS-IS Using Administrative Tags (Proposed=20 Standard) - 1 of 8=20 Token: Bill Fenner o draft-ietf-ospf-cap-09.txt Extensions to OSPF for Advertising Optional Router Capabilities (Proposed=20 Standard) - 2 of 8=20 Note: The PROTO shepherd is Rohit Dube =20 Token: Bill Fenner o draft-ietf-isis-caps-06.txt IS-IS Extensions for Advertising Router Information (Proposed Standard) - 3=20 of 8=20 Token: Bill Fenner o draft-ietf-tsvwg-rsvp-ipsec-04.txt Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations=20 (Proposed Standard) - 4 of 8=20 Note: Shepherd is James Polk (jmpolk@cisco.com)=20 Token: Magnus Westerlund o draft-ietf-l2tpext-failover-11.txt Fail Over extensions for L2TP "failover" (Proposed Standard) - 5 of = 8 Note: Final version is draft-ietf-l2tpext-failover-12.txt, which contains=20 small edits and was submitted on 1/30/07=20 Token: Mark Townsley o draft-ietf-lemonade-deployments-04.txt Deployment Considerations for lemonade-compliant Mobile Email (BCP) = - 6 of=20 8=20 Token: Ted Hardie o draft-ietf-mip4-mobike-connectivity-02.txt Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE (BCP) = - 7 of=20 8=20 Note: Document Shepherd is =20 Token: Jari Arkko o draft-ietf-mip4-message-string-ext-02.txt Mobile IPv4 Message String Extension (Proposed Standard) - 8 of 8=20 Note: Document Shepherd is =20 Token: Jari Arkko 2.1.2 Returning Item o draft-ietf-ipv6-2461bis-10.txt Neighbor Discovery for IP version 6 (IPv6) (Draft Standard) - 1 of 3 = Note: Brian Haberman is the Document shepherd. NOTE: Tentatively put on the agenda. Still need to check = if =20 everything was actually revised correctly=20 Token: Jari Arkko o draft-ietf-idr-rfc3065bis-05.txt Autonomous System Confederations for BGP (Draft Standard) - 2 of 3=20 Note: Note that -06 has been submitted to address WGLC comments.=A0 If=20 it has not yet appeared in the draft directories, a copy is at=20 http://rtg.ietf.org/~fenner/tmp/draft-ietf-idr-rfc3065bis-06.txt .=20 Token: Bill Fenner o draft-ietf-pim-mib-v2-09.txt Protocol Independent Multicast MIB (Proposed Standard) - 3 of 3=20 Note: Re-issued Last Call for downref to PIM-DM.=A0 Revised Last Call=20 expires Feb 8.=20 Token: Bill Fenner 2.2 Individual Submissions 2.2.1 New Item o draft-kelly-ipsec-ciph-sha2-01.txt Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 With IPsec (Proposed=20 Standard) - 1 of 1=20 Token: Russ Housley _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Fri Feb 16 05:34:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI0Pl-0008WD-PI; Fri, 16 Feb 2007 05:34:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI0Pl-0008Ub-36; Fri, 16 Feb 2007 05:34:05 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI0Pj-0004HG-Oq; Fri, 16 Feb 2007 05:34:05 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l1GAXwIp007932; Fri, 16 Feb 2007 05:33:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Feb 2007 12:33:56 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for February 22, 2007 Telechat Thread-Index: AcdRdbb80yqwQ707SrOaeVMW4y6vLAAPyS3w From: "Romascanu, Dan \(Dan\)" To: "MIB Doctors \(E-mail\)" , , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: Subject: [AAA-DOCTORS] FW: PRELIMINARY Agenda and Package for February 22, 2007 Telechat X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: aaa-doctors-bounces@ietf.org Please find below the documents brought for approval at the IESG telechat on 2/22. Please let me know if there are any issues or concerns until 2/21 COB the latest.=20 Thanks and Regards, Dan =20 =20 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item o draft-ietf-iptel-tgrep-08.txt A Telephony Gateway REgistration Protocol (TGREP) (Proposed Standard) - 1=20 of 7=20 Note: Proto shepherd in Jonathan Rosenberg=20 Token: Cullen Jennings o draft-ietf-pim-bidir-08.txt Bi-directional Protocol Independent Multicast (BIDIR-PIM) (Proposed=20 Standard) - 2 of 7=20 Token: Bill Fenner o draft-ietf-tsvwg-sctp-auth-07.txt Authenticated Chunks for Stream Control Transmission Protocol (SCTP) (Proposed Standard) - 3 of 7=20 Token: Magnus Westerlund o draft-ietf-l2tpext-failover-11.txt Fail Over extensions for L2TP "failover" (Proposed Standard) - 4 of 7 Token: Mark Townsley o draft-ietf-pwe3-wildcard-pw-type-02.txt Wildcard Pseudowire Type (Proposed Standard) - 5 of 7=20 Token: Mark Townsley o draft-ietf-lemonade-deployments-05.txt Deployment Considerations for lemonade-compliant Mobile Email (BCP) - 6 of=20 7=20 Token: Ted Hardie o draft-ietf-smime-cms-mult-sign-03.txt Cryptographic Message Syntax (CMS) Multiple Signer Clarification (Proposed=20 Standard) - 7 of 7=20 Token: Sam Hartman 2.1.2 Returning Item o draft-ietf-mipshop-cga-cba-03.txt Enhanced Route Optimization for Mobile IPv6 (Proposed Standard) - 1 of 1=20 Token: Mark Townsley 2.2 Individual Submissions 2.2.1 New Item o Five-document ballot: - 1 of 2 - draft-legg-xed-rxer-07.txt Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One (ASN.1) (Proposed Standard)=20 - draft-legg-xed-rxer-ei-04.txt Encoding Instructions for the Robust XML Encoding Rules (RXER) (Proposed=20 Standard)=20 - draft-legg-xed-asd-07.txt Abstract Syntax Notation X (ASN.X) (Proposed Standard)=20 - draft-legg-xed-asd-gserei-03.txt Abstract Syntax Notation X (ASN.X) Representation of Encoding=20 Instructions for the Generic String Encoding Rules (GSER) (Proposed =20 Standard)=20 - draft-legg-xed-asd-xerei-03.txt Abstract Syntax Notation X (ASN.X) Representation of Encoding=20 Instructions for the XML Encoding Rules (XER) (Proposed Standard) Token: Ted Hardie o draft-heard-rfc4181-update-00.txt RFC 4181 Update to Recognize the IETF Trust (BCP) - 2 of 2=20 Token: Dan Romascanu 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-mip6-dsmip-problem-03.txt Problem Statement: Dual Stack Mobility (Informational) - 1 of 1=20 Note: PROTO shepherd is Basavaraj Patil .=20 NOTE: There are significant RFC Editor notes!=20 Token: Jari Arkko 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item o draft-kalin-geant-urn-namespace-01.txt A URN Namespace for GEANT (Informational) - 1 of 3=20 Note: Sent to URN-NID list for review in November of 2006=20 Token: Ted Hardie o draft-saintandre-xmpp-urn-02.txt A Uniform Resource Name (URN) Namespace for Extensions to the Extensible=20 Messaging and Presence Protocol (XMPP) (Informational) - 2 of 3=20 Note: Sent to URN-NID list in November of 2006=20 Token: Ted Hardie o draft-rissen-bbc-urn-00.txt A Uniform Resource Name (URN) Formal Namespace for the British Broadcasting=20 Corporation (Informational) - 3 of 3=20 Note: Sent to the URN-NID list in mid January.=20 Token: Ted Hardie 3.2.2 Returning Item NONE 3.3 Independent Submissions Via RFC Editor The IESG will use RFC 3932 responses: 1) The IESG has not found any conflict between this document and IETF work; 2) The IESG thinks that this work is related to IETF work done in WG , but this does not prevent publishing; 3) The IESG thinks that publication is harmful to work in WG and recommends not publishing at this time; 4) The IESG thinks that this document violates the IETF procedures for and should therefore not be published without IETF review and IESG approval; 5) The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. =20 =20 Other matters may be recorded in comments to be passed on to the RFC Editor as community review of the document. 3.3.1 New Item o draft-nagami-mip6-nemo-multihome-fixed-network-03.txt Multi-homing for small scale fixed network Using Mobile IP and NEMO=20 (Experimental) - 1 of 1=20 Token: Jari Arkko 3.3.2 Returning Item NONE 3.3.3 For Action o draft-joslin-config-schema-17.txt A Configuration Profile Schema for LDAP-based agents (Informational) - 1 of=20 1=20 Note: Proposed for response 2, note 2 of RFC 3932=20 Token: Ted Hardie _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Sat Feb 17 19:16:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIZj3-0001j8-1Y; Sat, 17 Feb 2007 19:16:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIZj1-0001gW-Q8 for aaa-doctors@ietf.org; Sat, 17 Feb 2007 19:16:19 -0500 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIZif-0008Ve-C0 for aaa-doctors@ietf.org; Sat, 17 Feb 2007 19:16:19 -0500 Received: from c-24-16-66-58.hsd1.wa.comcast.net ([24.16.66.58] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.63) (envelope-from ) id 1HIZie-0005OE-3v for aaa-doctors@ietf.org; Sat, 17 Feb 2007 19:15:57 -0500 Received: by internaut.com (Postfix, from userid 1000) id 7E18F3A72F; Sat, 17 Feb 2007 16:15:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 5A8AE30B93 for ; Sat, 17 Feb 2007 16:15:58 -0800 (PST) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.16.66.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Sat, 17 Feb 2007 16:15:58 -0800 (PST) From: Bernard Aboba To: aaa-doctors@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ba883ba659fcd62a05a0ed0aea6f612 Subject: [AAA-DOCTORS] Review of draft-ietf-geopriv-radius-lo X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: aaa-doctors-bounces@ietf.org Review of draft-ietf-geopriv-radius-lo-10.txt Overview comments: Overall, this document includes many normative statements relating to privacy in a number of sections. As it stands, this makes it very difficult to understand exactly what privacy support will be provided in various scenarios. I would strongly urge that these statements be consolidated into a single section. In terms of RADIUS protocol usage, there are a few problems (violation of a MUST NOT provision in RFC 3576, use of non-standard RADIUS data types, inappropriate use of complex attributes) There are also a lot of editorial issues that need to be cleaned up. Given everything, this document requires substantial work before it would be suitable for publication as an RFC. Section 1 Wireless LAN (WLAN) access networks are being deployed in public places such as airports, hotels, shopping malls, and coffee shops by a diverse set of operators such as cellular network operators (GSM and CDMA), Wireless Internet Service Providers (WISPs), and fixed broadband operators. As noted later on, these attributes are not limited to use with WLAN networks, but the relationship to user location is probably stronger with WLAN or LAN access than other access types. I think you need to talk about this. When a user executes the network access authentication procedure to such a network, information about the location and ownership of this network needs to be conveyed to the user's home network to which the user has a contractual relationship. The use of the term "need" seems wrong here, since one of the goals of the document is to guard the privacy of location information, only providing it where there is "need to know". This document describes AAA attributes, which are used by a AAA client or a AAA proxy in an access network, to convey location- related information to the user's home AAA server. The use of the term "AAA" here is a bit confusing. If the attributes are applicable to both RADIUS and Diameter, this should be explicitly stated. Although the proposed attributes in this draft are intended for wireless LAN deployments, they can also be used in other types of wireless and wired networks whenever location information is required. I'd suggest this paragraph be combined with the first paragraph. Location information needs to be protected against unauthorized access and distribution to preserve the user's privacy. [10] defines requirements for a protocol-independent model for the access to geographic location information. The model includes a Location Generator (LG) that creates location information, a Location Server (LS) that authorizes access to location information, a Location Recipient (LR) that requests and receives information, and a Rule Maker (RM) that provides authorization policies to the LS which enforces access control policies on requests to location information. I would talk a bit more about the privacy model in general terms, such as what protections it is designed to provide. Section 2 Based on today's protocols we assume that the location information is provided by the access network where the end host is attached. As part of the network attachment authentication to the AAA server location information is sent from the AAA client to the AAA server. Earlier, the document refers to use by a AAA proxy. Could you say a few words about where the information originates (e.g. may originate on the NAS, or may be added a proxy). Somewhere it is also worth stating that existing RADIUS attributes may also provide location information (e.g. NAS-Identifier). The authenticated identity might refer to a user, a device or something else. Although there might often be a user associated with the authentication process (either directly or indirectly; indirectly when a binding between a device and a user exists) there is no assurance that a particular real-world entity (such as a person) triggered this process. Is the distinction between a user, device or machine identity relevant for the purposes of a privacy discussion? This paragraph leaves me wondering whether there is a legal distinction that is relevant to the protocol design. Since location based authorization is executed based on the network access authentication of a particular "user" it might be reasonable to talk about user's privacy within this document even though scenarios exist where this might not apply (and device or network privacy might be the better term). Maybe you need to define the term "user" in the document as being either a user, device or machine identity in order to clarify this. Furthermore, the authors believe that there is a relationship between the NAS (or other nodes in the access network) and the location of the entity that triggered the network access authentication, such as the user. Why? If the NAS is a VPN server, then the user might be located halfway around the world. Might make more sense to say "depending on the type of access being provided, there may be a close relationship...." You might give examples: 1) WLAN has limited range when deployed with an omni-directional antenna, so user is probably close to the NAS in geospatial (but not necessarily civil) terms. Also, some WLAN access points can use "time of arrival" or other processing techniques to determine user location accurately; 2) In LAN access, the user can't be further away from the switch than cable length will permit. 3) Dialup or VPN user could be very far away from the NAS; If you talk about this a bit, it might help clarify why the document is mostly for WLAN/LAN access. The NAS might in many cases know the location of the end host through various techniques (e.g., wire databases, wireless triangulation). Knowing the location of a network (where the user or end host is attached) might in many networks also reveal enough information about the location of the user or the end host. A similar assumption is also made with regard to the location information obtained via DHCP (see for example [4]). The DHCP case might be analagous to WLAN/LAN, but it is not analagous to the case of VPN or dialup access where the NAS and user could be separated by thousands of miles. This information might be used by applications in other protocols (such as SIP [11] with extensions [12]) to indicate the location of a particular user even though the location "only" refers to the location of the network or equipment within the network. This assumption might not hold in all scenarios but seems to be reasonable and practicable. I think you need to say that the assumption can be presumed to hold for certain values of the NAS-Port-Type attribute (e.g. LAN or WLAN access). In others it may not hold. Section 3 Location Objects, which consist of location information and privacy rules, are transported via the RADIUS protocol from the AAA client to the AAA server. A few attributes are introduced for this purpose, as listed in Section 5, whereby delivery to the RADIUS server can happen during the authentication/authorization phase (described in Section 3.1), or in the mid-session using the dynamic authorization protocol framework (described in Section 3.2). This section describes messages flows for both delivery methods. To me, it makes more sense to talk about what packets the location information can be delivered in, rather than "phases". For example, location is delivered in Access-Request or Accounting-Request packets. Whether the Access-Request was triggered by dynamic authorization or a new user login is not important. Also, this paragraph seems to suggest that dynamic authorization is required to obtain mid-session location information. Since location can be provided interim accounting packets, this is not really true. Perhaps the point is that dynamic authorization allows the information to be provided on demand. Section 3.1 Figure 1 shows an example message flow for delivering location information during the network access authentication and authorization procedure. Upon a network authentication request from an access network client, the NAS submits a RADIUS Access-Request message that contains location information attributes among other required attributes. These attributes are added based on various criteria (such as local policy, business relationship with subscriber's home network provider and in case of location information also by considering privacy policies). Even though Figure 1 mentions "out of band agreement" the text doesn't elaborate on what this means. Since Figure 1 shows location information provided in an Accounting-Request, the first sentence isn't quite right. Given the privacy issues, I think you need to qualify what "location information" means in the second sentence. Do you mean that the user location is being supplied by the NAS? I think you need to say something about the default settings (e.g. location provided, or not?) Backward compatiblity issues also probably deserve some discussion here. You might say a few words about when this flow might occur (e.g. challenge-incapable NAS). Figure 1 uses the term "Network Access Client" which isn't defined in terminology or used in other RADIUS RFCs. I would change all uses of this term to "User". If the AAA server needs to obtain location information also in accounting messages then it needs to include a Requested-Info attribute to the Access-Accept to express that is desired (if privacy policy allow it) and the Network Access Server SHOULD then include location information to the RADIUS accounting messages . I think you should say something about the packets within which the location information can be delivered in Section 1. Something like: "This document enables a RADIUS server to request the delivery of location information within Access-Request packets, or additionally, within Accounting-Request packets." Section 3.2 This section is problematic since it specifies RADIUS attribute usage prohibited by RFC 3576 Section 3, which states: Where a Service-Type Attribute with value "Authorize Only" is included within a CoA-Request or Disconnect-Request, attributes representing an authorization change MUST NOT be included; only identification attributes are permitted. If the desire is to change the location information being provided (e.g. to turn on location in accounting packets, or deliver different types of location) why couldn't a CoA-Request be sent without an "Authorization-Only" Service-Type? If the desire is to request location immediately, couldn't this be encoded in the Request-Info attribute? There seem to be ways to achieve the goal without violating RFC 3576. Later on in the section, it is stated: Since location information can be sent in accounting records (including accounting interim records), RFC 3576 [5] is only needed for authorization changes. Given this, it would appear that the need to obtain location mid-session is best met by another technique, and that use of CoA-Request packets is only a corner case. Given that RFC 3576 is not widely implemented, I'd expect the accounting approach to be more applicable, at least without an explanation about why this isn't a good idea (e.g. might not need location info with each interim accounting update). Also, this section doesn't talk about when a RADIUS server can send a CoA-Request containing a Request-Info attribute. Wouldn't this be restricted to cases where the NAS has previously included a Location-Information or Challenge-Capable attribute? Section 4 I'm not clear this section should exist as a standalone entity. It might be best to delete Section 4.2 entirely and integrate Section 4.1 with Sections 1 or 2. Section 4.1 The home network operator requires location information for authorization and billing purposes. The operator may deny service if location information is not available, or it may offer limited service only. The NAS delivers location information to the home AAA server. The location of the AAA client and/or the end host is transferred from the NAS to the RADIUS server (based on a pre-established agreement or if the RADIUS server asks for it under consideration of privacy policies). The NAS and intermediaries (if any) are not allowed to use that information other than to forward it to the home network. Are the terms "NAS" and "AAA client" used interchangeably here? If so, can we primarily use one term (NAS seems best)? The NAS and intermediaries (if any) are not allowed to use that information other than to forward it to the home network. Intermediaries (e.g. AAA proxies) sometimes log Accounting-Request packets, since they may need them for billing purposes. Since billing is one of the uses of location information, I don't think you can prohibit that. Also, what does it mean for the NAS to "use" location information? Some NASes have stable storage, so they might write Accounting-Request packets to stable storage prior to delivery. Or they might retain location information in memory. Do you mean that that the NAS or proxies can't provide the location information to unauthorized parties? Or do you mean that proxies MUST respect the privacy policies they receive from the RADIUS server? The RADIUS server authenticates and authorizes the user requesting access to the network. If the user's location policies are available to the RADIUS server, the RADIUS server MUST deliver those policies in an Access Accept to the RADIUS client. This information MAY be needed if intermediaries or other elements want to act as Location Servers (see Section 4.2). If the NAS or intermediaries do not receive policies from the RADIUS server (or the end host itself) then they MUST NOT make any use of the location information other than forwarding it to the user's home network. I would name the specific attributes rather than just saying "location policies". You are essentially saying that some attributes MUST be included in an Access-Accept packet. The last sentence is somewhat more specific than just saying "allowed to use that information". Location Information may also be reported in accounting messages. Accounting messages are generated when the session starts, stops and periodically. Accounting messages may also be generated when the user roams during handoff. This information may be needed by the billing system to calculate the user's bill. For example, there may be different tariffs or tax rates applied based on the location. Unless otherwise specified by authorization rules, location information in the accounting stream MUST NOT be transmitted to third parties. Most of this paragraph probably belongs in Section 1 of the document. I'm unsure what the last sentence means. I think that the part of the last sentence from "location..." should probably be combined with the next sentence, to clarify it: Location information in the accounting stream MUST only be sent in the proxy chain to the home network (unless specified otherwise). For example, you might say "Location attributes contained within Accounting-Request packets MUST only be made available to entities on the proxy chain between the NAS and the home accounting server." Section 4.2 Location Servers are entities that receive the user's location information and transmit it to other entities. In this second scenario, Location Servers comprise also the NAS and the RADIUS server. The RADIUS servers are in the home network, in the visited network, or in broker networks. Unless explicitly authorized by the user's location policy, location information MUST NOT be transmitted to other parties outside the proxy chain between the NAS and the Home RADIUS server. Upon authentication and authorization, the home RADIUS server MUST transmit the ruleset (if available) in an Access-Accept. The RADIUS client, intermediate proxies are allowed to share location information if they received ruleset indicates that it is allowed. Is a "Location Server" somehow different from an entity eligible to receive location information as described in the previous section? I'm unclear whether this section is saying anything different from Section 4.1 with respect to handling of user location information. Section 5.1 The Operator-Name attribute SHOULD be sent in Access-Request, and Accounting-Request records where the Acc-Status-Type is set to Start, Interim, or Stop. Is this attribute only sent in these packets? If so, I would say: "MAY only be sent in Access-Request and Accounting-Request..." The Value type is restricted to use with Integers. I think that we are talking about a String here, no? Section 5.2 The Location-Information attribute SHOULD be sent in Access-Request and in Accounting-Request messages. For the Accounting-Request message the Acc-Status-Type may be set to Start, Interim or Stop. Is the intent that these attributes are only sent in Access-Request and Accounting-Request messages? If so, say "MAY only be sent in..." I think you are talking about a String type attribute, not an integer, right? The 16-bit unsigned integer value allows to associate the Location-Information attribute with Location-Info-Civic and Location-Info-Geo attributes. This is not a complete sentence. I think you need to explain that this attribute is used to provide information relating to the information included in the Location-Info-Civic and Location-Info-Geo attributes to which it refers (via the Index). You should probably also state that this attribute is largely treated as an opaque blob, like the Location-Info-Civic and Location-Info-Geo attributes to which it refers. As a result, it is not expected that RADIUS servers will need to change code to receive this attribute (although location applications would have to parse it). Section 5.3 Location-Info-Civic attribute SHOULD be sent in Access-Request and in Accounting-Request messages. For the Accounting-Request message the Acc-Status-Type may be set to Start, Interim or Stop. Change to "MAY only be sent..." if that is the intent. Please change "Value" to "String". The 16-bit unsigned integer value allows to associate the Location-Info-Civic attribute with the Location-Information attributes. Is there an implication that multiple Location-Information attributes will have the same Index value? That doesn't make sense to me. Section 5.4 Location-Info-Geo attribute SHOULD be sent in Access-Request, and Accounting-Request records where the Acc-Status-Type is set to Start, Interim or Stop if available. Change to "MAY only be sent" if that is the intent. Change "Value" to "String" Section 5.5 Should the title be "Basic-Policy-Rules Attribute"? Policy rules control the distribution of location location information. In some environments the the AAA client might know the privacy preferences of the user based on pre-configuration or the user communicated them as part of the network attachment. This seems somewhat unlikely. Do any existing access protocols support user-provided privacy policies? Or are we talking about generic NAS privacy settings here? Basic-Policy-Rules attribute SHOULD be sent in an an Access-Request, Access-Accept, an Access-Challenge, an Access-Reject and an Accounting-Request message. I think you mean "MAY be sent in an Access-Request..." o The AAA client SHOULD NOT attach location information in the initial Access-Request message but should rather wait for the AAA server to receive a challenge for location information. I think you mean "for the AAA server to send an Access-Challenge..." I think you are instead saying that "absent NAS settings to the contrary, the default is..." This probably should be clarified. o If a roamig agreement or legal circumstances require the AAA roamig -> roaming client to transfer location information in the initial Access- Request message to the AAA server (even though user specific policies are not available to the AAA client) then the access network attaches default authorization policies. Are you saying that a Basic Policy Rules attribute MUST accompany a Location-Information, Location-Info-Geo or Location-Info-Civic attribute? The 'retransmission-allowed' flag MUST be set to '0' meaning that the location must not be shared with other parties (other than forarding them to the user's home network). Are we saying that sharing of location information is controlled by the 're-transmission-allowed' flag and that parties MUST respect the flag? This seems to contradict earlier MUST statements (which seem to imply that sharing is not permitted, regardless of the flag value). In case the home network knows the user's privacy policies then these policies SHOULD be sent from the RADIUS server to the RADIUS client in a subsequent response message and these policies will be applied to further location dissemination and in subsequent RADIUS interactions (e.g., when attaching location information to Accounting messages). What kind of response message? Do you mean Access-Challenge here or Access-Accept? Is there a reason why a RADIUS server would refuse to disclose the user's privacy policies? Should those policies ever be considered private? 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Retention Expires ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retention Expires ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retention Expires | Note Well ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Note Well ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The design of this attribute is problematic. It is different from other complex attributes in that it is sent by the RADIUS server, and the inclusion of timestamps implies that it needs to be computed dynamically, rather than treated as an opaque blob. Also, there is an implication elsewhere in the document that the retransmission bit needs to be respected by RADIUS proxies. Most existing RADIUS proxies cannot be configured to look at a specific octet in an attribute, so this will not be possible. Is there a reason that this could not be split into separate unitary attributes, say, one for Retransmission, one for Retention-Expires and another for Privacy-Policy? The "Retention Expires" attribute would a 64-bit Long Integer, the Flags would be a 32-bit integer and the Note Well would be a string. This would be much more compatible with the design of existing RADIUS servers and proxies and would enable privacy policies to be respected. Section 5.6 The Extended-Policy-Rules attribute SHOULD be sent in an Access- Request, an Access-Accept, an Access-Challenge, an Access-Reject and in an Accounting-Request message whenever location information is transmitted. Do we mean "MAY be sent" here? I think "String" should be used here instead of "Value" Why is Length >=4 (rather than 3)? Section 5.7 Why is the Challenge-Capable attribute defined if it is always set to 0? Is the presence of the attribute sufficient to indicate that the NAS is capable of being challenged so that the value is irrelevant? It would make more sense for this to be a 32-bit integer value that only has a single value defined (1) indicating that the NAS is capable of being challenged. Section 5.8 The Requested-Info attribute allows the RADIUS server to indicate whether it needs civic and/or geospatial location information of the NAS or the end host (i.e., the entities that are indicated in the Entity field of the Location-Information attribute). Can't the RADIUS server ask for both NAS and end host information? 2. If the RADIUS server does not receive the requested information in response to the Access-Challenge (including the Requested-Info attribute) then the RADIUS server responds with an Access-Reject with an Error-Cause attribute (including the "Location-Info-Required" value). Note that an Access-Reject message SHOULD only be sent if the RADIUS server MUST use location information for returning a positive access control decision. The combination of SHOULD and MUST is confusing. I think you mean to say that an Access-Reject MUST only be sent if the RADIUS server requires location information, but does not receive it, right? This is typically the case when location information is used for inclusion to the user's bill only. Rephrase to "is used only for billing". If the RADIUS server does not send a Requested-Info attribute then the RADIUS client MUST NOT attach location information to messages to the RADIUS server. The user's authorization policies, if available, MUST be consulted by the RADIUS server before requesting location information delivery from the RADIUS client. But earlier it is said that the NAS may send location information by default, correct? Or is an exception being made? Figure 11 probably belongs earlier in the document. The Requested-Info attribute MUST be sent by the RADIUS server if it wants the RADIUS client to return civic and/or geospatial information. This Requested-Info attribute MAY appear in the Access- Accept or in the Access-Challenge message. Earlier it seems to imply that the NAS could sent location information by out-of-band agreement. So do you mean to say "in the absence of an out-of-band agreement..."? Requested-Info (64 bits): This text field contains an integer value that encodes the requested information attributes. Each capability value represents a bit position. It would be clearer to just say that the Requested-Info attribute defines a bit field, where the information on CIVIC_LOCATION, GEO_LOCATION, USERS_LOCATION, and NAS_LOCATION can be requested. BTW, why is a 64-bit value required? wouldn't 32-bits do as well? Section 6 If multiple Location-Information attributes are sent then they MUST NOT contain the same information. Does this mean "must not have the same Index field?" Or does it mean that they must not be identical in all respects? Section 8.2 o The visited network is able to learn the user's identity. I think you need a reference to NAI privacy (e.g. RFC 4282 or 4372) here. Section 8.3 This section interrupts the document flow; it would better belong in an Appendix. Section 9 Two entities might act as Location Servers as shown in Section 4, in Figure 16 and in Figure 17: I think the sentence should end with a period, not a colon, right? Section 9.1 In this scenario it is difficult to obtain authorization policies from the end host (or user) immediately when the user attaches to the network. In this case we have to assume that the visited network does not allow unrestricted distribution of location information to other than the intended recipients (e.g., to third party entities). When the AAA messages traverses one or more broker networks, the broker network is bound by the same guidelines as the visited network with respect to the distribution of location information. Are you just saying that proxies need to respect the 'retransmission' bit? In practice, they won't be able to do that because their policy engines operate at the attribute, not bit level. You'll need to have an individual attribute for retransmission if you want this to work. The visited network MUST behave according to the following guidelines: o Per default only the home network is allowed to receive location information. The visited network MUST NOT distribute location information to third parties without seeing the user's privacy rule set. Are you saying that the lack of distribution is the default, absent receipt of privacy policies to the contrary? I'd suggest that this be stated earlier on. o If the RADIUS client in the visited network learns the basic rule set or a reference to the extended rule set by means outside the RADIUS protocol (e.g., provided by the end host) then it MUST include the Basic-Policy-Rules and the Extended-Policy-Rules attribute in the Access-Request message towards the home AAA server. Furthermore, the visited network MUST evaluate these rules prior to the transmission of location information either to the home network or a third party. The visited network MUST follow the guidance given with these rules. This seems quite unlikely. Is there a reference to a specification where this is proposed? o If the RADIUS client in the visited network receives the Basic- Policy-Rules attribute with Access-Accept or the Access-Challenge message then the Basic-Policy-Rules MUST be attach in subsequent RADIUS messages which contain the Location-Information attribute (such as interim accounting messages). attach -> attached You need to include this statement in the Attribute Table section 6. Doesn't it apply to all NASes, not just a visited network? o If the RADIUS client in the visited network receives the Extended- Policy-Rules attribute with Access-Accept or the Access-Challenge message then the Basic-Policy-Rules attribute MUST be attach in subsequent RADIUS messages which contain the Location-Information attribute (such as interim accounting messages). attach -> attached I think this needs to be included in the Attribute Table section 6. Doesn't it apply to all NASes, not just a Visited network? Section 10 If no authorization information is provided by the user then the visited network MUST set the authorization policies to only allow the home AAA server to use the provided location information. This seems to contradict Figure 1 which shows location information sent by out-of-band agreement without any policy attributes. It is necessary to use authorization policies to limit the unauthorized distribution of location information. The security requirements which are created based on [10] are inline with threats which appear in the relationship with disclosure of location information as described in [33]. PIDF-LO [21] proposes S/MIME to protect the Location Object against modifications. S/SIME relies on public key cryptography which raises performance, deployment and size considerations. Encryption would require that the local AAA server or the NAS knows the recipient's public key (e.g., the public key of the home AAA server). So are we saying that the location information attributes can be encrypted in some cases, so that the privacy concerns are not applicable? But the attributes don't support this, right? Knowing the final recipient of the location information is in many cases difficult for RADIUS entities. Specifically, RADIUS clients only deal with RADIUS servers that are one hop away. _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors