SIPPING WG J. Peterson
Internet-Draft NeuStar
Expires: August 15, 2005 February 14, 2005
Retargeting and Security in SIP: A Framework and Requirements
draft-peterson-sipping-retarget-00
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 15, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
Retargeting, the alteration by intermediaries of the destination of a
Session Initiation Protocol (SIP) request, is a common practice
performed during the routing of a call. Some forms of retargeting,
however, give rise to security problems and potential functional gaps
in SIP. This document provides a general framework for discussion of
the security problems relating to retargeting, and gives requirements
for mechanisms that might overcome these problems.
Peterson Expires August 15, 2005 [Page 1]
Internet-Draft Retargeting Security February 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problems with Retargeting . . . . . . . . . . . . . . . . . . 4
2.1 Legitimacy of Retargeting . . . . . . . . . . . . . . . . 5
2.2 Response Identity . . . . . . . . . . . . . . . . . . . . 6
2.2.1 The Unanticipated Respondent Problem . . . . . . . . . 7
2.3 Establishment of Security Parameters . . . . . . . . . . . 8
2.4 Consent of the UAC . . . . . . . . . . . . . . . . . . . . 10
2.5 Furtherance of Transitive Trust . . . . . . . . . . . . . 11
3. Summary of Threats . . . . . . . . . . . . . . . . . . . . . . 12
4. Benefits of Retargeting . . . . . . . . . . . . . . . . . . . 12
5. Requirements for Securing Retargeting . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 14
8.2 Informative References . . . . . . . . . . . . . . . . . . . 15
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 16
Peterson Expires August 15, 2005 [Page 2]
Internet-Draft Retargeting Security February 2005
1. Introduction
Retargeting is the process by which a SIP intermediary (such as a
proxy server) alters the Request-URI of a SIP request before it
forwards that request. A proxy server may retarget when it
determines (by accessing a location service, perhaps) that one or
more new target URIs are eligible to receive the request.
Retargeting to a contact address URI discovered by a location service
for the address-of-record in the Request-URI of a request is common.
However, proxy servers may also retarget to other proxy servers,
potentially leading to significant signaling chains between the UAC
and UAS.
When one or more new targets have been identified for a request,
RFC3261-compliant intermediaries can choose either to retarget or
redirect (i.e., send a 3xx response code) on a per-request basis.
Perhaps the most important reason for retargeting is efficiency, in
terms of overall messages required. In the simplest case (one new
target for the request is discovered):
A redirecting intermediary must send a 3xx response to the UAC.
The UAC must both acknowledge this response and send a new request
to the new target. Three messages total are required.
A retargeting intermediary sends only one message to the
destination UAS - nothing is sent back to the UAC.
However, retargeting has its downside: namely, the UAC does not know
where its request will be going. This might not immediately seem
like a serious problem; after all, when one places a telephone call,
one never really knows if it will be forwarded to a different
number, who will pick up the line when it rings, and so on. The
user-driven signaling environment of SIP, however, makes this
condition much more problematic than its analog in traditional
telephony.
Currently, RFC3261 allows retargeting to occur only under very
specific circumstances: a proxy server may retarget only if it is
'responsible' for the domain in the host portion of the Request-URI.
Unfortunately, this concept of 'responsibility' is not sufficiently
specified, and moreover, a UAC has no way of knowing which proxy
server in the network performed any retargeting. Consequently, the
UAC has no assurance at a protocol level against malicious or
misguided retargeting by intermediaries which are not 'responsible'
for the target.
In fact, RFC3261 includes a number of normative constraints on
intermediary behavior which suggest, tacitly, an authorization
relationship between the UAC and a proxy server. However, since
there is no explicit account of what exactly a UAC does and does not
Peterson Expires August 15, 2005 [Page 3]
Internet-Draft Retargeting Security February 2005
authorize a proxy server to do, there is little by way of mechanism
in SIP to chaperone proxy server behavior. Since everything that is
not prevented by mechanism tends to be permitted in practice, the
reality is that SIP proxy servers behave as if UACs have no authority
to exert any policy controls over the handling of their requests and
accordingly, the normative constraints in RFC3261 are routinely
flouted.
Unfortunately, this inability to police intermediary behavior leads
to practicable attacks against SIP and various weaknesses in the
authorization policies needed by user agents. In order to address
such problems, a UAC must be capable of implementing authorization
policies informed by questions that are, today, essentially
unanswerable, such as:
How can a UAC determine the URI that a request has eventually
reached?
How can a UAC determine which intermediary has changed the target
of the request?
This draft attempts to tease out the actual authority which a UAC
invests in a proxy server, in so far as it relates to retargeting, by
examining the negative space: the problem cases where clearly, the
UAC cannot grant permissions to intermediaries without exposing
itself to attacks or policy failures. It then provides some
requirements for a corresponding security mechanism that might
actually constrain the retargeting behavior of intermediaries in
order to improve the overall security of the protocol.
2. Problems with Retargeting
SIP is a protocol that relies on intermediaries to perform
application-layer routing functions. It is necessary for
intermediaries to perform this function in order to support an
architectural layer of indirection between the identifiers of users
(the SIP "address-of-record" or AoR) and the identifiers of devices
(SIP "contact addresses"). The mappings between these two types of
identifiers are provided by the abstract location service function of
SIP, which is accessed by proxy servers when they make forwarding
decisions. This function is essential and integral to SIP's
operation.
However, this function also makes it difficult to differentiate an
intermediary that is behaving legitimately from an attacker. If SIP
is designed in such a way that malicious attacks against the protocol
cannot be distinguished from the legitimate activities of
intermediaries, then SIP will never be securable.
Ultimately, intermediaries can discharge their responsibilities while
Peterson Expires August 15, 2005 [Page 4]
Internet-Draft Retargeting Security February 2005
giving user agents enough information to detect attacks and to make
reasonable authorization decisions. In order to understand how
intermediaries would need to behave for this to be the case, a
detailed examination of the gaps in SIP's current security story
relating to retargeting is necessary.
The problems discussed in this section exhibit the following three
qualities:
Undetectable: The originating user agent has no means of
anticipating that the condition will arise, nor any means of
determining that it has occurred until the negative consequences
have already been realized.
Unpreventable: There is no existing security mechanism that might
be employed by the originating user agent in order to guarantee
that the condition will not arise.
Entailed by retargeting: If retargeting did not exist, this
problem would not arise.
2.1 Legitimacy of Retargeting
RFC3261 allows retargeting to occur only if the retargeting
intermediary is responsible for the domain indicated by the
Request-URI of the request. For example, if a request was sent to
sip:bob@example.com, then a proxy server at example.com would be
authorized to retarget the request, but a proxy server at example.org
would not be authorized to retarget the request.
However, RFC3261 offers no way to enforce this rule. There is no way
for the UAC or UAS to detect which intermediary retargeted a request.
Accordingly, if due to local policy a UAC were forced to send its
request through a proxy server example.org on its way to the proxy
server at example.com, the example.org proxy server might malicious
retarget the request to, say, a user at example.org, and the UAC
would have no way to determine that example.com had not authorized
this retargeting.
The rule in RFC3261 is intended to combat various forms of service
hijacking. The domain in the Request-URI is permitted to retarget
because it presumably has a business relationship with the target
user, since that user can provision its local service with
registrations or other administrative means. Other domains, however,
have no such relationship with the target user, and might retarget to
their own advantage. If we imagine that example.org is a hotel, for
example, the example.org proxy server might retarget requests for
various local pizza shops (sip:orders@pizza.example.com) to a
specific, preferred pizza shop (sip:orders@pizza.example.net) with
which the hotel enjoys an underhanded business arrangement.
Peterson Expires August 15, 2005 [Page 5]
Internet-Draft Retargeting Security February 2005
Nothing will be able to prevent intermediaries from changing the
Request-URI of a SIP request. It is impossible to provide integrity
protection over the Request-URI because there are cases where it
changes of necessity (such as intradomain routing of GRUUs and so
on). However, if it were possible to determine which proxy server
was responsible for changing the target of the request, the UAC could
abandon requests that have been maliciously mishandled and perhaps
take up some recourse against the misbehaving domain. As it stands,
since the condition in undetectable, domains might engage in this
behavior without fear of reproach.
2.2 Response Identity
When Alice sends a request to Bob, Bob may want to send a secure
response back to Alice. What is the purpose of a secure response?
Bob secures his response so that Alice can make certain authorization
and policy decisions based on the security of the response. Usually,
this requires at least providing integrity protection over the
response (as a whole or in part) and providing cryptographic
authentication of the sender of the response. Alice might accept the
response, or perhaps discard it, on the basis of those security
properties. In the absence of this authentication and integrity, it
might be possible for a third-party attacker, whom we'll call Edgar,
to eavesdrop on the request, and forge their own response
(impersonating Bob) with an inappropriate response code, or
inappropriate SDP answer, or what have you.
In most respects, a security mechanism to defeat this impersonation
threat in responses would be very similar to a comparable mechanism
for requests - except for the problem of retargeting. If Alice's
request to Bob were retargeted to Carol, and Carol wished to send a
secure response to Alice, this can create a number of headaches for
existing security practices.
The first, and perhaps most important, problem is that Carol's domain
may not be the domain to which Alice sent the request. Any
authentication or integrity provided by a solution like sip-identity
[6] would require a signature over the response by the responding
domain. If Alice sent the request to sip:bob@biloxi.example.com, and
the request is retargeted to sip:carol@cleveland.example.org, then an
identity service in Carol's domain, clearly, would not be able to
sign for the domain in the To header field of the request and
response (which would be biloxi.example.com). This is called the
response identity problem (although this problem also arises for
requests sent in the backwards direction within a dialog).
The root problem here is, of course, that the To header field of the
request and response does not contain the identity of the actual
Peterson Expires August 15, 2005 [Page 6]
Internet-Draft Retargeting Security February 2005
respondent. In these cases, Carol's domain cannot provide an
identity signature, and accordingly responses cannot be secured when
retargeting has occurred. This creates opportunities for
eavesdroppers to launch impersonation attacks in responses.
The solution space for this problem generally involves providing an
identity for the respondent which the responding domain can sign.
There are a number of ways this might be achieved; one common
suggestion is that some kind of supplemental identity field,
colloquially known as the 'connected party' field, should be added to
responses in order to identify the party that was actually reached.
Presumably, this field would be understood to clobber the value in
the To header field of responses and represent the genuine identity
of the respondent. However, this sort of solution gives rise to a
new class of 'unanticipated respondent' problems.
2.2.1 The Unanticipated Respondent Problem
When retargeting has occurred, the respondent to a request may not be
identified by the To header field of the request and response. For
example, the To header field of a request may designate
sip:bob@biloxi.example.com, but an intermediary may retarget that
request to sip:carol@cleveland.example.org. That request might then
land at a UAS controlled by Carol, and Carol may be the respondent to
that request.
In this case we would say that Carol is the 'connected party'. In
order to provide secure responses to Alice's request, one could argue
that the 'connected party' information, i.e., some URI that
identifies Carol, should be communicated to Alice in responses. This
would let Alice know that some party other than the anticipated party
(Bob) was reached by the request, and give her an identity of this
unanticipated party. This information could then be
cryptographically signed by the responding domain, presumably
resolving any concerns about providing response identity.
The problem is that Edgar the eavesdropper can do the same thing that
Carol just did. That is, Edgar can construct a response with a
'connected party' value indicating himself. He can even get his
domain (evil.example.net) to sign that 'connected party' value. When
Edgar sends the response back to Alice, how can Alice tell the
difference between his forged reply and Carol's legitimate reply?
Ironically, 'connected party' does not provide any new leverage
against the very problem that response identity is supposed to solve
- preventing an eavesdropper from sending a forged reply.
The reason why this is true is because allowing unanticipated
respondents makes Alice's authorization decisions very complicated.
Peterson Expires August 15, 2005 [Page 7]
Internet-Draft Retargeting Security February 2005
If Alice authorize is to authorize some set of respondents other than
Bob to reply to her request, how does she arrive at that set? In the
current retargeting regime, Alice has no way of knowing what targets
might be selected for her request by an intermediary, and
accordingly, she has no choice but to accept any respondents that
contact her.
What is needed to address the response identity and unanticipated
respondent problems, then, is a mechanism by which Alice can learn
the set of targets which might be respondents to her request. This
information would need to come from the domain that is changing the
target of the request. In other words, when Alice sends a request to
sip:bob@biloxi.example.com, biloxi.example.com would tell Alice that
it was redirecting her request to sip:carol@cleveland.example.org.
Alice could then set an authorization policy for this transaction
that would only accept responses coming from Carol. This would allow
Alice to tell the difference between a legitimate target of the
request and an attacker.
The major distinction between this explicit indication to the UAC of
a change of target and the traditional concept of 'connected party'
is the source of the indication - 'connected party' assumes that the
respondent or respondent's domain provides the identity of the
respondent. The requirement articulated here is that the domain that
changes the target provides the new target for the request. Of
course, it is possible that the target of the request will change
several times during the routing of a request; in that case, several
such indications would need to be given to the UAC by the mechanism
so that a complete chain can be formed from the original form of the
Request-URI to the final target.
Note that the considerations above treat 'connected party' only as it
relates to security and response identity; some have argued that
'connected party' is a nice feature to have in an environment with
retargeting even if it were inert from a security perspective.
2.3 Establishment of Security Parameters
Consider a case where Alice and Bob would like to share a voice
conversation over the Internet which is secured by sRTP. In order to
do so, Alice must generate a session key that will be used to encrypt
media sent to her and place that session key inside an SDP offer.
She must then send that offer to Bob in an INVITE. If the body of
that invite is not encrypted, however, an eavesdropper might learn
her symmetric key and use it to decrypt the media sent to her by Bob.
Accordingly, she must learn a public key for Bob, and use that key to
encrypt her SDP offer. One manner in which she might learn a public
key for Bob is described in the certs [7] draft.
Peterson Expires August 15, 2005 [Page 8]
Internet-Draft Retargeting Security February 2005
What happens if Alice's request to Bob is retargeted to Carol? Since
Carol does not (and should not) possess the private key corresponding
to Bob's public key, she would send some sort of failure response
code (perhaps a 493 Undecipherable). Carol and Alice might then
reconnect in any of a number of ways; the manner suggest in RFC3261
is that Carol will return her certificate in the body of the 493
response, and the Alice will re-initiate the session, encrypting with
Carol's certificate.
Retargeting gives rise to a couple of problems here. One is just a
variant of the previously-discussed 'unanticipated respondent'
problem - Alice has no way of knowing if Carol is actually an
attacker who sends a 493 in order to bid-down the security for the
ensuing RTP session [note: this is a very serious problem, and is
only being de-emphasized here because an essentially identical
problem has already been discussed above]. But even beyond
determining whether the 493 should be accepted, recovery from a 493
is awkward and fraught with risks because the scope of the key
returned in the 493 is ambiguous when retargeting has occurred. When
Alice receives a 493, whose key does she think she is learning from
the body? What if Alice re-initiates her request, this time with the
body encrypted with Carol's key, but the new request lands on a UA
controlled by Bob? These cases are especially problematic when
Carol's key is self-signed.
Ultimately, the very potential for retargeting significantly
discourages the use of confidentiality in SIP. Since Alice cannot
anticipate when retargeting will occur, she cannot anticipate when
she should expect an encrypted message to be accepted. The
complexity of managing 493 responses and making the resulting
authorization decisions and re-initiated messaging exchanges is
fairly prohibitive.
The 'connected party' mindset would suggest that Carol should
disambiguate the 493 by providing her identity along with the
certificate, informing Alice to re-originate the quest directly to
Carol and encrypt with Carol's key. In this case, the 493 would
behave something like a 3xx response, redirecting Alice's request
from Bob to Carol. The problem with this approach is the same as the
comparable 'connected party' problems above - the respondent is not
the one authorized to retarget the request, and accordingly, the
respondent should not be the one to tell the UAC the request's new
target.
This whole class of failure would be preventable if Alice were able
to guess who would eventually receive her request. Since Alice can't
access the location service at the domain which her request targets,
though, she has to rely on that domain to tell her. If the
Peterson Expires August 15, 2005 [Page 9]
Internet-Draft Retargeting Security February 2005
intermediary that changed the target of the request could know,
hypothetically, that Alice would need to rekey her request if the
target changes, it could avoid the whole step of forwarding the
retargeting the request to Carol and simply tell Alice (through a 3xx
or something comparable) that Carol is the new target.
While the example given here is specific to keying, there are a
number of ways in which a request might need to be modified if its
destination were to change.
2.4 Consent of the UAC
Alice may be friends with Bob, but not at all cordial with Bob's
friend Carol. If Bob configures his SIP service to forward messages
to Carol, then Alice might reach Carol when she sends a request to
Bob. While the consequences of this for an INVITE might not be so
bad (Alice could hang up when she hears Carol's voice, or what have
you), some SIP requests (such as the MESSAGE method) contain content
that might be viewed by the recipient without any further activity on
the part of the sender.
. Because this sort of problem is a fact of life in the existing
telephone system, it might seem unavoidable for SIP. However, there
are Internet systems where this class of problem doesn't arise. One
example would be the ad-blocker software built into web browsers.
When a web browser with an ad-blocker downloads a page, it inspects
the list of hyperlinks on the page and determines if any of them
contain a blacklisted domain known to be associated with an
advertiser. Those hyperlinks are never traversed. Ultimately, this
works because HTTP has an endpoint consent model - when you access a
web resource, it tells you what related resources you might want to
access rather than pre-emptively accessing related resources on your
behalf.
In fact, retargeting is the reason why SIP does not have an endpoint
consent model. The lack of an endpoint consent model prevents user
agents from exercise valuable authorization policies. Consider the
question of how a blacklist might operate. If we imagine that Alice
hates Carol, then Alice might add Carol to her user agent's
blacklist. Whenever Carol calls Alice, the blacklist is
automatically consulted for an authorization decision and Alice's
user agent rejects, politely or impolitely, the session initiation
request. When Alice places a call, though, she has no control over
the target set that will be selected for the call. If Carol is
selected by a retargeting intermediary, then Alice will be put in
contact with Carol against her will; effectively, this circumvents
Alice's blacklist. Of course, if the intermediary sent a redirection
Peterson Expires August 15, 2005 [Page 10]
Internet-Draft Retargeting Security February 2005
At a high level, the main problem is when retargeting occurs, new
targets are chosen by an intermediary without the consent of the UAC.
By sending a request to a proxy server, the UAC is essentially giving
"implied consent" that the request can be retargeted arbitrarily. To
remedy this authorization policy defect, the UAC would have to have
some ability to review the new targets for a request that have been
chosen by an intermediary, and decide which of these targets it might
want to pursue or not pursue before the request is forwarded to a new
target.
If the UAC does not learn the new target until the respondent
responds (i.e., the 'connected party' approach), this will be of
little help when the response is an acknowledgment of a MESSAGE
request that is grossly inappropriate for the recipient.
2.5 Furtherance of Transitive Trust
At a higher level, retargeting is also a source of transitivity for
SIP. This is not in and of itself a direct threat, but an overall
negative implication for the security model.
If Alice sends a request to sip:bob@biloxi.example.com, and that
request is retargeted by biloxi.com to
sip:carol@cleveland.example.com, it places Alice at a significant
disadvantage if she received a Digest authentication challenge
response (i.e., a 407) from cleveland.example.com. Per RFC3261
26.3.2.1, the establishment of a direct connection to a challenging
proxy allows the UAC to compare the subject of the site certificate
presented by that proxy via TLS with the "realm" parameter used in
Digest authentication. A correspondence between the two provides
reference integrity - it ensures Alice that the challenge she is
receiving from the realm 'cleveland.example.com' is actually coming
from a proxy server at 'cleveland.example.com' rather than an
imposter trying to capture her Digested credentials (which might then
be attacked offline).
If biloxi.com retargets and proxies the request, Alice will only have
established a connection to biloxi.example.com, and thus she will
have no may to match the challenge she received against the
certificate of cleveland.example.com. If biloxi.example.com
redirects, however, Alice can form her own TLS connection to
cleveland.example.com to make this determination. Effectively, Alice
must rely on Bob's domain to relay messages to and from Carol's
domain faithfully, and if there is something suspicious about the
response, Alice will not be able to determine authoritatively if
Bob's domain or Carol's domain is responsible. In this sense,
retargeting has put Alice into a position of increased transitive
trust.
Peterson Expires August 15, 2005 [Page 11]
Internet-Draft Retargeting Security February 2005
3. Summary of Threats
In terms of the typical Internet threat model, the sorts of threats
described above require a relatively high level of sophistication in
an attacker. In order for an attacker to impersonate a respondent,
for example, the attacker must be able to capture dialog identifying
parameters (which entails inspecting SIP signaling in transit),
create plausible responses on the fly, insert this responses back
into the signaling stream (or make it appear so to the originator
through various forms of spoofing), and possibly squelch legitimate
responses that might alert the originator to malfeasance. This
essentially requires the attacker to be a man-in-the-middle. The use
of judicious channel security, such as TLS, between proxy servers can
prevent eavesdropping and many forms of signaling insertion or
squelching.
Unfortunately, in order to police the behavior of proxy servers
themselves, however, one must guard against precisely that: a
man-in-the-middle. The primary attacker envisioned by this draft is
an intermediary which is legitimately within the path of SIP
signaling.
In summary, the threats that have been discussed in this section
include:
Service hijacking: Unscrupulous domains can retarget requests,
disobeying the rules of RFC3261, without significant risk of
detection.
Insecure responses: When retargeting has occurred, traditional
signatures cannot be applied to SIP responses because the identity
of the sender is not reflected in the response. Modifying
responses in order to communicate the identity of the sender does
not seem to fix the problem.
Confidentiality problems: It is easy to bid-down attempts to use
confidentiality in SIP message bodies, and when SIP responses are
used as a key distribution mechanism, retargeting makes the
intended scope of those keys ambiguous.
Circumvention of blacklists: Retargeting can cause a SIP user
agent to come into contact with an entity that has been
blacklisted.
Rampant transitivity: Retargeting increases the amount of
indirection between the originating user agent and various
intermediaries and endpoints with which it might need to establish
a security relationship.
4. Benefits of Retargeting
Given that an intermediary has two different ways that it can choose
Peterson Expires August 15, 2005 [Page 12]
Internet-Draft Retargeting Security February 2005
to change the target of a request - redirection and retargeting -
what are the advantages of retargeting over redirection?
Messaging Efficiency: Instead sending a response back to the UAC
whenever the target needs to change, intermediaries just forward
the request. This can be significant in environments where UACs
are constrained in terms of computational power or bandwidth.
However, it can significantly increase the amount of signaling and
state that an intermediary needs to manage, especially in forking
cases.
Target set privacy: If an intermediary discovers more than one
potential target for a request, then the policy of the original
target user may favor concealment of the whole target set from the
UAC. In retargeting cases, a certain amount of information about
the new target would be revealed in successful responses (the
Contact header and so on), but unresponding targets would be
totally hidden from the UAC. Redirection of course discloses the
target set to the UAC.
Target set ordering policy: If there is more than one possible
target for a request, an intermediary can guarantee strict
ordering of the target set by performing sequential forking
itself. If the intermediary redirects to the UAC, it may use
qvalues to suggest and ordering, but it has no guarantee that the
ordering will be followed.
Dialog control: By redirecting a dialog-forming request, an
intermediary may put itself out of the loop of future signaling in
the dialog. When an intermediary retargets a request, it may add
a Record-Route header and thus remain in the path of future
messages in the dialog.
NAT traversal: In some cases, an intermediary that changes the
target of a request is, in fact, the one SIP entity that can
contact the new target. If, for example, the new target is behind
a NAT, and maintains a persistent TLS connection to the
retargeting intermediary, any requests heading to the target must
go through the intermediary.
The most important question about these benefits is the following:
are they genuinely achievable only if retargeting transpires, or can
they replicated via redirection? For example, the ordering of a
target set can be preserved if the targets are shared via redirection
one at a time with the UAC (though this will substantially decrease
messaging efficiency). Many other effects, including privacy, dialog
control, and even NAT traversal can be replicated by redirecting to
an synthetic target (like a GRUU or an anonymized URI) which
dereferences to an intermediary under the control of the retargeting
domain.
Peterson Expires August 15, 2005 [Page 13]
Internet-Draft Retargeting Security February 2005
5. Requirements for Securing Retargeting
In an ideal world, it would be possible for a UAC to have a strong
assurance that intermediaries were behaving properly, and furthermore
to have the capability to differentiate between properly-behaving
intermediaries and attackers.
It MUST be possible for a UAC to detect when a request has been
retargeted.
A domain that changes the target of a request MUST be capable of
informing the UAC of the new target(s).
The mechanism MUST allow simple intradomain retargeting in cases
where persistent TLS connections are used as a NAT traversal
mechanism.
It must be possible for a domain that changes the target of a
request to inform the UAC of the new target(s) prior to contacting
any of the new target(s). There MUST furthermore be a way for
intermediaries to determine when UACs require prior information
about new targets.
It MUST be possible to preserve the privacy of targets and
potential targets of requests.
It MUST be possible to preserve the ordering of a target set
desired by the domain that changes the target of a request.
6. Security Considerations
This document provides a framework and requirements for addressing an
important gap in SIP's existing security practices.
7. IANA Considerations
This document contains no considerations for the IANA.
8. References
8.1 Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002.
[2] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, March 1997.
[3] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
Peterson Expires August 15, 2005 [Page 14]
Internet-Draft Retargeting Security February 2005
[5] Peterson, J., "Session Initiation Protocol (SIP) Authenticated
Identity Body (AIB) Format", RFC 3893, September 2004.
[6] Peterson, J., "Enhancements for Authenticated Identity
Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-04 (work in progress), February 2005.
[7] Peterson, J. and C. Jennings, "Certificate Management Service
for SIP", draft-ietf-sip-certs-01 (work in progress), February
2005.
8.2 Informative References
Author's Address
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA 94520
US
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Appendix A. Acknowledgments
Peterson Expires August 15, 2005 [Page 15]
Internet-Draft Retargeting Security February 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Peterson Expires August 15, 2005 [Page 16]