Internet DRAFT - draft-uri-acr-extension
draft-uri-acr-extension
Network Working Group S. Jakobsson, Ed.
Internet-Draft Telenor ASA Digital Services
Intended status: Informational K. Smith, Ed.
Expires: September 2, 2012 Vodafone-Group (R&D)
March 1, 2012
The acr URI for anonymous users
draft-uri-acr-extension-04
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 in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 2, 2012.
Copyright Notice
Copyright (c) 2012 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
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 Simplified BSD License.
Jakobsson & Smith Expires September 2, 2012 [Page 1]
Internet-Draft Abbreviated Title March 2012
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 . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Sharing identity . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Jakobsson & Smith Expires September 2, 2012 [Page 2]
Internet-Draft Abbreviated Title March 2012
1. Introduction
This document specifies the URI (Uniform Resource Identifier) scheme
"acr". This URI scheme is intended as an extension to the "tel:"
scheme but without disclosing the true identity of a reference or a
user. The "acr" URI describes an anonymous reference, that can be
mapped to a resource or a 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 5234 [RFC5234] and uses elements from the core
definitions (appendix A of RFC 5234).
The syntax definition follows RFC 3986 [RFC3986], 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 3986 [RFC3986] ) are equivalent to their "% HEX HEX" percent
encoding.
The "acr" URI has the following syntax:
Jakobsson & Smith Expires September 2, 2012 [Page 3]
Internet-Draft Abbreviated Title March 2012
acr-uri = "acr:" anonymous-customer-reference
anonymous-customer-reference = 1*alphanum *par
par = parameter / network-code / acr-type / domainname
network-code = ";ncc=" 1*uric
acr-type = ";type=" 1*( "DYNA" / "STAT" )
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 look-up reference or otherwise obfuscated.
The issuing provider is responsible for unreferencing 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
Jakobsson & Smith Expires September 2, 2012 [Page 4]
Internet-Draft Abbreviated Title March 2012
In order to know who issued the "acr" identifier, the Network Code or
domain name MUST be included, for cross-operator identification and
to ensure it is known which entity can deference 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 meta-data, or to
list the service endpoints which can consume the ACR.
The "network code" (ncc) is for mobile networks a concatenation of
"mobile country code" (MCC) and "mobile network code" (MNC) as
defined in ITU-T RECOMMENDATION E.212
As an example of ncc for Vodafone in UK, consists of MCC=234 and
MNC=15 would concatenate to ncc=23415
The acr-type indicates if the ACR is a static type or a temporary
type.
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=23415;type=DYNA This temporal URI points
to a user or group of users and can be resolved by the Vodafone
mobile network in UK.
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
Jakobsson & Smith Expires September 2, 2012 [Page 5]
Internet-Draft Abbreviated Title March 2012
breach a user's privacy (unauthorized location look-up, 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 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 for their comments and suggestions.
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
Jakobsson & Smith Expires September 2, 2012 [Page 6]
Internet-Draft Abbreviated Title March 2012
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:
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
<a href="acr:123456">Find free information here</a>
<a href="acr:123456">Call RFC organization for help</a>
"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.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Jakobsson & Smith Expires September 2, 2012 [Page 7]
Internet-Draft Abbreviated Title March 2012
Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
9.2. Informative References
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
Authors' Addresses
Sune Jakobsson (editor)
Telenor ASA Digital Services
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 September 2, 2012 [Page 8]
