Network Working Group S. Jakobsson, Ed.
Internet-Draft Telenor ASA GBD&R
Intended status: Informational K. Smith, Ed.
Expires: July 25, 2010 Vodafone-Group (R&D)
January 21, 2010
The acr URI for anonymous users
draft-uri-acr-extension-00
Abstract
This document specifies the URI (Uniform Resource Identifier) scheme
"acr". The "acr" URI describes an anonymous reference, that can be
mapped to a resource or user.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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.
This Internet-Draft will expire on July 25, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Jakobsson & Smith Expires July 25, 2010 [Page 1]
Internet-Draft Abbreviated Title January 2010
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. URI syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Privacy policies . . . . . . . . . . . . . . . . . . . . . 5
5.2. Cookie support . . . . . . . . . . . . . . . . . . . . . . 5
5.3. Sharing identity . . . . . . . . . . . . . . . . . . . . . 5
5.4. Relation to SIP . . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Jakobsson & Smith Expires July 25, 2010 [Page 2]
Internet-Draft Abbreviated Title January 2010
1. Introduction
This document specifies the URI (Uniform Resource Identifier) scheme
"acr". The "acr" URI describes an anonymous reference, that can be
mapped to a resource or user. There are multiple situations where
the true identity of a user or a resources can not be disclosed. The
"acr" URI is a globally unique identifier ( "name" ) only; it does
not describe the steps necessary to reach the user or the device.
However it can contain a parameter indication what body or
organisation that could resolve it. It is intended for privacy
protection, where a user trusts a translating party, that can route
or forward the request or message to the true user or resource.
2. Terminology
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 [RFC2119] and
indicate the requirements levels for compliant implementations.
3. URI syntax
The URI is defined using AB-NF (Augmented Backus-Naur Form) as
described in RFC 2234 [RFC2234] and uses elements from the core
definitions (appendix A of RFC 2234).
The syntax definition follows RFC 2396 [RFC2396], indicating the
actual characters contained in the URI. If the reserved characters
"+", ";", "=", and "?" are used as delimiters between components of
the "tel" URI, they MUST NOT be percent encoded. These characters
MUST be percent encoded if they appear in tel URI parameter values.
Characters other than those in the "reserved" and "unsafe" sets (see
RFC 2396 [RFC2396] ) are equivalent to their "% HEX HEX" percent
encoding.
The "acr" URI has the following syntax:
Jakobsson & Smith Expires July 25, 2010 [Page 3]
Internet-Draft Abbreviated Title January 2010
acr-uri = "acr:" anonymous-subscriber-identifier
anonymous-subscriber-identifier = 1*alphanum *par
par = parameter / network-code / domainname
network-code = ";ncc=" 1*uric
domainname = ";domain=" *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum
/ alphanum *( alphanum / "-" ) alphanum
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
parameter = ";" pname [ "=" pvalue ]
pname = 1*( alphanum / "-" )
pvalue = 1*paramchar
paramchar = param-unreserved / unreserved / pct-encoded
unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")"
pct-encoded = "%" HEXDIG HEXDIG
param-unreserved= "[" / "]" / "/" / ":" / "&" / "+" / "$"
alphanum = ALPHA / DIGIT
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" / "$"
/ ","
uric = reserved / unreserved / pct-encoded
DIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8"
/ "9"
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" / "a"
/ "b" / "c" / "d" / "e" / "f"
ALPHA = lowalpha / upalpha
lowalpha = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i"
/ "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r"
/ "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z"
upalpha = "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I"
/ "J" / "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R"
/ "S" / "T" / "U" / "V" / "W" / "X" / "Y" / "Z"
Figure 1
The "anonymous-subscriber-identifier" can be created from some
suitable user or customer data such as, phone number, and validation
date. In order to provide anonymisation, this data MUST not be
included unchanged within the ACR. Rather it MUST be encrypted,
hashed, represented by a lookup reference or otherwise obfuscated.
The issuing provider is responsible for dereferencing the ACR to the
user or resource. For example the SHA-256 algorithm can hash the
sensitive data:
SHA256("")= e3b0c442 98fc1c14 9afbf4c8 996fb924 27ae41e4 649b934c
a495991b 7852b855
In order to know who issued the identifier the Network Code or domain
Jakobsson & Smith Expires July 25, 2010 [Page 4]
Internet-Draft Abbreviated Title January 2010
name MUST be included, for cross-operator identification and to
ensure it is known which entity can dereference the ACR. In addition
a network country identifier MUST be provided (either as part of the
network code, or separately) to avoid confusion where networks
operate in multiple countries. A URI for ACR documentation MAY be
included; for example, to discover further metadata, or to list the
service endpoints which can consume the ACR.
4. Examples
acr:0123456890123456789 This URI points to a user. for network
internal use only since the network code is not provided
acr:0123456890123456789;ncc=123 This URI points to a user belonging
to network 123
acr:0123456890123456789;ncc=123 This URI points to a group of users
belonging to network 123.
Note that the fact that more than one user is represented is not
intrinsic to the acr but only known to the issuing network.
acr:0123456890123456789;domain=example.com This URI points to a user
belonging in domain example.com
5. Rationale
5.1. Privacy policies
Existing privacy policies and legislation restrict the sharing of
certain user identifiers, such as the MSISDN, since it may be used to
broach a user' s privacy (unauthorized location lookup, cold calling,
SMS Spam etc.). An ACR prevents such identifiers from being
circulated.
5.2. Cookie support
Cookie support is inconsistent across mobile devices. An acr can
help identify a returning mobile user to a Website, and hence
facilitate the provisioning of a personalized service based on
previous preferences and activity.
5.3. Sharing identity
Mobile, broadband and other access networks do not typically share a
user identifier. The acr is not bound to a particular access network
Jakobsson & Smith Expires July 25, 2010 [Page 5]
Internet-Draft Abbreviated Title January 2010
and can hence be used to provision user identifiers between networks.
5.4. Relation to SIP
The ACR can help the implementation of SIP privacy considerations, as
detailed in RFC3323 [RFC3323], 'A Privacy Mechanism for the Session
Initiation Protocol'. Specifically the ACR can be used as the value
for the 'anonymous from' header field [section 4.1], and is
consistent with the recommendation to remove Subject, Call-info,
Organization, User Agent, Reply-To, In-Reply-To in [section 5.3].
6. Acknowledgements
This document is built on top of RFC3966 [RFC3966], written by
Henning Schulzerinne
The editors of this document wishes to thank the GSMA ACCESS project
members, Gautam Hazari and Douglas Robb for their comments and
suggestions. We also would like to thank Frode Kileng for IETF
guidance.
7. IANA Considerations
This document includes a request to IANA.
The editors of this draft request the protocol scheme name "acr" to
be reserved for this RFC.
8. Security Considerations
Since the "acr" is used to protect the identity of a user or a device
the forwarding party must not disclose information that would or can
be used to reveal the identity of the user. However the network code
or domain name will reveal some information of the the "acr"
affiliation.
The security considerations parallel those for the tel URI RFC3966
[RFC3966].
Web clients and similar tools MUST NOT use the "acr" URI to place
telephone calls or send messages without the explicit consent of the
user of that client. Placing calls or sending messages automatically
without appropriate user confirmation may incur a number of risks,
such as those described below:
Jakobsson & Smith Expires July 25, 2010 [Page 6]
Internet-Draft Abbreviated Title January 2010
o Calls or messages may incur costs.
o The URI may be used to place malicious or annoying calls.
o A call will take the user's phone line off-hook, thus preventing
its use.
o A call may reveal the user's possibly unlisted phone number to the
remote host in the caller identification data and may allow the
attacker to correlate the user's phone number with other
information, such as an e-mail or IP address.
This is particularly important for "acr" URIs embedded in HTML links,
as a malicious party may hide the true nature of the URI in the link
text, as in
Find free information here
Call RFC organization for help
"acr" URIs may reveal private information, similar to including phone
numbers as text. However, the presence of the acr: schema identifier
may make it easier for an adversary using a search engine to discover
these numbers, and hence search engines should avoid indexing these
identifiers.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
9.2. Informative References
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
Jakobsson & Smith Expires July 25, 2010 [Page 7]
Internet-Draft Abbreviated Title January 2010
Authors' Addresses
Sune Jakobsson (editor)
Telenor ASA GBD&R
Otto Nielsens vei 12
Trondheim, 7004
Norway
Phone: +47 995 17 017
Email: sune.jakobsson@telenor.com
Kevin Smith (editor)
Vodafone-Group (R&D)
One Kingdom Street
London, WC2R 0RJ
UK
Phone: +44 78 251 06 554
Email: kevin.smith@vodafone.com
Jakobsson & Smith Expires July 25, 2010 [Page 8]