Internet DRAFT - draft-ono-dispatch-attribute-validation
draft-ono-dispatch-attribute-validation
Dispatch K. Ono
Internet-Draft H. Schulzrinne
Intended status: Standards Track Columbia University
Expires: April 22, 2012 October 20, 2011
Referencing and Validating User Attributes
draft-ono-dispatch-attribute-validation-00.txt
Abstract
This document describes a mechanism for referencing and validating
user attributes in SIP communication. User attributes, such as an
organizational affiliation and role, are helpful for the recipients
of a communication request to decide whether or not to grant the
sender access to the recipient's resources, especially when the
sender identity is unknown to the recipients. This mechanism allows
the sender to claim her attributes to recipients using an attribute
reference identifier without needing to prove the sender identity.
This document defines a new SIP "Sender-References" header field to
convey one or more attribute reference identifiers. This mechanism
satisfies all the requirements for trait-based authorization defined
in RFC 4484, except that it provides only one assertion scheme.
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 April 22, 2012.
Copyright Notice
Copyright (c) 2011 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
Ono & Schulzrinne Expires April 22, 2012 [Page 1]
Internet-Draft User Attribute Validation October 2011
(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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Assumed Trust Relationships among AVS, Caller, and
Callee . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. ARIDs are Loosely Associated with the Owner's Identity
in SIP . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Differences between Our Requirements and the
Requirements for Trait-Based Authorization . . . . . . . . 7
5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Generating an ARID . . . . . . . . . . . . . . . . . . . . 9
5.2. Obtaining an ARID . . . . . . . . . . . . . . . . . . . . 10
5.3. Sending an ARID in a Communication Request . . . . . . . . 12
5.4. Validating an ARID to Retrieve User Attributes . . . . . . 12
6. Sender-References Header Field . . . . . . . . . . . . . . . . 14
7. Relationship to Existing Mechanisms . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8.1. Man in the Middle Attacks . . . . . . . . . . . . . . . . 17
8.2. Replay Attacks Using a Received ARID . . . . . . . . . . . 17
8.3. Denial of Service Attacks on the AVS . . . . . . . . . . . 18
8.4. Phishing Attacks on the AVS . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Ono & Schulzrinne Expires April 22, 2012 [Page 2]
Internet-Draft User Attribute Validation October 2011
1. Introduction
Ascertaining a person's attributes is often useful to determine the
trustworthiness of the person when two people first meet each other.
These user attributes include, for example, an organizational
affiliation, a role in a professional society, age, holding
certificates or licenses, and being a customer of a bank, an
employee, or a student. If user attributes are available with a
communication request, these attributes can help the recipient
determine how to handle the communication request by estimating
whether the communication is important enough to be established.
A caller identifier (ID) authenticated by the SIP Identity mechanism
[RFC4474], when used alone, can be a helpful user attribute, but only
in limited cases. Only if a caller ID is in a SIP-URI [RFC3261] and
is authenticated by the domain of a trusted organization can the
caller ID be perceived as evidence that the caller belongs to the
trusted organization. However, if a caller ID in a SIP-URI belongs
to an untrusted domain regarding user admission policy, such as a
free voice over IP service provider, or if a caller ID does not
contain any domain name, such as a tel-URI [RFC3966], the caller ID
does not indicate the caller's trustworthiness to the callee who has
never seen the caller ID before. Thus, even if a caller has multiple
contact addresses, the caller needs to use a contact address issued
by a trusted domain for authorization purposes. To offer a flexible
choice of which contact address to use, our referencing mechanism
introduces another piece of information, an attribute reference ID
(ARID), that enables a caller to refer to her attributes without
needing to rely on the caller ID. A caller can use multiple ARIDs if
the caller wants to prove multiple attributes associated with
different organizations. This referencing mechanism, unlike the
caller ID, allows a caller to use multiple ARIDs to declare multiple
user attributes in a single communication request.
If an authenticated caller ID does not provide sufficient
information, the callee can look up further user attributes through
directory services. However, a reference integrity problem arises
when a directory service does not allow queriers to look up user
attributes by the user's contact address. Additionally, when a
directory service allows queries by a user's contact address, but is
offered by a third party, not the issuer of contact addresses, the
authenticity of the information is unreliable. For example,
DoctorFinder service offered by the American Medical Association
provides information about certified medical doctors. When making a
query, a querier cannot use the doctor's phone number, but needs to
use doctor's common name, street address or specialty, which is
available to the public. If a doctor makes a call (or sends an email
message) that includes such query information and a reference to the
Ono & Schulzrinne Expires April 22, 2012 [Page 3]
Internet-Draft User Attribute Validation October 2011
DoctorFinder service, the callee (or the recipient) is not convinced
of the certainty. To solve this reference integrity problem, our
referencing mechanism allows an organization to generate a short-
lived ARID upon a caller request. This ARID is effective only for a
specific communication by limiting the lifetime and encoding
designated destinations, namely designated queriers. In addition,
the ARID can be used only for retrieving the attributes that the
caller selects to disclose to the specific queriers.
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 [RFC2119].
3. Architecture
Figure 1 depicts an overview of the service architecture where an
attribute validation server (AVS) operates to reference and validate
user attributes for an organization. For each user, the AVS
maintains the username and credentials to authenticate the user for
remote access, in addition to other information such as a user number
and role which the organization assigns, the users's common name,
affiliation, street address, and electronic contact addresses. Note
that the AVS stores a user's contact addresses, but it neither
guarantees that the user owns the contact addresses nor can be
reached by their addresses.
We provide an example for illustration. Alice, a user of services
provided by the organization, "example.org", is about to make a call
to Bob at "bob@example.com". Alice first requests an ARID from the
AVS using HTTP [RFC2616] over TLS [RFC5246]. When sending the
request, Alice authenticates the AVS using its X.509 Public Key
Certificate (PKC) [RFC5280] which is delivered in the TLS handshake
and is signed by a trusted Certificate Authority (CA). In turn, when
generating an ARID for Alice, the AVS authenticates her using any
credentials supported by the AVS, such as a password or a client's
X.509 PKC. Upon successfully obtaining an ARID, Alice makes a call
to Bob using SIP [RFC3261] over TLS. The SIP INVITE request includes
the ARID. When Bob receives an ARID, he queries the validity of the
ARID to the AVS using HTTP over TLS. Bob authenticates the AVS using
its X.509 PKC in the same way that Alice does. Based on the query
results, Bob determines whether or not to answer the call from Alice
and adjusts his communication stance accordingly.
Ono & Schulzrinne Expires April 22, 2012 [Page 4]
Internet-Draft User Attribute Validation October 2011
+------------------------+
| Attribute | Database
| Validation |==[username, credentials, attributes]
| Server (AVS) |
| |
| attributes.example.org |<------------\
+------------------------+ \ 3. Query
^ \ ARID's validity
| \ via HTTP over TLS
| 1. \
| Request and obtain an ARID \
| via HTTP over TLS \
| \
+---------------+ +------------------+
| UAC | 2. | UAS |
| | Send or call with ARID | |
| Alice | via SIP over TLS | Bob |
| +12345678 |------------------------->| bob@example.com |
+---------------+ +------------------+
Figure 1: Architecture
3.1. Assumed Trust Relationships among AVS, Caller, and Callee
We assume that the AVS and the caller, Alice, trust each other
regarding the attribute validation service for an organization,
"example.org." They share Alice's username and credentials for
remote access, and her attributes. Alice trusts the AVS to properly
maintain her attributes and to disclose the attributes she selects
only to queriers whom she specifies. In turn, the AVS trusts Alice
as a user in the organization and trusts her attributes which it
knows first-hand, such as "Alice is an IEEE student member."
However, the AVS does not know the authenticity of her attributes
that are not issued by the organization, such as her common name,
affiliation, and contact addresses.
We also assume that Bob knows "example.org" as the domain name of an
organization that has a user admission policy he trusts, whether or
not he belongs to the organization. Bob also trusts the AVS to
properly perform its attribute validation service.
Alice finds Bob worth making a call and disclosing her attributes to
establish a communication with him. In turn, Bob does not have
sufficient information about Alice's trustworthiness based solely on
her identity in a SIP communication request.
Ono & Schulzrinne Expires April 22, 2012 [Page 5]
Internet-Draft User Attribute Validation October 2011
3.2. ARIDs are Loosely Associated with the Owner's Identity in SIP
An ARID generated upon Alice's request can be used only to retrieve
her attributes, but the ARID is not tightly linked with her identity
used in a SIP communication request, namely the caller ID in a call.
When Bob receives an ARID in a SIP communication request where the
message integrity is protected by TLS, the callee can perceive the
ARID to be associated with the caller ID. Bob can loosely link an
ARID with the owner's identity only because of the fact that these
two pieces of information are sent in the same message. Other than
the presence of these two pieces of information in the same message,
there is no linkage between the ARID and the caller ID. Bob does not
need to provide Alice's caller ID to validate a received ARID. The
user attributes Bob retrieves upon the success of the validation do
not contain the owner's contact address. This loose linkage is a
natural consequence of the general fact that user attributes and the
user identifier in a communication are often issued separately by
different organizations or services.
This loose linkage, however, makes it difficult for Bob to detect
impersonation using a stolen ARID. Bob cannot detect this
impersonation by providing the AVS with the owner's caller ID or by
being presented the caller ID in user attributes. When issuing an
ARID, the AVS cannot easily authenticate her caller ID since the
caller ID is issued by a different administrative domain.
Additionally, Bob cannot always authenticate the caller ID. The
cases where no authentication of the caller ID is available include
where a caller ID is in a SIP-URI issued by the domain which does not
deploy the SIP Identity mechanism, where a caller ID is in a tel-URI
which is sent without any other authentication mechanisms, such as a
digital signature in S/MIME [RFC5751], and where a caller ID is
anonymized. Thus, although tightening this linkage can protect from
impersonation attacks, it makes the service deployment more difficult
and limits the caller's choice of caller IDs.
To mitigate the vulnerability to impersonation attacks using a stolen
ARID without tying an ARID to an authenticated caller ID, a
countermeasure is devised for each vulnerable target. To prevent a
man in the middle from eavesdropping on an ARID, all the connection
links to convey an ARID need to be protected with TLS. To detect
that an ARID was stolen from the owner, the recipients, or
intermediaries, such as a SIP proxy server, an ARID can be used to
retrieve user attributes only a limited number of times, for a
limited time period, and by limited queriers. Yet even with these
protections, this mechanism cannot prevent the owner of an ARID from
giving her own ARID to others. To keep this mechanism simple, we do
not include any additional mechanisms that discourage the owner from
giving her own ARID. As a result, this mechanism allows the owner of
Ono & Schulzrinne Expires April 22, 2012 [Page 6]
Internet-Draft User Attribute Validation October 2011
an ARID to informally delegate her attributes to others without
proving the chain of authorizing delegation. However, a legitimate
recipient cannot impersonate Alice's attributes by forwarding a
received ARID.
4. Requirements
This section first identifies the requirements of a mechanism for
referencing and validating attributes, and then identifies
differences between these requirements and the requirements for
Trait-Based Authorization (TBA) for SIP [RFC4484].
Our requirements are:
REQ-1: The mechanism must enable a user to prove one or more
attributes by presenting an attribute reference ID (ARID).
REQ-2: The mechanism must allow a user to prove her attributes in
one or more organizations in a single communication request.
REQ-3: The mechanism must allow a user to specify her attributes to
be disclosed for each communication session.
REQ-4: The mechanism must allow a user to restrict queriers who can
retrieve her attributes to the recipients of a communication
request.
REQ-5: This mechanism must adapt to various attribute policies;
thus, an ARID must be temporary rather than persistent.
REQ-6: The mechanism must allow the recipients of an ARID to easily
validate a received ARID.
REQ-7: The mechanism must prevent the recipients of an ARID from
impersonation by forwarding a received ARID.
REQ-8: The mechanism must protect user's private information, such
as communication history, even against an AVS.
REQ-9: This mechanism should provide flexibility for deployment;
thus, an ARID should be unique across different organizations
deployed on a single AVS.
We intentionally omit the following requirements:
o The mechanism does not need to prevent a user from giving her ARID
to others.
o The mechanism does not need to support a user who delegates the
ARID with proving the chain of authorizing delegation.
o The mechanism does not need to bind an ARID to the SIP signaling
path or SIP identity.
4.1. Differences between Our Requirements and the Requirements for
Trait-Based Authorization
Our requirements described above are similar to the TBA requirements
for SIP, but two differences exist. First, we do not require support
Ono & Schulzrinne Expires April 22, 2012 [Page 7]
Internet-Draft User Attribute Validation October 2011
for optional assertion schemes other than an ARID defined in
Section 5 while the TBA includes the following requirement:
7. The mechanism MUST have a single baseline mandatory-to-
implement authorization assertion scheme. The mechanism MUST also
allow support of other assertion schemes, which would be optional
to implement. One example of an assertion scheme is Security
Assertion Markup Language (SAML) [6] and another is RFC 3281 X.509
Attribute Certificates [7].
Our mechanism currently does not support other assertion schemes,
such as SAML [SAML] or X.509 Attribute Certificates (AC) [RFC5755],
as mentioned above. Such mechanisms that protect assertion integrity
by signing using the issuer's private key requires that recipients
verify the integrity using the issuer's public key in the application
layer. The recipients also need to authenticate the issuer of an
assertion. On the other hand, our mechanism relies on transport
layer security, namely TLS, to protect message integrity and
authenticate the issuer of an ARID. Although our mechanism does not
separately protect the integrity of user attributes or the linkage
between user attributes and their owner, our mechanism instead
protects the integrity of a whole message including these attributes.
As long as intermediaries such as an HTTP and SIP proxy servers can
be trusted to properly transfer messages for this attribute
referencing service, this security with TLS is simpler, and strong
enough against message tampering and server impersonation.
The second difference is that our requirements include an additional
requirement for protecting user's privacy described in REQ-8.
Although an authorization service or AVS needs to limit designated
queriers to the designated destinations of a SIP request, the
authorization service has to know neither user's communication
history nor plans containing routable contact addresses to do so even
for a short term during the lifetime of an assertion or ARID. Our
mechanism hashes contact addresses to prevent this unnecessary
disclosure of the private information of a user.
5. Procedures
Figure 2 illustrates message exchanges among a UAC, the UAS and the
AVS for the following procedures:
1. Obtaining an ARID;
2. Sending the ARID when making a call using SIP;
3. Validating the ARID to retrieve user attributes.
Before explaining each procedure, we describe how the AVS typically
generates an ARID.
Ono & Schulzrinne Expires April 22, 2012 [Page 8]
Internet-Draft User Attribute Validation October 2011
Alice Bob
UAC AVS UAS
| | |
| F1. HTTP POST | |
|---------------------->| |
| F2. 200 OK with ARID | |
|<----------------------| |
| | |
| F3. SIP INVITE with ARID |
|----------------------------------------------->|
| | |
| | F4. HTTP GET with ARID |
| |<-----------------------|
| | F5. 200 OK |
| |----------------------->|
| F6. 200 OK |
|<-----------------------------------------------|
| F7. ACK |
|----------------------------------------------->|
| |
Note: SIP messages to/from SIP proxy servers are omitted since they are
not affected by this mechanism.
Figure 2: Message Exchanges
5.1. Generating an ARID
An ARID is a string of URL [RFC3986] characters generated by an AVS
upon a user's request. When a single AVS offers this attribute
service for multiple organizations, a subdomain or a path in the URL
of the AVS website is assigned to each organization as part of an
ARID to meet the requirement REQ-9.
We show two examples how an AVS generates an ARID. Note that the AVS
does not have to follow these generating mechanisms. The first
example is to hash a string of characters by SHA1 [SHA1]. The string
of characters is a user number concatenated with the timestamp, a
nonce, and hashed contact addresses of one or more desired queriers
(REQ-4,8) as shown below. Hashed contact addresses of one or more
desired queriers are sent from a user when the user requests an ARID,
as described in Section 5.2. The information other than these hashed
contact addresses is stored or generated on the AVS.
Generating an ARID by hash:
m = user number || timestamp || nonce || hashed querier's contact
address
If two queriers, querier_1 and querier_2, are specified,
Ono & Schulzrinne Expires April 22, 2012 [Page 9]
Internet-Draft User Attribute Validation October 2011
m = user number || timestamp || nonce || hashed querier_1's
contact address;hashed querier_2's contact address
ARID = URL path/Hash(m)
Another example is to encrypt a string of characters with a symmetric
key of the AVS using AES [AES]. The string of characters is a user
number concatenated with a disclosure mode, the expiry time, hashed
contact addresses of desired queriers. The disclosure mode is
determined what attributes a user discloses to desired queriers
(REQ-3). The expiry time of an ARID needs to be shortly after the
time an ARID is generated, such as ten minutes later, to avoid replay
attacks (REQ-7).
An appropriate expiry time depends on the service type. For
synchronous communication services, such as a voice or video call
or real-time text chat, the lifetime needs to be short. For
asynchronous services, such as instant messaging, or email
communication, the lifetime needs to be longer, such as 24 hours.
Generating an ARID by encryption:
m = user number || disclosure mode || expiry time || salt|| hashed
querier's contact address
If two queriers, querier_1 and querier_2, are specified,
m = user_id || disclosure_mode || expiry time || salt || hashed
querier_1's contact address;hashed querier_2's contact address
ARID = URL path/Encrypt(m)
When selecting a method for generating an ARID, by hash or
encryption, they have the trade-off between the memory cost of
storing ARIDs with related data and the computational cost of
decrypting ARIDs. When generating an ARID by hash, the AVS needs to
store the generated ARID with associated data including the expiry
time, the nonce, the hashed contact addresses of desired queriers
which the user sent, and the disclosure mode which the user
specified. On the other hand, when generating an ARID by encryption,
the AVS only needs to remember the salt for decryption, but not any
generated ARIDs. Instead, it requires the computational cost of
decryption.
5.2. Obtaining an ARID
To obtain an ARID which can be used for a communication with Bob,
Alice first needs to connect to the AVS using a SIP UA which supports
this mechanism. When connecting, the SIP UAC MUST authenticate the
AVS using its X.509 PKC sent in the TLS handshake. In turn, the AVS
MUST authenticate Alice using her username and credentials. For user
authentication, HTTP Basic or Digest authentication [RFC2617], a
Ono & Schulzrinne Expires April 22, 2012 [Page 10]
Internet-Draft User Attribute Validation October 2011
client's PKC, or other mechanisms SHOULD be used. Upon successful
user authentication, the SIP UAC MUST send the AVS an HTTP POST
request with setting hashed Bob's contact address as a desired
querier, and a disclosure mode in a message body, as shown in the
following example. Each hashed contact address of a desired querier
SHOULD be attached as a JSON [RFC4627] object, or MAY be in XML
[XML]. When a communication request has multiple destinations, such
as a conference call, multiple "destination" fields SHOULD be
included to contain multiple hashed contact addresses of the desired
queriers.
F1. HTTP POST sent from Alice to AVS:
POST /requestARID HTTP/1.1
HOST:attributes.example.org
Content-Type:application/json
{"destination":"2cf6a1eda3b5205005d25a7d5dcf13bb200fc26a",\
"disclosure_mode":"details"}
Note: Mandatory HTTP or SIP headers unrelated to this mechanism
are not shown here and the following example messages.
Hashing the contact address of a desired querier is to limit
acceptable queriers without revealing communication history to the
AVS (REQ-8). The SIP UA supporting this mechanism MUST implement and
use SHA1, and MAY support any other hash algorithms. To prevent re-
identification based on hashed contact addresses collected on the
AVS, the SIP UAC MUST generate a salt, which is a random string of
characters, and concatenate it with a contact address as follows:
Hash(salt || contact address)
In the example above, the destination field,
"2cf6a1eda3b5205005d25a7d5dcf13bb200fc26a", is generated by
SHA1("dmvb1p03"||"sips:bob@example.com").
When the AVS successfully generates an ARID for Alice, the AVS
responds to her with a 200 OK response including the ARID and its
expiry time in the same data format used in the received HTTP
request. The HTTP messages MUST be sent over TLS to protect message
confidentiality and integrity. In the following example, the ARID is
attached as a JSON object. The "arid" field consists of the URL of
the website for the ARID validation,
"https://attributes.example.org/", and the ARID,
"17750c5cbac9979171991d505d2e634e727d8d9b."
F2. 200 OK sent from AVS to Alice:
Ono & Schulzrinne Expires April 22, 2012 [Page 11]
Internet-Draft User Attribute Validation October 2011
HTTP/1.1 200 OK
Content-Type:application/json
{ "arid":"https://attributes.example.org/17750c5cbac997917199\
1d505d2e634e727d8d9b", "expires":"2011-08-24T16:20:20Z" }
5.3. Sending an ARID in a Communication Request
When Alice makes a call to Bob with an ARID, she needs to specify the
ARID associated with the URL of the website for validating the ARID
in a SIP UA. The SIP UA MUST generate a new SIP header called
"Sender-Reference" including a URI, "type", "salt", and "hash_alg"
parameters to convey the ARID in the path of an HTTP URL, specify
this service, and the salt and the hash algorithm which were used for
hashing the querier's contact address described in Section 5.2,
respectively. If Alice wants to specify multiple ARIDs, this Sender-
References header field includes multiple set of an ARID and related
parameters concatenating a comma separator. The SIP UA then sends an
SIP INVITE request including the Sender-Reference as shown in the
following example. The INVITE request MUST be sent over TLS to
protect message confidentiality and integrity.
Instead of defining a new SIP header field, the existing Call-Info
header field can be set to an ARID by defining a new value of the
purpose parameter, such as "sender-attributes." However, to
convey a salt and the hash algorithm, we also need to define two
more parameters. To avoid complexing the Call-Info parameter
structure, we rather define a new SIP header field.
F3. SIP INVITE from Alice to Bob:
INVITE sips:bob@example.com SIP/2.0
From:Alice <tel:+12345678>
To:Bob <sips:bob@example.com>
Sender-References:<https://attributes.example.org/\
17750c5cbac9979171991d505d2e634e727d8d9b>;type="avs";\
salt="dmvb1p03";hash_alg="SHA1"
5.4. Validating an ARID to Retrieve User Attributes
When Bob, the recipient of one or more ARIDs, wants to retrieve the
caller attributes, the SIP UAS needs to test the validity of the
ARIDs on the corresponding AVSes. By prompting Bob or based on his
preconfigured information, the SIP UAS first needs to determine
whether or not he trusts each domain name of the AVS in the Sender-
References header in received SIP INVITE request. Only for trusted
AVSes, the SIP UAS looks up the received ARIDs on the corresponding
AVSes to retrieve the caller's attributes by using an HTTP GET
request as shown in the following example. HTTP messages MUST sent
Ono & Schulzrinne Expires April 22, 2012 [Page 12]
Internet-Draft User Attribute Validation October 2011
over TLS for security as well as messages between the SIP UAC the
AVS. Bob authenticates the AVS using its X.509 PKC delivered in the
TLS handshake.
For this validation, the SIP UAS MUST send the ARID found in the
Sender-References header field and a hashed querier's contact address
generated by the hash algorithm and salt also found in the Sender-
References header field. To generate a hashed querier's contact
address, the SIP UAS needs to know the original destination address
by extracting from the To header or by Bob's pre-configuration
especially when he enables call forwarding services. In the
following example, the hashed querier's contact address,
"2cf6a1eda3b5205005d25a7d5dcf13bb200fc26a", is generated by
SHA1("dmvb1p03"||"sips:bob@example.com"). This validation MAY be
invoked by a SIP inbound proxy on behalf of the UAS.
F4. HTTP GET from Bob to AVS:
GET /17750c5cbac9979171991d505d2e634e727d8d9b/\
2cf6a1eda3b5205005d25a7d5dcf13bb200fc26a HTTP/1.1
HOST:attributes.example.org
If no AVSes are trusted by Bob, the SIP UAS MUST ignore the Sender-
Reference header field and stop any further validation process. If
the SIP UAS does not support a hash algorithm specified in the
Sender-References header field, or if the SIP UAS does not support
the header field, it SHOULD also ignore the header field and continue
normal processing of the received SIP request.
If the ARID is valid at the queried time and with the querier's
contact address, the AVS MUST respond to the querier with 200 OK in
HTTP having the attributes based on the disclosure mode which Alice
specifies in the message body, as shown in the following example.
The attributes SHOULD be attached as a JSON object or MAY be in XML.
If the query is done later than the expiry time, the AVS SHOULD
respond with 408 Request Timeout in HTTP. If the querier is not
included in the list of desired queriers specified earlier by Alice,
the AVS SHOULD respond with 403 Forbidden in HTTP. If the ARID is
invalid for other reasons, the AVS MUST respond with 404 Not Found in
HTTP.
F5. HTTP 200 OK from AVS to Bob:
HTTP/1.1 200 OK
Content-Type:application/json
{ "user_status":"student member" }
Ono & Schulzrinne Expires April 22, 2012 [Page 13]
Internet-Draft User Attribute Validation October 2011
If Bob receives a 200 OK in HTTP from the AVS, he is informed that
the ARID is valid and attached information is the caller's
attributes, for the example above, the caller is a student member in
"example.org". With any other responses, Bob knows nothing about the
caller's attributes. Based on this information, he determines
whether or not to answer the call and adjusts his communication
stance accordingly.
6. Sender-References Header Field
The SIP "Sender-References" header field is newly defined to provide
the reference information about the sender or the caller. The field
consists of one or more sender-ref information. Each sender-ref
information consists of three parts: an absolute URI, sender-ref-
type, and avs-params. The absolute URI contains the URI of the AVS
website including an ARID in the path. The sender-ref-type indicates
the service type of using this header field. For this referencing
service, it MUST be "avs." The avs-params consists of two
parameters: one is to specify a salt and another is for a hash
algorithm. Both parameters are used for hashing a contact address to
be presented for validation.
The syntax of the Sender-References header field in the ABNF
[RFC5234] is as follows:
Sender-References = "Sender-References" HCOLON sender-ref
*(COMMA sender-ref)
sender-ref = LAQUOT absoluteURI RAQUOT sender-ref-type
SEMI avs-params
sender-ref-type = "type" EQUAL ( "avs" / quoted-string )
avs-params = salt-param SEMI hash-alg-param
salt-param = "salt" EQUAL quoted-string
hash-alg-param = "hash-alg" EQUAL ( "SHA1" / quoted-string )
This Sender-References header field is optionally set in any SIP
requests and responses.
7. Relationship to Existing Mechanisms
This section discusses why this referencing mechanism does not use
existing mechanisms that provide an attribute assertion or third-
party authentication, such as an X.509 Attribute Certificate (AC), a
Security Assertion Markup Language (SAML) assertion, Vouch by
Reference [RFC5518], OAuth [RFC5849] or Kerberos [RFC4120]. The
following table compares our mechanism using an AVS with these
existing mechanisms in terms of the trust model they assume, whether
Ono & Schulzrinne Expires April 22, 2012 [Page 14]
Internet-Draft User Attribute Validation October 2011
or not to need to bind the assertion to the sender ID, and applicable
services.
+-----------+----------+----------+----------+----------+-------+------+
| | AVS | X.509 AC | SAML | VBR | OAuth | Ker- |
| | | | assertion| | | beros|
+-----------+----------+----------+----------+----------+-------+------+
|trust model|described | the same as AVS | different |
| |in Sec 3.1| | from AVS |
+-----------+----------+----------+----------+----------+-------+------+
|need for | no | yes | optional |yes, with | no | yes |
|binding to | | | |the sender| | |
|sender ID | | | |domain | | |
+-----------+----------+----------+----------+----------+-------+------+
|apps. | SIP | any | any | email | Web | any |
+-----------+----------+----------+----------+----------+-------+------+
apps. = applications
An X.509 Attribute Certificate (AC) provides a superset of features
we need for our equivalent trust model. However, an X.509 AC, unlike
our mechanism, requires the AC holder information, namely a user's
identity, to be bound to the user's attributes. This binding is
protected by being digitally signed with the AC issuer's private key.
However, the AC issuer does not always have the right to sign the
binding since the AC issuer cannot authenticate the user identity
issued by a different organization as described in Section 3.2.
Authenticating the user identity requires either the user's PKC or
other mechanisms, such as the SIP identity mechanism where the user
identity is a user identifier in SIP. These mechanisms are difficult
to deploy for each reason. Users' PKCs have not been widely deployed
because of difficulty in managing the pair of public and private keys
across multiple devices. The sender ID in SIP is usually issued by
an administrative domain different from the AC issuer. For these
reasons, we need a new mechanism to allow a looser linkage between
the sender ID and attributes.
Similar to an X.509 AC, a SAML assertion provides a superset of
features we need for our equivalent trust model. Unlike an X.509 AC,
a SAML assertion does not require the binding between user attributes
and the user identity. Including the user identity into a SAML
assertion is optional. To limit queriers, a SAML assertion can
restrict its audience by addressing the URIs of specific entities,
but they are currently not allowed to address by their hashed names.
Thus, with a minor modification in the form of the restricted
audience, we can use an XML-based SAML assertion to convey user
attributes instead of a JSON object described in Section 5.4.
However, using a SAML assertion requires a digital signature by its
Ono & Schulzrinne Expires April 22, 2012 [Page 15]
Internet-Draft User Attribute Validation October 2011
issuer, which is an application layer protection against message
tampering and server impersonation. As discussed in Section 4.1, we
prefer a simple transport layer protection to an application layer
one, namely protecting a whole message by TLS rather than protecting
part of a message by a digital signature.
Vouch by Reference (VBR) defines a simple mechanism that vouches a
specific type of content claimed by the sender's domain of an email
message. This mechanism uses a new email "VBR-Info" header and a
DNS-based server of a third party certification service. If the
recipient finds a trusted domain from the certification service
providers set in the VBR-info header in a received email message, he
looks up an entry of the sender domain on the DNS-based server of a
trusted certification service provider. Since VBR assumes the same
trust model as ours, it is possible to extend this VBR mechanism to
vouch a user's attributes instead of certifying a specific content
type for the sender's domain. However, VBR requires the
authentication of the sender domain since the server domain is used
as a query key. Additionally, it is difficult for a DNS-based server
to restrict queriers for each record, mainly private attributes.
Consequently, we cannot apply VBR to referencing user attributes.
OAuth is a third-party authentication model for Web services. OAuth
uses three tokens to delegate limited permissions of user's resource
to another entity called a Consumer. With the OAuth terminology, a
caller is a User, the callee is a Consumer, and the AVS is a Service
Provider, which is a third-party authenticator. In OAuth, unlike our
trust model, the AVS and the callee share a Consumer ID and a key to
authenticate the Consumer when the AVS provides one of these three
tokens, a Request Token. An unauthorized Request Token is generated
upon the Consumer's request. After the Consumer is authorized by a
User, it is provided with an authorized Request Token. Since this
authorized Request Token has a restricted scope and limited lifetime
to access the Users' resources, this Request Token can be used to
query the caller's attributes once the caller authorizes that.
However, to obtain an authorized Request Token, the callee, who is a
Consumer in OAuth, needs to obtain an unauthorized Request Token from
the AVS beforehand. To resolve these differences in the trust models
and the procedures, it is possible to omit using both an unauthorized
and authorized Request Tokens. In addition, using the third token in
OAuth, an Access Token, which is exchanged with an authorized Request
Token, is not needed. Thus, we do not need unnecessary complexities
of using these three types of tokens. Rather, we prefer a simple
mechanism, using a single token for SIP.
Kerberos provides strong user-client authentication using a Key
Distribution Center (KDC). An Authentication Server in KDC
authenticates a user on behalf of a Service Server (SS), and a Ticket
Ono & Schulzrinne Expires April 22, 2012 [Page 16]
Internet-Draft User Attribute Validation October 2011
Granting Server (TGS) issues a ticket which is effective only for a
session between the user and the SS for a limited time period. The
Kerberos features cover all our mechanism needs, but the trust model
is different. Kerberos assumes that the TGS and the SS share the
SS's secret key to allow the SS to verify a received ticket by
decrypting with the SS's key without connecting to the TGS. Since
using this ticket is a key feature in Kerberos, we cannot omit
sharing the SS's key with the TGS to resolve the difference in the
trust model. Because of this difference in assumed trust model, we
cannot use Kerberos for referencing and validating user attributes.
8. Security Considerations
8.1. Man in the Middle Attacks
Man in the middle attacks need to be prevented on the AVS, connection
links, and the recipients of an ARID. To prevent from impersonating
a user on the AVS, the AVS MUST authenticate a user using HTTP Basic
or Digest authentication, a client X.509 PKC or other mechanisms. To
prevent from eavesdropping and message tampering on connection links,
all connection links between UAC and the AVS, UAC and UAS, UAS and
the AVS MUST be protected using TLS.
To prevent from impersonating user attributes using a stolen ARID,
the AVS MUST limit queriers using a specific ARID based on the hashed
contact addresses the original requester of the ARID specifies. SIP
UAs MUST support SHA1 to hash a contact address. To mitigate the
damage of the impersonation in the case where an ARID is stolen with
one of these hashed contact addresses, the AVS MUST limit an ARID's
lifetime and MAY also limit the number of times it can be resolved.
Limiting the use times of an ARID strengthens security, but
reduces service applicability. When the originator of a
communication knows that the communication has multiple
recipients, she can specify these multiple destination addresses
as designated queriers. The AVS then limits the use times of an
ARID to one for each designated querier. However, the difficult
case exists where the originator cannot know the number of honest
recipients or their addresses, for example, using a forking proxy
at the destination side or using a list service that distributes
the same message to multiple registered destinations.
8.2. Replay Attacks Using a Received ARID
The recipient of an ARID can exploit impersonation just by forwarding
a received ARID to another user since this mechanism does not have a
tight link between the username of AVS and the caller ID as described
in Section 3.2 nor a link between the SIP signaling path and the
Ono & Schulzrinne Expires April 22, 2012 [Page 17]
Internet-Draft User Attribute Validation October 2011
ARID. To prevent this replay or forwarding attack, the AVS MUST
limit queriers for each ARID based on the hashed contact addresses
that the original requester of the ARID specifies. This is the same
way as preventing impersonation using a stolen ARID described in
Section 8.1.
Suppose Bob, the recipient of Alice's ARID, forwards the ARID to
Carol when sending an instant message to her. In the message, Bob
instructs Carol to query his attributes using his hashed contact
address, instead of hers. By instructing this wrong way of query,
Bob fails in his attempt to masquerade as a user having Alice's
attributes. However, despite Alice's original designation, Carol can
retrieve Alice's attributes following Bob's wrong instruction,
resulting in raising Alice's privacy concerns. This privacy problem
is caused by Bob's misbehavior and unavoidable for any attribute
mechanisms which others can retrieve the attributes.
8.3. Denial of Service Attacks on the AVS
Another form of potential attacks is denial of service (DoS) attacks
by flooding requests to exhaust resources on the AVS. To mitigate
the damage from DoS attacks, we need to spare resources for valid
requests. For this purpose, the AVS MUST carefully configure TCP and
implement user authentication. To detect invalid requests as easily
as possible, this mechanism SHOULD use a light query protocol using
the RESTful API [REST], which sets a query key in the path of an HTTP
URL.
8.4. Phishing Attacks on the AVS
An evil website having a domain name confusingly similar to a well-
known AVS makes it possible to steal the password of a user for
remote access to the AVS. It is also possible for an evil website to
respond to any attribute queries with an HTTP 200 OK response with
forged user attributes attached to invalidate the attribute
validation service. To prevent these attacks, both a user and the
recipient of an ARID MUST use TLS when connecting to the AVS and MUST
ensure that the server's PKC has a valid signature for the valid
domain name.
9. IANA Considerations
This document defines a new SIP Sender-References header field. This
header field needs to be registered by the IANA in the SIP Parameters
registry under the Header Fields sub-registry.
Ono & Schulzrinne Expires April 22, 2012 [Page 18]
Internet-Draft User Attribute Validation October 2011
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[SHA1] National Institute of Science and Technology, "Secure Hash
Standard", Federal Information Processing Standard
(FIPS) 180-2, August 2002.
10.2. Informative References
[AES] National Institute of Science and Technology,
"Specifications for the Advanced Encryption Standard",
Federal Information Processing Standard (FIPS) 197,
November 2001.
[REST] Fielding, R. and R. Taylor, "Principled design of the
modern Web architecture", ACM Transactions on Internet
Technology (TOIT) 2-2, May 2002,
<http://portal.acm.org/citation.cfm?doid=514183.514185>.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
Ono & Schulzrinne Expires April 22, 2012 [Page 19]
Internet-Draft User Attribute Validation October 2011
RFC 3966, December 2004.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4484] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig,
"Trait-Based Authorization Requirements for the Session
Initiation Protocol (SIP)", RFC 4484, August 2006.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5518] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By
Reference", RFC 5518, April 2009.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet
Attribute Certificate Profile for Authorization",
RFC 5755, January 2010.
[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849,
April 2010.
[SAML] "Security Assertion Markup Language (SAML) V2.0",
March 2005,
<http://docs.oasis-open.org/security/saml/v2.0/>.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third
Edition)", W3C Recommendation REC-xml-20040204,
February 2004.
Ono & Schulzrinne Expires April 22, 2012 [Page 20]
Internet-Draft User Attribute Validation October 2011
Authors' Addresses
Kumiko Ono
Department of Computer Science
Columbia University
New York, NY 10027
USA
Email: kumiko@cs.columbia.edu
Henning Schulzrinne
Department of Computer Science
Columbia University
New York, NY 10027
USA
Email: hgs@cs.columbia.edu
Ono & Schulzrinne Expires April 22, 2012 [Page 21]
