SIP WG V. Gurbani
Internet-Draft A. Jeffrey
Expires: December 28, 2006 Lucent Technologies, Inc./Bell
Laboratories
June 26, 2006
Domain Certificates in the Session Initiation Protocol (SIP)
draft-gurbani-sip-domain-certs-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 December 28, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document attempts to clarify the use of domain certificates in
the Session Initiation Protocol (SIP). Currently, there is much
ambiguity surrounding domain -- or site -- certificates.
Gurbani & Jeffrey Expires December 28, 2006 [Page 1]
Internet-Draft Domain Certs June 2006
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . 3
4. A Possible Solution to Conveying the Peer Identity . . . . . 4
5. Registrars and Redirect Servers . . . . . . . . . . . . . . 5
6. Proxy Servers, Identities and SIP Headers . . . . . . . . . 6
7. Server Farms and Certificate Content . . . . . . . . . . . . 8
7.1 Choosing a Server in the Proxy Farm . . . . . . . . . . . 9
7.2 Authenticating a Server From the Proxy Farm . . . . . . . 9
8. Virtual SIP Servers and Certificate Content . . . . . . . . 10
9. Wildcards in dNSName Type . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . 11
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1 Normative References . . . . . . . . . . . . . . . . . . 13
12.2 Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
A. Retargetting in SIP . . . . . . . . . . . . . . . . . . . . 14
B. Retargetting and Identity . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . 18
Gurbani & Jeffrey Expires December 28, 2006 [Page 2]
Internet-Draft Domain Certs June 2006
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
2. Introduction
Transport Layer Security (TLS) [3] has started to appear in an
increasing number of Session Initiation Protocol (SIP) [2]
implementations. TLS depends on the Internet X.509 Public Key
Infrastructure [4] for its proper use and function.
Despite the appearance of TLS in SIP implementations, an enduring
question has remained regarding the contents of the certificates for
domain verification. We hope that the discussion in this document
provides some guidelines in this area. Moreover, TLS by itself only
provides security guarantees for the transport layer. In this
document, we also discuss the requirements of SIPS message processing
to ensure that these security guarantees are also provided at the
application layer.
The discussion in this document is pertinent to a certificate used
for a TLS connection. It may not apply in its entirety to a
certificate used in S/MIME, for instance.
3. Problem Statement
Put succinctly, the problem can be summarized as how should hosts be
identified in a certificate that purports to authoritatively
represent a domain from which a request is being sent from, or a
domain to which a request is being sent to? Not surprisingly, the
answer has varied depending on the exact assumptions under
consideration.
In SIP, proxy servers, redirect servers, and registrars must posses
domain certificates by which their identity is conveyed in an
authoritative fashion to a client. Conversely, a proxy server in
particular, accepting inter-domain requests from other proxy servers
may ask of equivalent domain certificate from its peer. As such, a
domain certificate must provide two pieces of identification. First,
it must provide an assurance the peer presenting the certificate is
an authority for the domain, and second, since TLS in SIP is defined
on a hop-by-hop basis, the certificate must also convey the identity
of the host that presents the certificate. It is conceivable that
the latter identification be made optional; however, an explicit
binding in this fashion is preferable to implicitly assuming that a
certificate presented that does not contain the canonical name of the
Gurbani & Jeffrey Expires December 28, 2006 [Page 3]
Internet-Draft Domain Certs June 2006
host does indeed belong to the said host. TLS connections are made
between individual hosts, thus conveying the identity of the host
directly in the certificate in the form of a canonical host name
provides a strong guarantee that the host is indeed who it purports
to be.
4. A Possible Solution to Conveying the Peer Identity
A TLS client connecting to a TLS server, and a TLS server who has
received a certificate from a TLS client need to ensure that the
identity of the peer is contained in the certificate. Traditionally,
the identity of the peer in the form of a domain name was carried in
the Common Name field of the Subject field. However, RFC 3280 [4]
has mandated that such identities now be carried in the
subjectAltName extension.
Accordingly, the recommendations of the SIP working group have been
to populate the X.509v3 subjectAltName extension. However, this is
underspecified in RFC 3261, which mentions subjectAltName in
conjunction with S/MIME only and not TLS. For S/MIME certificates,
the subjectAltName provides additional identities of the certificate
holder, some in the form of a SIP URI. RFC 3261 does not provide any
guidelines on the use of subjectAltName for TLS certificates. As a
result, some implementations populate only the Common Name field of
the Subject field with a domain name, and others populate only the
subjectAltName extension, while still others populate both. This
leads to problems when attempting to interpret the certificate
contents in a uniform manner.
As a possible answer to the problem of conveying identity described
above, it seems appropriate that TLS certificates contain two
identities in the subjectAltName X.509v3 extension. The first
identity would be a Uniform Resource Identifier (URI), more
specifically, a SIP URI. This URI corresponds to the name of the
domain over which that certificate is asserting its authority (e.g.,
"URI:sip:example.com"). The second identity would correspond to a
domain name system label, more specifically, the canonical name of
the host (e.g., "DNS:proxy-1.example.com") to who the certificate
belongs.
Note that RFC 3261 states that "Proxy servers, redirect servers
and registrars SHOULD possess a site certificate whose subject
corresponds to their canonical hostname." (Section 26.3.1)
The notion that a domain certificate contains, at the very least, the
two identities mentioned above is well worth consideration and
further discussion. It solves the problem identified in Section 5.1
of [8], as well as satisfy the RFC 3261 concept on what should be
Gurbani & Jeffrey Expires December 28, 2006 [Page 4]
Internet-Draft Domain Certs June 2006
contained in a site (or domain) certificate (Section 26.3.1 of RFC
3261, quoted above).
As an example, consider that the autonomous domain example.com is
applying for a certificate from an authority. As part of the
certificate request, it will ask the following two identities be
bound to the generated certificate: "URI:sip:example.com", and "DNS:
proxy-1.example.com". The former (domain) URI asserts the ownership
of the domain to the holder of the certificate, and the latter (host)
URI identifies the particular host on hop-by-hop TLS connections.
Aspects of this document have been discussed on the SIP working group
mailing list and some consensus appears to be coalescing around how
to identify a downstream server when the said server presents a
certificate upon contact. More specifically, when a client asks for
a certificate from the server, and receives one, the certificate must
assert an identity corresponding to the name that the client
performed a RFC3263-type resolution on. A certificate asserting an
identity of "sip:example.com" provides a sufficient anchor for
identifying the said server if the client was attempting to connect
to a Request-URI (R-URI) (or the URI in the topmost Route header, if
one existed) that contained a domainname of "example.com". In this
direction (i.e., the server presenting a certificate for
verification), it is not absolutely required to search for a
canonical hostname as an identity in the certificate (i.e., if
RFC3263 leads to the choice of "proxy-1.example.com", then it is not
necessary to specifically look for a dNSName SAN extension matching
this canonical name). In fact, certain deployments specifically
forbid this (SIP Identity [9] mentions an example of RFC3263
resolution on "sip:jon@example.com" leading to a service located at
"sip1.example.org").
For the remainder of this document, the term "domain URI" will be
used to describe the identity contained in the subjectAltName URI of
the form "URI:sip:example.com", and the term "host URI" will be used
to describe the identity (canonical hostname) contained in the
subjectAltName domain name system label of the form "DNS:proxy-
1.example.com".
5. Registrars and Redirect Servers
The identities in the certificate are leveraged by clients to
authenticate the registrars and redirect servers they are connecting
to. When a client forms a TLS connection to a registrar, it will be
presented with a certificate corresponding to the registrar. To
assure the client that it is indeed conversing with the correct
registrar, the domain URI in the certificate should matches the R-URI
the client was trying to reach (in a REGISTER request, the R-URI
Gurbani & Jeffrey Expires December 28, 2006 [Page 5]
Internet-Draft Domain Certs June 2006
typically names the location service for which the registration is
meant, for example, "REGISTER sip:example.com").
Note that this only works as intended if the client and the
registrar are in the same domain. If the client is in a visited
network, it may have to go through a chain of TLS intermediaries
in order to reach its home registrar, and thus it may not be able
to directly access the certificate of the home registrar or to
open a TLS connection to it.
In SIP, redirect servers are used in lieu of proxy servers to offload
the processing of a request to the client. As such, the steps that a
client would normally use to ascertain the identity of a proxy server
are just as applicable when identifying a redirect server. These are
outlined in the next section.
Needless to say, registrars and redirect servers should authenticate
the clients as well. This can be done by asking for a X509
certificate of the client if the client possesses one, or by other
means such as HTTP Digest authentication.
6. Proxy Servers, Identities and SIP Headers
For the following discussion, assume the standard SIP trapezoid shown
in Figure 1:
P1 ------------------ P2
(proxy.example.com) (proxy.biloxi.com)
V V
/ \
/ \
/ \
/ \
User Agent User Agent
(sip:alice@example.com) (sip:bob@biloxi.com)
Figure 1: Traditional SIP Trapezoid
P1 establishes a TLS connection to P2 on behalf of the sender of the
request, Alice. P1 is presented with P2's certificate. P1 must
ensure that the certificate is not expired and is rooted in a trusted
hierarchy. Next, P1 compares the domain URI in the certificate
against the domainname in the next hop URI -- which could be the
R-URI or the topmost Route header -- and looks for a match. If they
Gurbani & Jeffrey Expires December 28, 2006 [Page 6]
Internet-Draft Domain Certs June 2006
match, P1 can be certain that P2 adequately represents the biloxi.com
domain. Note that under some circumstances, the next hop URI may not
contain contents that will be amenable to an RFC3263-type of
resolution; it may contain a fully-qualified domain name instead of
an identifier that would normally be used as input to the RFC3263
process. In such cases, having the host URI in the certificate is a
help since P1 can match the host URI in the certificate to the next
hop URI to gain confidence in the veracity of the connection.
P2 may ask of a certificate from P1. Since P1 is a proxy, it has a
certificate, which it presents to P2. P2 now proceeds to do mutual
authentication of P1. It should ensure that the certificate is not
expired and is rooted in a trusted hierarchy. Additionally, because
of the transitive trust nature of TLS connections in SIP, the only
attribute that P2 can absolutely depend on verifying of P1 is that it
(i.e., P1) represents a host in the example.com domain. To this
extent, matching the topmost Via sent-by with one of the URIs in the
SAN of the presented certificate will give P2 the confidence
regarding adequate representation of the example.com domain by P1.
Note that RFC3261 Section 26.3.2.2 essentially allows P2 to match
the domainname in the P1's certificate with the domainname of the
From header field in the INVITE request for mutual verification.
This, however, may not always work due to retargetting since in
this case the From header will not correspond to the
administrative domain from which the request has been proxied (see
Appendix A). Furthermore, the From header may contain an
alternative URI such as the tel URI instead of SIP or SIPS URI.
Thus, other techniques such as examining the Via trail may
additionally be used.
Since the issuance of RFC3261, the SIP WG has also expanded
considerable resources in SIP Identity [9]. SIP Identity makes it
possible for a sending domain to authoritatively assert the
originator of a SIP message. This mechanism is much more robust
that ensuring that the domainname in the From header matches the
one stored in the certificate. The minor irritant in SIP Identity
and per-hop transitive nature of TLS connections means that if P2
gets a request from P1 over a TLS connection, and this request has
an Identity header (and Identity-Info header), P2 cannot assume
that P1 inserted those headers. Some other element upstream of P1
could have inserted them (these headers are not removed by
intermediaries; see Appendix B). Thus, it appears that the Via
sent-by is the only appropriate SIP header that can be used by P2
to provide it adequate confidence regarding representation of the
example.com domain by P1.
Gurbani & Jeffrey Expires December 28, 2006 [Page 7]
Internet-Draft Domain Certs June 2006
7. Server Farms and Certificate Content
In many deployments, a bank of SIP servers are logically treated as
one SIP entity. Such clusters of SIP servers, or server farms, are
routinely used for load balancing and reliability. Server farms have
an interesting intersection with the identities stored in
certificates. Generally speaking, it seems appropriate to have at
least two identities stored in the certificate. One would correspond
to a top level URI and the other one would be specific to that host.
The following discussion outlines this in more detail.
Figure 2 contains a proxy farm consisting of two SIP servers. This
farm is identified by an advertised address of "example.com", i.e.,
any request that emanates from this farm has a sent-by value of
"example.com". Conversely, any requests destined to this farm is
done by performing a RFC 3263 [5] resolution of the domain name
"example.com".
+-----------+ +-----------+ +---------+
| | | | | |
| host-a1 | | host-a2 | | Proxy B |
| 192.0.2.1 | | 192.0.2.2 | | |
+-----------+ +-----------+ +---------+
|________________________________| |_____________|
example.com biloxi.com
Figure 2: A Server Farm.
Here is a partial DNS zone file corresponding to the above farm.
$ORIGIN example.com.
; order pref. flags service regexp replacement
NAPTR 100 50 "s" "SIPS+D2T" "" _sips._tcp.example.com.
;; pri. weight port target
_sips._tcp.example.com. IN SRV 0 1 5061 host-a1.example.com.
IN SRV 0 1 5061 host-a2.example.com.
host-a1 A 192.0.2.1
host-a2 A 192.0.2.2
Now, assume that each server in the farm has a unique certificate
that contains two identities of type dNSName in subjectAltName
extension. The first one is "DNS:example.com" and the second
Gurbani & Jeffrey Expires December 28, 2006 [Page 8]
Internet-Draft Domain Certs June 2006
identity corresponds to the actual host name. The two identities
work in concert to provide the appropriate identification and
authentication to hosts outside the server farm.
7.1 Choosing a Server in the Proxy Farm
When a SIP server outside the server farm wants to choose a server
from the farm, it will follow the normal RFC 3263 [5] resolution
process to find an appropriate server. In Figure 2, consider that
Proxy B wants to choose one of the two servers in the farm. Let's
assume that it executes the RFC 3263 server resolution process and
arrives at a choice of host-a1.example.com. It now makes a TLS
connection to host-a1.example.com and is presented with a certificate
from host-a1.
Proxy B must ensure that the canonical host name that it used to
establish the connection -- host-a1.example.com -- appears as one of
the identities in the subjectAltName extension. If this is not the
case, then the connection must be closed and the authentication of
the server from the proxy farm would be considered to have failed.
It goes without saying that host-a1.example.com must mutually
authenticate Proxy B. If Proxy B itself is a cluster of proxies, then
the steps in the next section can be applied to the authentication of
Proxy B.
7.2 Authenticating a Server From the Proxy Farm
When any of the servers in the farm establish a TLS connection to
Proxy B in a different administrative domain (biloxi.com), they
should be prepared to present a certificate if asked by Proxy B. For
the sake of this discussion, assume that proxy B asks for a
certificate when it accepts a TLS connection.
Proxy B now has the certificate of one of the host from the server
farm. Proxy B also has a SIP request that contains the following
topmost Via header ("received" parameter has been added by Proxy B):
Via: SIP/2.0/TLS example.com;branch=z9hG4bK7cx8177;
received=192.0.2.2
To authenticate the host in the server farm that sent the request,
Proxy B follows the following logic:
1. Verifies that the certificate presented is not expired and that
it is rooted in a trusted certificate chain.
Gurbani & Jeffrey Expires December 28, 2006 [Page 9]
Internet-Draft Domain Certs June 2006
2. Void.
3. Resolve the "sent-by" by performing a DNS SRV lookup for service
"_sips" and transport "_tcp". If this fails, go to Step 5.
Otherwise, this will result in one or more relevant A/AAAA
records. Ensure that one of these records resolves to the IP
address in the "received" parameter.
4. If the "sent-by" had a non-default port number, then this port
number must match the port number corresponding to the A record
that matched in the above step. Got to step 7, authentication is
successful.
It is open to discussion whether the port number should be
used in the matching rule.
5. If DNS SRV lookup failed, then chances are that the contents of
the "sent-by" contain a canonical host name. Thus, this name
must match the host URI stored in the certificate. If there is
no match, the connection should be closed and processing proceeds
to step 7; authentication has failed.
6. If the host name in "sent-by" matches the host URI stored in the
certificate, then ensure that it resolves to the IP address in
the "received" parameter. If so, authentication is successful,
otherwise it has failed.
Note: This is open to discussion since it allocates a lower
probability of a compromised DNS when compared to a
compromised certificate.
7. Process is complete.
Open issue: Will all of this work if the proxy farm is behind a NAT?
In that case, P1 will add a "received" parameter that corresponds to
the IP address of the middlebox and not that of the appropriate
server from the proxy farm.
Open issue: Will all of this work if the proxy farm is behind a TLS
accelerator? This is similar to the problem of NATs, but the
certificate is issued to the accelerator, not to the proxy.
8. Virtual SIP Servers and Certificate Content
The closest guidance in SIP today regarding certificates and virtual
SIP servers occurs in SIP Identity ([9], Section 13.4). The quoted
section states that, "... certificates have varying ways of
describing their subjects, and may indeed have multiple subjects,
especially in the 'virtual hosting' cases where multiple domains are
managed by a single application."
This appears to imply that one certificate will have multiple SANs
(or Subject) fields, each such field corresponding to a discrete
virtual server that represents a single domain? Since only one
certificate is needed for multiple domains, the keying material
Gurbani & Jeffrey Expires December 28, 2006 [Page 10]
Internet-Draft Domain Certs June 2006
management is simpler, but what happens if one of the domains no
longer wants to continue the business relationship with the hosting
service? Is the entire certificate to be revoked?
Is it conceivable that each domain have a distinct certificate that
is provided to the hosting service? Certainly, this means that the
domain must share the domain's private key with the hosting service.
TLS extensions [7] like the extended client hello allow TLS clients
to provide to the TLS server the name of the server they are
contacting. Thus, the server can present the correct certificate to
establish the TLS connection.
TODO: Need some more discussion on the mailing list around this
issue. What is the recommended procedure here?
9. Wildcards in dNSName Type
RFC 2818 (HTTP over TLS) [6] allows the dNSName component to contain
a wildcard; e.g., "DNS:*.example.com". RFC 3280 [4], while not
disallowing this explicitly, leaves the interpretation of wildcards
to the individual specification.
RFC 3261 does not provide any guidelines on the presence of wildcards
in certificates. The consensus from the working group discussion
leans in the favor of not using them in SIP.
10. Security Considerations
The goals of TLS include the following security guarantees at the
transport layer:
Confidentiality: packets tunneled through TLS can only be read by the
sender and receiver.
Integrity: packets tunneled through TLS can only be modified by the
sender and receiver.
Authenticity: each principal is authenticated to the other as
posessing a private key for which a certificate has been issued.
Moreover, this certificate has not been revoked, and is backed by
a certificate chain leading to a mutually trusted trust anchor.
By itself, these security guarantees do not immediately lift to
guarantees at the application layer. RFC 3261 states that:
The proxy server at biloxi.com SHOULD inspect the certificate of
the proxy server at atlanta.com in turn and compare the domain
asserted by the certificate with the "domainname" portion of the
From header field in the INVITE request.
Gurbani & Jeffrey Expires December 28, 2006 [Page 11]
Internet-Draft Domain Certs June 2006
This requires each authoritative proxy for atlanta.com to be issued
with a certificate containing "atlanta.com" as its subject. This has
two problems:
1. It does not correspond to common TLS usage, which is to use a
certificate identifying the host. If proxy.biloxi.com is allowed
to require that the subject of the certificate contains a DNS
entry corresponding to the IP address of proxy1.atlanta.com, then
this in turn requires every authoritative proxy for atlanta.com
to be registered with the DNS entry atlanta.com. Hence it is
impossible for a domain to use different SIP proxies as incoming
and outgoing proxies.
2. It makes forensics in the case of compromise more complex. If a
malicious principal is discovered making use of a certificate for
a private key issued to proxy1.atlanta.com, there is little to
identify which of atlanta.com's SIP proxies has been compromised.
If the certificate contains proxy1.atlanta.com's name as well as
atlanta.com's name, then the forensics are simpler.
Fortunately, both of these problems are addressed by having two
identities in domain certificate as outlined in Section 3.
We expect that appropriate processing requirements of domain
certificates will provide the following security guarantees at the
application level:
Confidentiality: SIPS messages from alice@atlanta.com to
bob@biloxi.com can only be read by alice@atlanta.com,
bob@biloxi.com, and SIP proxies issued with domain certificates
for atlanta.com or biloxi.com.
Integrity: SIPS messages from alice@atlanta.com to bob@biloxi.com can
only be modified by alice@atlanta.com, bob@biloxi.com, and SIP
proxies issued with domain certificates for atlanta.com or
biloxi.com.
Authenticity: alice@atlanta.com and proxy.atlanta.com are mutually
authenticated, and moreover proxy.atlanta.com is authenticated to
alice@atlanta.com as an authoritative proxy for domain
atlanta.com. Similar mutual authentication guarantees are given
between proxy.atlanta.com and proxy.biloxi.com and between
proxy.biloxi.com and bob@biloxi.com. As a result,
alice@atlanta.com is transitively mutually authenticated to
bob@biloxi.com (assuming trust in the authoritative proxies for
atlanta.com and biloxi.com).
Moreover, if a suitable media key exchange mechanism (such as DH-HMAC
with null encryption [DH-HMAC]) is used to protect the media between
alice@atlanta.com and bob@biloxi.com, then these guarantees are also
provided for the media streams.
Gurbani & Jeffrey Expires December 28, 2006 [Page 12]
Internet-Draft Domain Certs June 2006
11. Acknowledgments
The discussion on proxy farms in Section 7 is inspired by earlier
versions of Rohan Mahy's connect-reuse draft. Scott Lawrence
suggested the idea of a certificate containing two identities.
Jeroen van Bemmel provided comments to draft versions of this
document.
12. References
12.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[4] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 3280.
12.2 Informative References
[5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Location SIP Servers", RFC 3263, June 2002.
[6] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[7] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
T. Wright, "Transport Layer Security (TLS) Extensions",
RFC 4366, April 2006.
[8] Gurbani, V. and A. Jeffrey, "The Use of Transport Layer Security
(TLS) in the Session Initiation Protocol (SIP)",
draft-gurbani-sip-tls-use-00.txt (work in progress),
February 2006.
[9] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-06.txt (work in progress), October 2005.
Gurbani & Jeffrey Expires December 28, 2006 [Page 13]
Internet-Draft Domain Certs June 2006
Authors' Addresses
Vijay K. Gurbani
Lucent Technologies, Inc./Bell Laboratories
2701 Lucent Lane
Room 9F-546
Lisle, IL 60532
USA
Phone: +1 630 224-0216
Email: vkg at aCm dot OrG
Alan S.A. Jeffrey
Lucent Technologies, Inc./Bell Laboratories
2701 Lucent Lane
Room 9F-534
Lisle, IL 60532
USA
Email: ajeffrey at bell hyphen labs dot com
Appendix A. Retargetting in SIP
Re-targetting breaks down several security assumptions in SIP. For
instance, consider the following call flow:
Gurbani & Jeffrey Expires December 28, 2006 [Page 14]
Internet-Draft Domain Certs June 2006
P1 P2 P3
(example.com) (atlanta.com) (biloxi.com)
| | |
+--F1---------->| |
| +--F2--------->|
...
Figure 3: Retargetting in SIP
F1:
INVITE sips:bob@atlanta.com SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=...
Via: SIP/2.0/TLS alice-pc.example.com;branch=...
From: Alice <sips:alice@example.com>;tag=891jhh
To: Bob <sips:bob@atlanta.com>
...
F2:
INVITE sips:bob@biloxi.com SIP/2.0
Via: SIP/2.0/TLS proxy.atlanta.com;branch=...
Via: SIP/2.0/TLS proxy.example.com;branch=...
Via: SIP/2.0/TLS alice-pc.example.com;branch=...
From: Alice <sips:alice@example.com>;tag=891jhh
To: Bob <sips:bob@atlanta.com>
...
Alice sends a request to Bob through her outbound proxy (F1). The
request ends up at Bob's inbound proxy, P2. Bob is currently not in
the atlanta.com domain and has his forwarding rules set such that all
requests are forwarded to an alternate domain, biloxi.com. P2 now
retargets the request to Bob's forwarding address in the biloxi.com
domain (F2).
When the biloxi.com proxy gets the incoming request, the "domainname"
component in the From SIP header will not match the domain URI stored
in the certificate (which will "URI:sip:atlanta.com"). If the
biloxi.com proxy has a strict policy to reject requests that do not
match the administrative domain from which they have been proxied,
the session setup will fail.
Gurbani & Jeffrey Expires December 28, 2006 [Page 15]
Internet-Draft Domain Certs June 2006
Appendix B. Retargetting and Identity
P1 P2 P3
(example.com) (atlanta.com) (biloxi.com)
| | |
+--F1---------->| |
| +--F2--------->|
...
Figure 4: Retargetting with Identity
F1:
INVITE sips:bob@atlanta.com SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=...
Via: SIP/2.0/TLS alice-pc.example.com;branch=...
From: Alice <sips:alice@example.com>;tag=891jhh
To: Bob <sips:bob@atlanta.com>
Identity: "kj0P4..."
Identity-Info: <https://proxy.example.com/example.cer>;alg=rsa-sha1
...
F2:
INVITE sips:bob@biloxi.com SIP/2.0
Via: SIP/2.0/TLS proxy.atlanta.com;branch=...
Via: SIP/2.0/TLS proxy.example.com;branch=...
Via: SIP/2.0/TLS alice-pc.example.com;branch=...
From: Alice <sips:alice@example.com>;tag=891jhh
To: Bob <sips:bob@atlanta.com>
Identity: "kj0P4..."
Identity-Info: <https://proxy.example.com/example.cer>;alg=rsa-sha1
...
Alice sends a request to Bob through her outbound proxy (F1). The
request ends up at Bob's inbound proxy, P2. Bob is currently not in
the atlanta.com domain and has his forwarding rules set such that all
requests are forwarded to an alternate domain, biloxi.com. P2 now
retargets the request to Bob's forwarding address in the biloxi.com
domain (F2).
When P3 gets the request from P2, the only attribute that P3 can
absolutely depend on to mutually authenticate P2 is the topmost Via
sent-by. This gives P3 some guarantee that P2 represents a host in
the atlanta.com domain. P3 cannot depend on the domainname in the
From header; that contains a completely different domain than
atlanta.com. Neither can it depend on the Identity headers inserted
Gurbani & Jeffrey Expires December 28, 2006 [Page 16]
Internet-Draft Domain Certs June 2006
by the originating proxy. These correspond, of course, to the
originating proxy and not to the proxy in the atlanta.com domain.
Gurbani & Jeffrey Expires December 28, 2006 [Page 17]
Internet-Draft Domain Certs June 2006
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 (2006). 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.
Gurbani & Jeffrey Expires December 28, 2006 [Page 18]