GeoPriv Working Group R. Gellens Internet Draft: GeoPriv Object/Protocol Requirements November 2001 Document: draft-gellens-geopriv-obj-req-00.txt GeoPriv Object/Protocol Requirements Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society 2001. All Rights Reserved. Table of Contents 1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2. Conventions Used in This Document . . . . . . . . . . . . . . 1 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 4. Requirements on the GeoPriv Object . . . . . . . . . . . . . 2 5. Requirements on Protocols Using the GeoPriv Object . . . . . 2 6. Usage Models . . . . . . . . . . . . . . . . . . . . . . . . 3 7. Security Considerations . . . . . . . . . . . . . . . . . . 3 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 9. Author's Address . . . . . . . . . . . . . . . . . . . . . . 4 10. Full Copyright Statement . . . . . . . . . . . . . . . . . . 4 1. Abstract This is a straw proposal for the requirements specification for the GeoPriv object and protocols which make use of it. 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. Gellens Expires May 2002 [Page 1] Internet Draft GeoPriv Object/Protocol Requirements November 2001 3. Introduction The GeoPriv working group needs to define requirements on its object and any use of this object by protocols. This memo is an attempt to list the minimum set of requirements for the most common uses. By starting with the simplest cases, we can more easily verify that the requirements are correct and that security and privacy are properly considered. We can then go on to consider more complex scenarios and see if the requirements need to be changed for them. 4. Requirements on the GeoPriv Object * The object MUST be suitable for requesting and receiving a location. * The object MUST contain enough information to allow the user/owner's policy to be applied, including decisions such as: - to disclose the location or not - the precision, accuracy, and age of the location - the number of decoy locations - encryption requirements * The object MUST permit (but not require) the policy to be enforced by a third party. * The object MUST be usable in a variety of protocols, such as HTTP [HTTP] and SIP [SIP], as well as local APIs. * The object MUST be usable in a secure manner even by applications on constrained devices. * Encryption and authentication MUST use IETF security protocols. * The object MUST carry location information in a well-known and standard format. * The object MUST be extensible. * All attributes of the object MUST have default values. This allows the object to be used in a more compact form, and allows interoperability with implementations supporting future extensions. * The default value of each attribute MUST reveal the least information. * The object SHOULD have attributes which allow the policy enforcer to comply with legal or contractual obligations. * The object SHOULD have a catchy acronym; for example Location and Security Description (LSD). 5. Requirements on Protocols Using the GeoPriv Object * Location information MUST be exchanged only in accordance with the user/owner's policy, including: - to disclose the location or not - the precision, accuracy, and age of the location - the number of decoy locations - encryption requirements Gellens Expires May 2002 [Page 2] Internet Draft GeoPriv Object/Protocol Requirements November 2001 6. Usage Models The model situation is where a device which knows its location wants to disclose it on request (for example, during an HTTP session). Other situations, such as a requester asking a proxy for the location of a target, or where the device doesn't know its location but a server does, can be constructed using the model situation as a base. The model situation requires a policy enforcer. This may reside within the device, or externally. Consider as an example that a web browser on the device is asked its location in order to receive a document. The original HTTP request might or might not use the GeoPriv object. The web browser on the device might construct a GeoPriv object and fill in what it knows (e.g., the host name asking for the information, details of the TLS [TLS] layer in effect, etc.), or it might verify and extend an object received in the HTTP request. In either case the object does not yet contain the location. The web browser passes the GeoPriv object to a local or remote policy enforcer, which applies the policy, fills in the location as appropriate under the policy, and returns a GeoPriv object. The web browser returns the GeoPriv object to the HTTP server. Alternatively, the web browser may return an encrypted GeoPriv object containing the location to the web server, which must send it to the policy enforcer (as specified in the object) in order to use the information. The policy enforcer applies the policy and returns a usable GeoPriv object to the web server. 7. Security Considerations Security is a primary concern of the object and any use of it by protocols. Security and privacy are considered throughout this document. 8. References [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, November 1997. Gellens Expires May 2002 [Page 3] Internet Draft GeoPriv Object/Protocol Requirements November 2001 [HTTP] Fielding, Gettys, Mogul, Frystyk, Masinter, Leach, Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [SIP] Handley, Schulzrinne, Schooler, Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [TLS] Dierks, Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. 9. Author's Address Randall Gellens QUALCOMM Incorporated 5775 Morehouse Dr. San Diego, CA 92121-2779 U.S.A. Phone: +1 858 651 5115 Email: rg+ietf@qualcomm.com 10. Full Copyright Statement Copyright (C) The Internet Society 2001. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Gellens Expires May 2002 [Page 4] Internet Draft GeoPriv Object/Protocol Requirements November 2001 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Gellens Expires May 2002 [Page 5]