One document matched: draft-ono-dispatch-attribute-validation-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3261 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml'>
<!ENTITY rfc3966 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3966.xml'>
<!ENTITY rfc2616 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml'>
<!ENTITY rfc2617 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2617.xml'>
<!ENTITY rfc5246 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'>
<!ENTITY rfc4627 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4627.xml'>
<!ENTITY rfc5755 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5755.xml'>
<!ENTITY rfc4510 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4510.xml'>
<!ENTITY rfc5518 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5518.xml'>
<!ENTITY rfc4474 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4474.xml'>
<!ENTITY rfc4120 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4120.xml'>
<!ENTITY rfc5849 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5849.xml'>
<!ENTITY rfc5280 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml'>
<!ENTITY rfc5234 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml'>
<!ENTITY rfc4484 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4484.xml'>
<!ENTITY rfc5751 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5751.xml'>
<!ENTITY rfc5039 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5039.xml'>
<!ENTITY rfc3986 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml'>
]>
<rfc category="std" ipr="trust200902" docName="draft-ono-dispatch-attribute-validation-00.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc tocdepth="2" ?>
<?rfc compact="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<front>
<title abbrev="User Attribute Validation">
Referencing and Validating User Attributes
</title>
<author initials="K.O." surname="Ono" fullname="Kumiko Ono">
<organization abbrev="Columbia University">
Department of Computer Science </organization>
<address>
<postal>
<street>Columbia University</street>
<city>New York</city> <region>NY</region>
<code>10027</code>
<country>USA</country>
</postal>
<email>kumiko@cs.columbia.edu</email>
</address>
</author>
<author initials="H.S." surname="Schulzrinne" fullname="Henning Schulzrinne">
<organization abbrev="Columbia University">
Department of Computer Science </organization>
<address>
<postal>
<street>Columbia University</street>
<city>New York</city> <region>NY</region>
<code>10027</code>
<country>USA</country>
</postal>
<email>hgs@cs.columbia.edu</email>
</address>
</author>
<date day="20" month="October" year="2011"/>
<area>Real-time Applications and Infrastructure</area>
<workgroup>Dispatch</workgroup>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
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.
</t>
<t>
A caller identifier (ID) authenticated by the SIP Identity mechanism <xref target="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 <xref target="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 <xref target="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.
</t>
<t>
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 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.
</t>
</section>
<section title="Terminology">
<t>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 <xref target="RFC2119"/>.
</t>
</section>
<section title="Architecture">
<t>
<xref target="fig_ov"/> 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.
</t>
<t>
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 <xref target="RFC2616"/> over TLS <xref
target="RFC5246"/>. When sending the request, Alice authenticates the
AVS using its X.509 Public Key Certificate (PKC) <xref
target="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 <xref target="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.
</t>
<figure anchor="fig_ov" title="Architecture"><artwork><![CDATA[
+------------------------+
| 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 |
+---------------+ +------------------+
]]></artwork></figure>
<section title="Assumed Trust Relationships among AVS, Caller, and Callee">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="ARIDs are Loosely Associated with the Owner's Identity in SIP" anchor="sec_loose_link">
<t>
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.
</t>
<t>
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 <xref target="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.
</t>
<t>
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
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.
</t>
</section>
</section>
<section title="Requirements">
<t>
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 <xref target="RFC4484"/>.
</t>
<t>
Our requirements are:
</t>
<list style="format REQ-%d:">
<t>The mechanism must enable a user to prove one or more attributes by presenting an attribute reference ID (ARID).</t>
<t>The mechanism must allow a user to prove her attributes in one or more organizations in a single communication request.
</t>
<t>The mechanism must allow a user to specify her attributes to be disclosed for each communication session.</t>
<t>The mechanism must allow a user to restrict queriers who can retrieve her attributes to the recipients of a communication request.
</t>
<t>This mechanism must adapt to various attribute policies; thus, an ARID must be temporary rather than persistent.
</t>
<t>The mechanism must allow the recipients of an ARID to easily validate a received ARID.
</t>
<t>The mechanism must prevent the recipients of an ARID from impersonation by forwarding a received ARID.
</t>
<t>The mechanism must protect user's private information, such as communication history, even against an AVS.
</t>
<t>This mechanism should provide flexibility for deployment; thus, an ARID should be unique across different organizations
deployed on a single AVS.
</t>
</list>
<t>We intentionally omit the following requirements:</t>
<list style="symbols">
<t>The mechanism does not need to prevent a user from giving her ARID to others.
</t>
<t>The mechanism does not need to support a user who delegates the ARID with proving the chain of authorizing delegation.
</t>
<t>
The mechanism does not need to bind an ARID to the SIP signaling path or SIP identity.
</t>
</list>
<section title="Differences between Our Requirements and the Requirements for Trait-Based Authorization" anchor="sec_diff">
<t>
Our requirements described above are similar to the TBA requirements for SIP,
but two differences exist.
First, we do not require support for optional assertion schemes other than an ARID defined in <xref target="sec_proc"/>
while the TBA includes the following requirement:
</t>
<list>
<t>
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].
</t>
</list>
<t>
Our mechanism currently does not support other assertion
schemes, such as SAML <xref target="SAML"/> or X.509 Attribute Certificates (AC) <xref target="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.
</t>
<t>
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.
</t>
</section>
</section>
<section title="Procedures" anchor="sec_proc">
<t>
<xref target="fig_seq"/> illustrates message exchanges among a UAC, the UAS and the AVS
for the following procedures:
</t>
<list style="numbers">
<t>Obtaining an ARID; </t>
<t>Sending the ARID when making a call using SIP; </t>
<t>Validating the ARID to retrieve user attributes.</t>
</list>
<t>
Before explaining each procedure, we describe how the AVS typically generates an ARID.
</t>
<figure anchor="fig_seq" title="Message Exchanges"><artwork><![CDATA[
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.
]]></artwork></figure>
<section title="Generating an ARID" anchor="sec_gen_arid">
<t>
An ARID is a string of URL <xref target="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.
</t>
<t>
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 <xref target="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 <xref target="sec_obtain_arid"/>.
The information other than these hashed contact addresses is stored or generated on the AVS.
</t>
<list style="hanging" hangIndent="3">
<t hangText="Generating an ARID by hash:">
<vspace />
m = user number || timestamp || nonce || hashed querier's contact address
<vspace blankLines="1"/>
If two queriers, querier_1 and querier_2, are specified,
<vspace/>
m = user number || timestamp || nonce || hashed querier_1's contact address;hashed querier_2's contact address
<vspace blankLines="1"/>
ARID = URL path/Hash(m)
</t>
</list>
<t>
Another example is to encrypt a string of characters with a symmetric key of the AVS using AES <xref target="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).
<list symbols="empty">
<t>
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.
</t>
</list>
<list style="hanging" hangIndent="3">
<t hangText="Generating an ARID by encryption:">
<vspace />
m = user number || disclosure mode || expiry time || salt|| hashed querier's contact address
<vspace blankLines="1"/>
If two queriers, querier_1 and querier_2, are specified,
<vspace/>
m = user_id || disclosure_mode || expiry time || salt || hashed querier_1's contact address;hashed querier_2's contact address
<vspace blankLines="1"/>
ARID = URL path/Encrypt(m)
</t>
</list>
</t>
<t>
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.
</t>
</section>
<section title="Obtaining an ARID" anchor="sec_obtain_arid">
<t>
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
<xref target="RFC2617"/>, a 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 <xref target="RFC4627"/> object,
or MAY be in XML <xref target="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.
</t>
<t>F1. HTTP POST sent from Alice to AVS:</t>
<list style="empty">
<artwork>
POST /requestARID HTTP/1.1
HOST:attributes.example.org
Content-Type:application/json
{"destination":"2cf6a1eda3b5205005d25a7d5dcf13bb200fc26a",\
"disclosure_mode":"details"}
</artwork>
<t>
Note: Mandatory HTTP or SIP headers unrelated to this mechanism are not shown here
and the following example messages.
</t>
</list>
<t>
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:
</t>
<list style="empty">
<t>
Hash(salt || contact address)
</t>
</list>
<t>
In the example above, the destination field,
"2cf6a1eda3b5205005d25a7d5dcf13bb200fc26a", is generated by SHA1("dmvb1p03"||"sips:bob@example.com").
</t>
<t>
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."
</t>
<t>F2. 200 OK sent from AVS to Alice:</t>
<list style="empty">
<artwork>
HTTP/1.1 200 OK
Content-Type:application/json
{ "arid":"https://attributes.example.org/17750c5cbac997917199\
1d505d2e634e727d8d9b", "expires":"2011-08-24T16:20:20Z" }
</artwork>
</list>
</section>
<section title="Sending an ARID in a Communication Request">
<t>
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 <xref target="sec_obtain_arid"/>, 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.
</t>
<list>
<t>
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.
</t>
</list>
<t>F3. SIP INVITE from Alice to Bob:</t>
<list style="empty">
<artwork>
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"
</artwork>
</list>
</section>
<section title="Validating an ARID to Retrieve User Attributes" anchor="sec_validate">
<t>
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 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.
</t>
<t>
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.
</t>
<t>F4. HTTP GET from Bob to AVS:</t>
<list style="empty">
<artwork>
GET /17750c5cbac9979171991d505d2e634e727d8d9b/\
2cf6a1eda3b5205005d25a7d5dcf13bb200fc26a HTTP/1.1
HOST:attributes.example.org
</artwork>
</list>
<t>
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.
</t>
<t>
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.
</t>
<t>F5. HTTP 200 OK from AVS to Bob:</t>
<list style="empty">
<artwork>
HTTP/1.1 200 OK
Content-Type:application/json
{ "user_status":"student member" }
</artwork>
</list>
<t>
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.
</t>
</section>
</section>
<section title="Sender-References Header Field">
<t>
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.
</t>
<t>
The syntax of the Sender-References header field in the ABNF <xref target="RFC5234"/> is as follows:
</t>
<list>
<artwork>
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 )
</artwork>
</list>
<t>
This Sender-References header field is optionally set in any SIP requests and responses.
</t>
</section>
<section title="Relationship to Existing Mechanisms">
<t>
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 <xref target="RFC5518"/>, OAuth <xref target="RFC5849"/>
or Kerberos <xref target="RFC4120"/>.
The following table compares our mechanism using an AVS with these existing mechanisms
in terms of the trust model they assume, whether or not to need to bind the assertion to the sender ID, and applicable services.
</t>
<artwork><![CDATA[
+-----------+----------+----------+----------+----------+-------+------+
| | 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
]]>
</artwork>
<t>
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 <xref target="sec_loose_link"/>. 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.
</t>
<t>
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 <xref target="sec_validate"/>.
However, using a SAML assertion requires a digital signature by its issuer, which is an application
layer protection against message tampering and server impersonation. As
discussed in <xref target="sec_diff"/>, 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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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
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.
</t>
</section>
<section title="Security Considerations">
<section title="Man in the Middle Attacks" anchor="sec_mitm">
<t>
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.
</t>
<t>
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.
</t>
<list>
<t>
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.
</t>
</list>
</section>
<section title="Replay Attacks Using a Received ARID">
<t>
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 <xref target="sec_loose_link"/>
nor a link between the SIP signaling path and the 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 <xref target="sec_mitm"/>.
</t>
<t>
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.
</t>
</section>
<section title="Denial of Service Attacks on the AVS">
<t>
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 <xref target="REST"/>, which sets a query key in the path of an HTTP URL.
</t>
</section>
<section title="Phishing Attacks on the AVS">
<t>
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.
</t>
</section>
</section>
<section title="IANA Considerations">
<t>
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.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;&rfc3261;
&rfc2616;
&rfc5246;
&rfc5234;
&rfc3986;
<reference anchor="SHA1">
<front>
<title>Secure Hash Standard</title>
<author>
<organization>National Institute of Science and Technology</organization>
</author>
<date month="August" year="2002"/>
</front>
<seriesInfo name="Federal Information Processing Standard (FIPS)" value="180-2"/>
</reference>
</references>
<references title="Informative References">
&rfc2617;
&rfc4484;
&rfc4627;
&rfc5280;
&rfc4474;
&rfc5755;
&rfc5518;
&rfc3966;
&rfc4120;
&rfc5849;
&rfc5751;
<reference anchor="AES">
<front>
<title>Specifications for the Advanced Encryption Standard</title>
<author>
<organization>National Institute of Science and Technology</organization>
</author>
<date month="November" year="2001"/>
</front>
<seriesInfo name="Federal Information Processing Standard (FIPS)" value="197"/>
</reference>
<reference anchor="XML">
<front>
<title>Extensible Markup Language (XML) 1.0 (Third Edition)</title>
<author initials="T" surname="Bray"/>
<author initials="J" surname="Paoli"/>
<author initials="C.M" surname="Sperberg-McQueen"/>
<author initials="E" surname="Maler"/>
<author initials="F" surname="Yergeau"/>
<organization>World Wide Web Consortium (W3C)</organization>
<date month="February" year="2004"/>
</front>
<seriesInfo name="W3C Recommendation" value="REC-xml-20040204"/>
</reference>
<reference anchor="SAML" target="http://docs.oasis-open.org/security/saml/v2.0/">
<front>
<title>Security Assertion Markup Language (SAML) V2.0</title>
<organization>OASIS Standard</organization>
<date month="March" year="2005"/>
</front>
</reference>
<reference anchor="REST" target="http://portal.acm.org/citation.cfm?doid=514183.514185">
<front>
<title>Principled design of the modern Web architecture</title>
<author initials="R" surname="Fielding"/>
<author initials="R" surname="Taylor"/>
<date month="May" year="2002"/>
</front>
<seriesInfo name="ACM Transactions on Internet Technology (TOIT)" value="2-2"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 12:54:35 |