Date: Thu, 21 Feb 2002 14:19:51 GMT
Call-ID: a84b4c76e66710
CSeq: 231 BYE
Content-Length: 0
Also note that this request contains no Contact header field.
Accordingly, biloxi.example.org will place no value in the canonical
string for the addr-spec of the Contact address. Also note that
there is no message body, and accordingly, the signature string will
terminate, in this case, with two vertical bars. The canonical
string over which the identity signature will be generated is the
following (note that the first line wraps because of RFC editorial
conventions):
sip:bob@biloxi.example.org|sip:alice@atlanta.example.com|
a84b4c76e66710|231 BYE|Thu, 21 Feb 2002 14:19:51 GMT||
The resulting signature (sha1WithRsaEncryption) using the private RSA
key given above for biloxi.example.org, with base64 encoding, is the
following:
sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo
eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp
pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=
Accordingly, the biloxi.example.org authentication service will
create an Identity header containing that base64 signature string.
It will also add an HTTPS URL where its certificate is made
available. With those two headers added, the message looks like the
following:
BYE sip:alice@pc33.atlanta.example.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnashds10
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.org>;tag=a6c85cf
To: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Date: Thu, 21 Feb 2002 14:19:51 GMT
Call-ID: a84b4c76e66710
CSeq: 231 BYE
Identity:
"sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo
eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp
pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs="
Identity-Info: <https://biloxi.example.org/biloxi.cer>;alg=rsa-sha1
Content-Length: 0
biloxi.example.org then forwards the request normally.
11. Identity and the TEL URI Scheme
Since many SIP applications provide a Voice over IP (VoIP) service,
telephone numbers are commonly used as identities in SIP deployments.
In the majority of cases, this is not problematic for the identity
mechanism described in this document. Telephone numbers commonly
appear in the username portion of a SIP URI (e.g.,
’sip:+17005551008@chicago.example.com;user=phone’). That username
conforms to the syntax of the TEL URI scheme (RFC 3966 [13]). For
this sort of SIP address-of-record, chicago.example.com is the
appropriate signatory.
It is also possible for a TEL URI to appear in the SIP To or From
header field outside the context of a SIP or SIPS URI (e.g.,
’tel:+17005551008’). In this case, it is much less clear which
signatory is appropriate for the identity. Fortunately for the
identity mechanism, this form of the TEL URI is more common for the
To header field and Request-URI in SIP than in the From header field,
since the UAC has no option but to provide a TEL URI alone when the
remote domain to which a request is sent is unknown. The local
domain, however, is usually known by the UAC, and accordingly it can
form a proper From header field containing a SIP URI with a username
in TEL URI form. Implementations that intend to send their requests
through an authentication service SHOULD put telephone numbers in the
From header field into SIP or SIPS URIs whenever possible.
If the local domain is unknown to a UAC formulating a request, it
most likely will not be able to locate an authentication service for
its request, and therefore the question of providing identity in
these cases is somewhat moot. However, an authentication service MAY
sign a request containing a TEL URI in the From header field. This
is permitted in this specification strictly for forward compatibility
purposes. In the longer-term, it is possible that ENUM [14] may
provide a way to determine which administrative domain is responsible
for a telephone number, and this may aid in the signing and
verification of SIP identities that contain telephone numbers. This
is a subject for future work.
12. Privacy Considerations
The identity mechanism presented in this document is compatible with
the standard SIP practices for privacy described in RFC 3323 [3]. A
SIP proxy server can act both as a privacy service and as an
authentication service. Since a user agent can provide any From
header field value that the authentication service is willing to
authorize, there is no reason why private SIP URIs that contain
legitimate domains (e.g., sip:anonymous@example.com) cannot be signed
by an authentication service. The construction of the Identity
header is the same for private URIs as it is for any other sort of
URIs.
Note, however, that an authentication service must possess a
certificate corresponding to the host portion of the addr-spec of the
From header field of any request that it signs; accordingly, using
domains like ’anonymous.invalid’ will not be possible for privacy
services that also act as authentication services. The assurance
offered by the usage of anonymous URIs with a valid domain portion is
"this is a known user in my domain that I have authenticated, but I
am keeping its identity private". The use of the domain
’anonymous.invalid’ entails that no corresponding authority for the
domain can exist, and as a consequence, authentication service
functions are meaningless.
The "header" level of privacy described in RFC 3323 requests that a
privacy service alter the Contact header field value of a SIP
message. Since the Contact header field is protected by the
signature in an Identity header, privacy services cannot be applied
after authentication services without a resulting integrity
violation.
RFC 3325 [12] defines the "id" priv-value token, which is specific to
the P-Asserted-Identity header. The sort of assertion provided by
the P-Asserted-Identity header is very different from the Identity
header presented in this document. It contains additional
information about the sender of a message that may go beyond what
appears in the From header field; P-Asserted-Identity holds a
definitive identity for the sender that is somehow known to a closed
network of intermediaries that presumably the network will use this
identity for billing or security purposes. The danger of this
network-specific information leaking outside of the closed network
motivated the "id" priv-value token. The "id" priv-value token has
no implications for the Identity header, and privacy services MUST
NOT remove the Identity header when a priv-value of "id" appears in a
Privacy header.
Finally, note that unlike RFC 3325, the mechanism described in this
specification adds no information to SIP requests that has privacy
implications.
13. Security Considerations
13.1. Handling of digest-string Elements
This document describes a mechanism that provides a signature over
the Contact, Date, Call-ID, CSeq, To, and From header fields of SIP
requests. While a signature over the From header field would be
sufficient to secure a URI alone, the additional headers provide
replay protection and reference integrity necessary to make sure that
the Identity header will not be used in cut-and-paste attacks. In
general, the considerations related to the security of these headers
are the same as those given in RFC 3261 for including headers in
tunneled ’message/sip’ MIME bodies (see Section 23 in particular).
The following section details the individual security properties
obtained by including each of these header fields within the
signature; collectively, this set of header fields provides the
necessary properties to prevent impersonation.
The From header field indicates the identity of the sender of the
message, and the SIP address-of-record URI in the From header field
is the identity of a SIP user, for the purposes of this document.
The To header field provides the identity of the SIP user that this
request targets. Providing the To header field in the Identity
signature serves two purposes: first, it prevents cut-and-paste
attacks in which an Identity header from legitimate request for one
user is cut-and-pasted into a request for a different user; second,
it preserves the starting URI scheme of the request, which helps
prevent downgrade attacks against the use of SIPS.
The Date and Contact headers provide reference integrity and replay
protection, as described in RFC 3261, Section 23.4.2.
Implementations of this specification MUST NOT deem valid a request
with an outdated Date header field (the RECOMMENDED interval is that
the Date header must indicate a time within 3600 seconds of the
receipt of a message). Implementations MUST also record Call-IDs
received in valid requests containing an Identity header, and MUST
remember those Call-IDs for at least the duration of a single Date
interval (i.e., commonly 3600 seconds). Because a SIP-compliant UA
never generates the same Call-ID twice, verifiers can use the Call-ID
to recognize cut-and-paste attacks; the Call-ID serves as a nonce.
The result of this is that if an Identity header is replayed within
the Date interval, verifiers will recognize that it is invalid
because of a Call-ID duplication; if an Identity header is replayed
after the Date interval, verifiers will recognize that it is invalid
because the Date is stale. The CSeq header field contains a numbered
identifier for the transaction, and the name of the method of the
request; without this information, an INVITE request could be cut-
and-pasted by an attacker and transformed into a BYE request without
changing any fields covered by the Identity header, and moreover
requests within a certain transaction could be replayed in
potentially confusing or malicious ways.
The Contact header field is included to tie the Identity header to a
particular user agent instance that generated the request. Were an
active attacker to intercept a request containing an Identity header,
and cut-and-paste the Identity header field into its own request
(reusing the From, To, Contact, Date, and Call-ID fields that appear
in the original message), the attacker would not be eligible to
receive SIP requests from the called user agent, since those requests
are routed to the URI identified in the Contact header field.
However, the Contact header is only included in dialog-forming
requests, so it does not provide this protection in all cases.
It might seem attractive to provide a signature over some of the
information present in the Via header field value(s). For example,
without a signature over the sent-by field of the topmost Via header,
an attacker could remove that Via header and insert its own in a
cut-and-paste attack, which would cause all responses to the request
to be routed to a host of the attacker’s choosing. However, a
signature over the topmost Via header does not prevent attacks of
this nature, since the attacker could leave the topmost Via intact
and merely insert a new Via header field directly after it, which
would cause responses to be routed to the attacker’s host "on their
way" to the valid host, which has exactly the same end result.
Although it is possible that an intermediary-based authentication
service could guarantee that no Via hops are inserted between the
sending user agent and the authentication service, it could not
prevent an attacker from adding a Via hop after the authentication
service, and thereby preempting responses. It is necessary for the
proper operation of SIP for subsequent intermediaries to be capable
of inserting such Via header fields, and thus it cannot be prevented.
As such, though it is desirable, securing Via is not possible through
the sort of identity mechanism described in this document; the best
known practice for securing Via is the use of SIPS.
This mechanism also provides a signature over the bodies of SIP
requests. The most important reason for doing so is to protect
Session Description Protocol (SDP) bodies carried in SIP requests.
There is little purpose in establishing the identity of the user that
originated a SIP request if this assurance is not coupled with a
comparable assurance over the media descriptors. Note, however, that
this is not perfect end-to-end security. The authentication service
itself, when instantiated at a intermediary, could conceivably change
the SDP (and SIP headers, for that matter) before providing a
signature. Thus, while this mechanism reduces the chance that a
replayer or man-in-the-middle will modify SDP, it does not eliminate
it entirely. Since it is a foundational assumption of this mechanism
that the users trust their local domain to vouch for their security,
they must also trust the service not to violate the integrity of
their message without good reason. Note that RFC 3261, Section 16.6,
states that SIP proxy servers "MUST NOT add to, modify, or remove the
message body."
In the end analysis, the Identity and Identity-Info headers cannot
protect themselves. Any attacker could remove these headers from a
SIP request, and modify the request arbitrarily afterwards. However,
this mechanism is not intended to protect requests from men-in-the-
middle who interfere with SIP messages; it is intended only to
provide a way that SIP users can prove definitively that they are who
they claim to be. At best, by stripping identity information from a
request, a man-in-the-middle could make it impossible to distinguish
any illegitimate messages he would like to send from those messages
sent by an authorized user. However, it requires a considerably
greater amount of energy to mount such an attack than it does to
mount trivial impersonations by just copying someone else’s From
header field. This mechanism provides a way that an authorized user
can provide a definitive assurance of his identity that an
unauthorized user, an impersonator, cannot.
One additional respect in which the Identity-Info header cannot
protect itself is the ’alg’ parameter. The ’alg’ parameter is not
included in the digest-string, and accordingly, a man-in-the-middle
might attempt to modify the ’alg’ parameter. However, it is
important to note that preventing men-in-the-middle is not the
primary impetus for this mechanism. Moreover, changing the ’alg’
would at worst result in some sort of bid-down attack, and at best
cause a failure in the verifier. Note that only one valid ’alg’
parameter is defined in this document and that thus there is
currently no weaker algorithm to which the mechanism can be bid down.
’alg’ has been incorporated into this mechanism for forward-
compatibility reasons in case the current algorithm exhibits
weaknesses, and requires swift replacement, in the future.
13.2. Display-Names and Identity
As a matter of interface design, SIP user agents might render the
display-name portion of the From header field of a caller as the
identity of the caller; there is a significant precedent in email
user interfaces for this practice. As such, it might seem that the
lack of a signature over the display-name is a significant omission.
However, there are several important senses in which a signature over
the display-name does not prevent impersonation. In the first place,
a particular display-name, like "Jon Peterson", is not unique in the
world; many users in different administrative domains might
legitimately claim that name. Furthermore, enrollment practices for
SIP-based services might have a difficult time discerning the
legitimate display-name for a user; it is safe to assume that
impersonators will be capable of creating SIP accounts with arbitrary
display-names. The same situation prevails in email today. Note
that an impersonator who attempted to replay a message with an
Identity header, changing only the display-name in the From header
field, would be detected by the other replay protection mechanisms
described in Section 13.1.
Of course, an authentication service can enforce policies about the
display-name even if the display-name is not signed. The exact
mechanics for creating and operationalizing such policies is outside
the scope of this document. The effect of this policy would not be
to prevent impersonation of a particular unique identifier like a SIP
URI (since display-names are not unique identifiers), but to allow a
domain to manage the claims made by its users. If such policies are
enforced, users would not be free to claim any display-name of their
choosing. In the absence of a signature, man-in-the-middle attackers
could conceivably alter the display-names in a request with impunity.
Note that the scope of this specification is impersonation attacks,
however, and that a man-in-the-middle might also strip the Identity
and Identity-Info headers from a message.
There are many environments in which policies regarding the display-
name aren’t feasible. Distributing bit-exact and internationalizable
display-names to end-users as part of the enrollment or registration
process would require mechanisms that are not explored in this
document. In the absence of policy enforcement regarding domain
names, there are conceivably attacks that an adversary could mount
against SIP systems that rely too heavily on the display-name in
their user interface, but this argues for intelligent interface
design, not changes to the mechanisms. Relying on a non-unique
identifier for identity would ultimately result in a weak mechanism.
13.3. Securing the Connection to the Authentication Service
The assurance provided by this mechanism is strongest when a user
agent forms a direct connection, preferably one secured by TLS, to an
intermediary-based authentication service. The reasons for this are
twofold:
If a user does not receive a certificate from the authentication
service over this TLS connection that corresponds to the expected
domain (especially when the user receives a challenge via a
mechanism such as Digest), then it is possible that a rogue server
is attempting to pose as an authentication service for a domain
that it does not control, possibly in an attempt to collect shared
secrets for that domain.
Without TLS, the various header field values and the body of the
request will not have integrity protection when the request
arrives at an authentication service. Accordingly, a prior
legitimate or illegitimate intermediary could modify the message
arbitrarily.
Of these two concerns, the first is most material to the intended
scope of this mechanism. This mechanism is intended to prevent
impersonation attacks, not man-in-the-middle attacks; integrity over
the header and bodies is provided by this mechanism only to prevent
replay attacks. However, it is possible that applications relying on
the presence of the Identity header could leverage this integrity
protection, especially body integrity, for services other than replay
protection.
Accordingly, direct TLS connections SHOULD be used between the UAC
and the authentication service whenever possible. The opportunistic
nature of this mechanism, however, makes it very difficult to
constrain UAC behavior, and moreover there will be some deployment
architectures where a direct connection is simply infeasible and the
UAC cannot act as an authentication service itself. Accordingly,
when a direct connection and TLS are not possible, a UAC should use
the SIPS mechanism, Digest ’auth-int’ for body integrity, or both
when it can. The ultimate decision to add an Identity header to a
request lies with the authentication service, of course; domain
policy must identify those cases where the UAC’s security association
with the authentication service is too weak.
13.4. Domain Names and Subordination
When a verifier processes a request containing an Identity-Info
header, it must compare the domain portion of the URI in the From
header field of the request with the domain name that is the subject
of the certificate acquired from the Identity-Info header. While it
might seem that this should be a straightforward process, it is
complicated by two deployment realities. In the first place,
certificates have varying ways of describing their subjects, and may
indeed have multiple subjects, especially in ’virtual hosting’ cases
where multiple domains are managed by a single application.
Secondly, some SIP services may delegate SIP functions to a
subordinate domain and utilize the procedures in RFC 3263 [4] that
allow requests for, say, ’example.com’ to be routed to
’sip.example.com’. As a result, a user with the AoR
’sip:jon@example.com’ may process its requests through a host like
’sip.example.com’, and it may be that latter host that acts as an
authentication service.
To meet the second of these problems, a domain that deploys an
authentication service on a subordinate host MUST be willing to
supply that host with the private keying material associated with a
certificate whose subject is a domain name that corresponds to the
domain portion of the AoRs that the domain distributes to users.
Note that this corresponds to the comparable case of routing inbound
SIP requests to a domain. When the NAPTR and SRV procedures of RFC
3263 are used to direct requests to a domain name other than the
domain in the original Request-URI (e.g., for ’sip:jon@example.com’,
the corresponding SRV records point to the service
’sip1.example.org’), the client expects that the certificate passed
back in any TLS exchange with that host will correspond exactly with
the domain of the original Request-URI, not the domain name of the
host. Consequently, in order to make inbound routing to such SIP
services work, a domain administrator must similarly be willing to
share the domain’s private key with the service. This design
decision was made to compensate for the insecurity of the DNS, and it
makes certain potential approaches to DNS-based ’virtual hosting’
unsecurable for SIP in environments where domain administrators are
unwilling to share keys with hosting services.
A verifier MUST evaluate the correspondence between the user’s
identity and the signing certificate by following the procedures
defined in RFC 2818 [11], Section 3.1. While RFC 2818 deals with the
use of HTTP in TLS, the procedures described are applicable to
verifying identity if one substitutes the "hostname of the server" in
HTTP for the domain portion of the user’s identity in the From header
field of a SIP request with an Identity header.
Because the domain certificates that can be used by authentication
services need to assert only the hostname of the authentication
service, existing certificate authorities can provide adequate
certificates for this mechanism. However, not all proxy servers and
user agents will be able to support the root certificates of all
certificate authorities, and moreover there are some significant
differences in the policies by which certificate authorities issue
their certificates. This document makes no recommendations for the
usage of particular certificate authorities, nor does it describe any
particular policies that certificate authorities should follow, but
it is anticipated that operational experience will create de facto
standards for authentication services. Some federations of service
providers, for example, might only trust certificates that have been
provided by a certificate authority operated by the federation. It
is strongly RECOMMENDED that self-signed domain certificates should
not be trusted by verifiers, unless some previous key exchange has
justified such trust.
For further information on certificate security and practices, see
RFC 3280 [9]. The Security Considerations of RFC 3280 are applicable
to this document.
13.5. Authorization and Transitional Strategies
Ultimately, the worth of an assurance provided by an Identity header
is limited by the security practices of the domain that issues the
assurance. Relying on an Identity header generated by a remote
administrative domain assumes that the issuing domain used its
administrative practices to authenticate its users. However, it is
possible that some domains will implement policies that effectively
make users unaccountable (e.g., ones that accept unauthenticated
registrations from arbitrary users). The value of an Identity header
from such domains is questionable. While there is no magic way for a
verifier to distinguish "good" from "bad" domains by inspecting a SIP
request, it is expected that further work in authorization practices
could be built on top of this identity solution; without such an
identity solution, many promising approaches to authorization policy
are impossible. That much said, it is RECOMMENDED that
authentication services based on proxy servers employ strong
authentication practices such as token-based identifiers.