Request for Comments: 4474 NeuStar
Category: Standards Track C. Jennings
Cisco Systems
August 2006
Enhancements for Authenticated Identity Management in the
Session Initiation Protocol (SIP)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The existing security mechanisms in the Session Initiation Protocol
(SIP) are inadequate for cryptographically assuring the identity of
the end users that originate SIP requests, especially in an
interdomain context. This document defines a mechanism for securely
identifying originators of SIP messages. It does so by defining two
new SIP header fields, Identity, for conveying a signature used for
validating the identity, and Identity-Info, for conveying a reference
to the certificate of the signer.
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Background ......................................................3
4. Overview of Operations ..........................................6
5. Authentication Service Behavior .................................7
5.1. Identity within a Dialog and Retargeting ..................10
6. Verifier Behavior ..............................................11
7. Considerations for User Agent ..................................12
8. Considerations for Proxy Servers ...............................13
9. Header Syntax ..................................................13
10. Compliance Tests and Examples .................................16
10.1. Identity-Info with a Singlepart MIME body ................17
10.2. Identity for a Request with No MIME Body or Contact ......20
11. Identity and the TEL URI Scheme ...............................22
12. Privacy Considerations ........................................23
13. Security Considerations .......................................24
13.1. Handling of digest-string Elements .......................24
13.2. Display-Names and Identity ...............................27
13.3. Securing the Connection to the Authentication Service ....28
13.4. Domain Names and Subordination ...........................29
13.5. Authorization and Transitional Strategies ................30
14. IANA Considerations ...........................................31
14.1. Header Field Names .......................................31
14.2. 428 ’Use Identity Header’ Response Code ..................32
14.3. 436 ’Bad Identity-Info’ Response Code ....................32
14.4. 437 ’Unsupported Certificate’ Response Code ..............32
14.5. 438 ’Invalid Identity Header’ Response Code ..............33
14.6. Identity-Info Parameters .................................33
14.7. Identity-Info Algorithm Parameter Values .................33
Appendix A. Acknowledgements ......................................34
Appendix B. Bit-Exact Archive of Examples of Messages .............34
B.1. Encoded Reference Files ...................................35
Appendix C. Original Requirements .................................38
References ........................................................39
Normative References ...........................................39
Informative References .........................................39
1. Introduction
This document provides enhancements to the existing mechanisms for
authenticated identity management in the Session Initiation Protocol
(SIP, RFC 3261 [1]). An identity, for the purposes of this document,
is defined as a SIP URI, commonly a canonical address-of-record (AoR)
employed to reach a user (such as ’sip:alice@atlanta.example.com’).
RFC 3261 stipulates several places within a SIP request where a user
can express an identity for themselves, notably the user-populated
From header field. However, the recipient of a SIP request has no
way to verify that the From header field has been populated
appropriately, in the absence of some sort of cryptographic
authentication mechanism.
RFC 3261 specifies a number of security mechanisms that can be
employed by SIP user agents (UAs), including Digest, Transport Layer
Security (TLS), and S/MIME (implementations may support other
security schemes as well). However, few SIP user agents today
support the end-user certificates necessary to authenticate
themselves (via S/MIME, for example), and furthermore Digest
authentication is limited by the fact that the originator and
destination must share a prearranged secret. It is desirable for SIP
user agents to be able to send requests to destinations with which
they have no previous association -- just as in the telephone network
today, one can receive a call from someone with whom one has no
previous association, and still have a reasonable assurance that the
person’s displayed Caller-ID is accurate. A cryptographic approach,
like the one described in this document, can probably provide a much
stronger and less-spoofable assurance of identity than the telephone
network provides today.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in RFC 2119 [2] and indicate requirement levels for
compliant SIP implementations.
3. Background
The usage of many SIP applications and services is governed by
authorization policies. These policies may be automated, or they may
be applied manually by humans. An example of the latter would be an
Internet telephone application that displays the Caller-ID of a
caller, which a human may review before answering a call. An example
of the former would be a presence service that compares the identity
of potential subscribers to a whitelist before determining whether it
should accept or reject the subscription. In both of these cases,
attackers might attempt to circumvent these authorization policies
through impersonation. Since the primary identifier of the sender of
a SIP request, the From header field, can be populated arbitrarily by
the controller of a user agent, impersonation is very simple today.
The mechanism described in this document aspires to provide a strong
identity system for SIP in which authorization policies cannot be
circumvented by impersonation.
All RFC 3261-compliant user agents support Digest authentication,
which utilizes a shared secret, as a means for authenticating
themselves to a SIP registrar. Registration allows a user agent to
express that it is an appropriate entity to which requests should be
sent for a particular SIP AoR URI (e.g.,
’sip:alice@atlanta.example.com’).
By the definition of identity used in this document, registration is
a proof of the identity of the user to a registrar. However, the
credentials with which a user agent proves its identity to a
registrar cannot be validated by just any user agent or proxy server
-- these credentials are only shared between the user agent and their
domain administrator. So this shared secret does not immediately
help a user to authenticate to a wide range of recipients.
Recipients require a means of determining whether or not the ’return
address’ identity of a non-REGISTER request (i.e., the From header
field value) has legitimately been asserted.
The AoR URI used for registration is also the URI with which a UA
commonly populates the From header field of requests in order to
provide a ’return address’ identity to recipients. From an
authorization perspective, if you can prove you are eligible to
register in a domain under a particular AoR, you can prove you can
legitimately receive requests for that AoR, and accordingly, when you
place that AoR in the From header field of a SIP request other than a
registration (like an INVITE), you are providing a ’return address’
where you can legitimately be reached. In other words, if you are
authorized to receive requests for that ’return address’, logically,
it follows that you are also authorized to assert that ’return
address’ in your From header field. This is of course only one
manner in which a domain might determine how a particular user is
authorized to populate the From header field; as an aside, for other
sorts of URIs in the From (like anonymous URIs), other authorization
policies would apply.
Ideally, then, SIP user agents should have some way of proving to
recipients of SIP requests that their local domain has authenticated
them and authorized the population of the From header field. This
document proposes a mediated authentication architecture for SIP in
which requests are sent to a server in the user’s local domain, which
authenticates such requests (using the same practices by which the
domain would authenticate REGISTER requests). Once a message has
been authenticated, the local domain then needs some way to
communicate to other SIP entities that the sending user has been
authenticated and its use of the From header field has been
authorized. This document addresses how that imprimatur of
authentication can be shared.
RFC 3261 already describes an architecture very similar to this in
Section 26.3.2.2, in which a user agent authenticates itself to a
local proxy server, which in turn authenticates itself to a remote
proxy server via mutual TLS, creating a two-link chain of transitive
authentication between the originator and the remote domain. While
this works well in some architectures, there are a few respects in
which this is impractical. For one, transitive trust is inherently
weaker than an assertion that can be validated end-to-end. It is
possible for SIP requests to cross multiple intermediaries in
separate administrative domains, in which case transitive trust
becomes even less compelling.
One solution to this problem is to use ’trusted’ SIP intermediaries
that assert an identity for users in the form of a privileged SIP
header. A mechanism for doing so (with the P-Asserted-Identity
header) is given in [12]. However, this solution allows only hop-
by-hop trust between intermediaries, not end-to-end cryptographic
authentication, and it assumes a managed network of nodes with strict
mutual trust relationships, an assumption that is incompatible with
widespread Internet deployment.
Accordingly, this document specifies a means of sharing a
cryptographic assurance of end-user SIP identity in an interdomain or
intradomain context that is based on the concept of an
’authentication service’ and a new SIP header, the Identity header.
Note that the scope of this document is limited to providing this
identity assurance for SIP requests; solving this problem for SIP
responses is more complicated and is a subject for future work.
This specification allows either a user agent or a proxy server to
provide identity services and to verify identities. To maximize
end-to-end security, it is obviously preferable for end-users to
acquire their own certificates and corresponding private keys; if
they do, they can act as an authentication service. However, end-
user certificates may be neither practical nor affordable, given the
difficulties of establishing a Public Key Infrastructure (PKI) that
extends to end-users, and moreover, given the potentially large
number of SIP user agents (phones, PCs, laptops, PDAs, gaming
devices) that may be employed by a single user. In such
environments, synchronizing keying material across multiple devices
may be very complex and requires quite a good deal of additional
endpoint behavior. Managing several certificates for the various
devices is also quite problematic and unpopular with users.
Accordingly, in the initial use of this mechanism, it is likely that
intermediaries will instantiate the authentication service role.
4. Overview of Operations
This section provides an informative (non-normative) high-level
overview of the mechanisms described in this document.
Imagine the case where Alice, who has the home proxy of example.com
and the address-of-record sip:alice@example.com, wants to communicate
with sip:bob@example.org.
Alice generates an INVITE and places her identity in the From header
field of the request. She then sends an INVITE over TLS to an
authentication service proxy for her domain.
The authentication service authenticates Alice (possibly by sending a
Digest authentication challenge) and validates that she is authorized
to assert the identity that is populated in the From header field.
This value may be Alice’s AoR, or it may be some other value that the
policy of the proxy server permits her to use. It then computes a
hash over some particular headers, including the From header field
and the bodies in the message. This hash is signed with the
certificate for the domain (example.com, in Alice’s case) and
inserted in a new header field in the SIP message, the ’Identity’
header.
The proxy, as the holder of the private key of its domain, is
asserting that the originator of this request has been authenticated
and that she is authorized to claim the identity (the SIP address-
of-record) that appears in the From header field. The proxy also
inserts a companion header field, Identity-Info, that tells Bob how
to acquire its certificate, if he doesn’t already have it.
When Bob’s domain receives the request, it verifies the signature
provided in the Identity header, and thus can validate that the
domain indicated by the host portion of the AoR in the From header
field authenticated the user, and permitted the user to assert that
From header field value. This same validation operation may be
performed by Bob’s user agent server (UAS).
5. Authentication Service Behavior
This document defines a new role for SIP entities called an
authentication service. The authentication service role can be
instantiated by a proxy server or a user agent. Any entity that
instantiates the authentication service role MUST possess the private
key of a domain certificate. Intermediaries that instantiate this
role MUST be capable of authenticating one or more SIP users that can
register in that domain. Commonly, this role will be instantiated by
a proxy server, since these entities are more likely to have a static
hostname, hold a corresponding certificate, and have access to SIP
registrar capabilities that allow them to authenticate users in their
domain. It is also possible that the authentication service role
might be instantiated by an entity that acts as a redirect server,
but that is left as a topic for future work.
SIP entities that act as an authentication service MUST add a Date
header field to SIP requests if one is not already present (see
Section 9 for information on how the Date header field assists
verifiers). Similarly, authentication services MUST add a Content-
Length header field to SIP requests if one is not already present;
this can help verifiers to double-check that they are hashing exactly
as many bytes of message-body as the authentication service when they
verify the message.
Entities instantiating the authentication service role perform the
following steps, in order, to generate an Identity header for a SIP
request:
Step 1:
The authentication service MUST extract the identity of the sender
from the request. The authentication service takes this value from
the From header field; this AoR will be referred to here as the
’identity field’. If the identity field contains a SIP or SIP Secure
(SIPS) URI, the authentication service MUST extract the hostname
portion of the identity field and compare it to the domain(s) for
which it is responsible (following the procedures in RFC 3261,
Section 16.4, used by a proxy server to determine the domain(s) for
which it is responsible). If the identity field uses the TEL URI
scheme, the policy of the authentication service determines whether
or not it is responsible for this identity; see Section 11 for more
information. If the authentication service is not responsible for
the identity in question, it SHOULD process and forward the request
normally, but it MUST NOT add an Identity header; see below for more
information on authentication service handling of an existing
Identity header.
Step 2:
The authentication service MUST determine whether or not the sender
of the request is authorized to claim the identity given in the
identity field. In order to do so, the authentication service MUST
authenticate the sender of the message. Some possible ways in which
this authentication might be performed include:
If the authentication service is instantiated by a SIP
intermediary (proxy server), it may challenge the request with
a 407 response code using the Digest authentication scheme (or
viewing a Proxy-Authentication header sent in the request,
which was sent in anticipation of a challenge using cached
credentials, as described in RFC 3261, Section 22.3). Note
that if that proxy server is maintaining a TLS connection with
the client over which the client had previously authenticated
itself using Digest authentication, the identity value obtained
from that previous authentication step can be reused without an
additional Digest challenge.
If the authentication service is instantiated by a SIP user
agent, a user agent can be said to authenticate its user on the
grounds that the user can provision the user agent with the
private key of the domain, or preferably by providing a
password that unlocks said private key.
Authorization of the use of a particular username in the From header
field is a matter of local policy for the authentication service, one
that depends greatly on the manner in which authentication is
performed. For example, one policy might be as follows: the username
given in the ’username’ parameter of the Proxy-Authorization header
MUST correspond exactly to the username in the From header field of
the SIP message. However, there are many cases in which this is too
limiting or inappropriate; a realm might use ’username’ parameters in
Proxy-Authorization that do not correspond to the user-portion of SIP
From headers, or a user might manage multiple accounts in the same
administrative domain. In this latter case, a domain might maintain
a mapping between the values in the ’username’ parameter of Proxy-
Authorization and a set of one or more SIP URIs that might
legitimately be asserted for that ’username’. For example, the
username can correspond to the ’private identity’ as defined in Third
Generation Partnership Project (3GPP), in which case the From header
field can contain any one of the public identities associated with
this private identity. In this instance, another policy might be as
follows: the URI in the From header field MUST correspond exactly to
one of the mapped URIs associated with the ’username’ given in the
Proxy-Authorization header. Various exceptions to such policies
might arise for cases like anonymity; if the AoR asserted in the From
header field uses a form like ’sip:anonymous@example.com’, then the
’example.com’ proxy should authenticate that the user is a valid user
in the domain and insert the signature over the From header field as
usual.
Note that this check is performed on the addr-spec in the From header
field (e.g., the URI of the sender, like
’sip:alice@atlanta.example.com’); it does not convert the display-
name portion of the From header field (e.g., ’Alice Atlanta’).
Authentication services MAY check and validate the display-name as
well, and compare it to a list of acceptable display-names that may
be used by the sender; if the display-name does not meet policy
constraints, the authentication service MUST return a 403 response
code. The reason phrase should indicate the nature of the problem;
for example, "Inappropriate Display Name". However, the display-name
is not always present, and in many environments the requisite
operational procedures for display-name validation may not exist.
For more information, see Section 13.2.
Step 3:
The authentication service SHOULD ensure that any preexisting Date
header in the request is accurate. Local policy can dictate
precisely how accurate the Date must be; a RECOMMENDED maximum
discrepancy of ten minutes will ensure that the request is unlikely
to upset any verifiers. If the Date header contains a time different
by more than ten minutes from the current time noted by the
authentication service, the authentication service SHOULD reject the
request. This behavior is not mandatory because a user agent client
(UAC) could only exploit the Date header in order to cause a request
to fail verification; the Identity header is not intended to provide
a source of non-repudiation or a perfect record of when messages are
processed. Finally, the authentication service MUST verify that the
Date header falls within the validity period of its certificate. For
more information on the security properties associated with the Date
header field value, see Section 9.
Step 4:
The authentication service MUST form the identity signature and add
an Identity header to the request containing this signature. After
the Identity header has been added to the request, the authentication
service MUST also add an Identity-Info header. The Identity-Info
header contains a URI from which its certificate can be acquired.
Details on the generation of both of these headers are provided in
Section 9.
Finally, the authentication service MUST forward the message
normally.
5.1. Identity within a Dialog and Retargeting
Retargeting is broadly defined as the alteration of the Request-URI
by intermediaries. More specifically, retargeting supplants the
original target URI with one that corresponds to a different user, a
user that is not authorized to register under the original target
URI. By this definition, retargeting does not include translation of
the Request-URI to a contact address of an endpoint that has
registered under the original target URI, for example.
When a dialog-forming request is retargeted, this can cause a few
wrinkles for the Identity mechanism when it is applied to requests
sent in the backwards direction within a dialog. This section
provides some non-normative considerations related to this case.
When a request is retargeted, it may reach a SIP endpoint whose user
is not identified by the URI designated in the To header field value.
The value in the To header field of a dialog-forming request is used
as the From header field of requests sent in the backwards direction
during the dialog, and is accordingly the header that would be signed
by an authentication service for requests sent in the backwards
direction. In retargeting cases, if the URI in the From header does
not identify the sender of the request in the backwards direction,
then clearly it would be inappropriate to provide an Identity
signature over that From header. As specified above, if the
authentication service is not responsible for the domain in the From
header field of the request, it MUST NOT add an Identity header to
the request, and it should process/forward the request normally.
Any means of anticipating retargeting, and so on, is outside the
scope of this document, and likely to have equal applicability to
response identity as it does to requests in the backwards direction
within a dialog. Consequently, no special guidance is given for
implementers here regarding the ’connected party’ problem;
authentication service behavior is unchanged if retargeting has
occurred for a dialog-forming request. Ultimately, the
authentication service provides an Identity header for requests in