SIP WG V. Gurbani, Ed.
Internet-Draft A. Jeffrey
Expires: October 6, 2006 Lucent Technologies, Inc./Bell
Laboratories
April 4, 2006
Domain Certificates in the Session Initiation Protocol (SIP)
draft-gurbani-sip-domain-certs-00
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 October 6, 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 October 6, 2006 [Page 1]
Internet-Draft Domain Certs April 2006
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . 3
4. Peer Identity . . . . . . . . . . . . . . . . . . . . . . . 4
5. Registrars and Redirect Servers . . . . . . . . . . . . . . 5
6. Proxy Servers, Identities and SIP Headers . . . . . . . . . 6
7. Server Farms and Certificate Content . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . 11
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1 Normative References . . . . . . . . . . . . . . . . . . 12
12.2 Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13
A. Retargetting in SIP . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . 15
Gurbani & Jeffrey Expires October 6, 2006 [Page 2]
Internet-Draft Domain Certs April 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 October 6, 2006 [Page 3]
Internet-Draft Domain Certs April 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.
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 [7], as well as satisfy the RFC 3261 concept on what should be
contained in a site (or domain) certificate (Section 26.3.1 of RFC
3261, quoted above). In the sections below, we apply the concept of
a certificate containing the two identities to typical scenarios in
SIP to discuss its merits and discover any shortcomings.
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".
4. 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
Gurbani & Jeffrey Expires October 6, 2006 [Page 4]
Internet-Draft Domain Certs April 2006
to populate the X.509v3 subjectAltName extension. However, this is
under specified 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.
A specific recommendation for TLS certificates should be that the
certificate has the X.509v3 subjectAltName extension populated with a
dNSName type that identifies the host (the "host URI").
Do we need to worry about certificates pre-dating RFC 3280 that
had the name of the host in the Common Name field of Subject
field? Some operators may have paid for these certificates for
web servers and may now find themselves reusing the certificates
for SIP servers (hopefully, not simultaneously!).
Additionally, it should also be recommended that the X.509v3
subjectAltName extension for proxy servers, registrars, and redirect
servers contain a "domain URI" that asserts the ownership of a domain
to the holder of the certificate.
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.
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
Request-URI (R-URI) the client was trying to reach (in a REGISTER
request, the R-URI typically names the location service for which the
registration is meant, for example, "REGISTER sip:example.com").
Additionally, the client will have more confidence if the host URI in
the certificate matches the canonical name of the server it had
established a TLS connection to.
Gurbani & Jeffrey Expires October 6, 2006 [Page 5]
Internet-Draft Domain Certs April 2006
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
Request from Alice to Bob, through P1:
INVITE sips:bob@biloxi.com SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=...
Via: SIP/2.0/TLS alice-pc.example.com;branch=...
To: SpongeBob Squarepants <sips:bob@biloxi.com>
From: Alice <sips:alice@example.com>;tag=jki981-1
Identity: ...
...
Gurbani & Jeffrey Expires October 6, 2006 [Page 6]
Internet-Draft Domain Certs April 2006
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 To header field or the next hop URI --
which could be the R-URI or the topmost Route header -- and looks for
a match. If they match, P1 can be certain that P2 has authority over
the biloxi.com domain. Additionally, P1 matches the host URI in the
certificate against the canonical name of the server that it had
established a TLS connection to. If they match, P1 can be sure of
the specific identity of the host it has established the TLS
connection to.
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. P2 must ensure that the certificate is not
expired and is rooted in a trusted hierarchy. Next, P2 examines the
domainname in the From header and matches it to the domain URI stored
in the certificate (c.f. Section 26.3.2.2 of RFC 3261). If they
match, P2 can be certain that P1 has authority over the example.com
domain.
However, if they do not match, P2 cannot assume the converse;
i.e., P2 cannot assume that P1 does not have authority over the
example.com domain. Due to retargetting, the From header may not
correspond to the administrative domain from which the request has
been proxied (see Appendix A). Other techniques, such as
examining the Via trail may be used.
And finally, P2 should match the sent-by value of the topmost Via
against the host URI stored in the certificate. A match will provide
further confidence to P2 on the veracity of P1's certificate.
It is open to discussion whether P2 should perform a reverse DNS
lookup of the address it inserted in the "received" parameter of
the topmost Via header and use the result to match against the
host URI in the certificate (as opposed to blindly trusting the
sent-by inserted by the sender). Possessing a certificate and the
associated key does not mean that the certificate is meant for the
host it is actually installed on. P2 could have more confidence
if it performs reverse DNS to match the host name in the
certificate (assuming that DNS itself has not been compromised).
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
Gurbani & Jeffrey Expires October 6, 2006 [Page 7]
Internet-Draft Domain Certs April 2006
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
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.
Gurbani & Jeffrey Expires October 6, 2006 [Page 8]
Internet-Draft Domain Certs April 2006
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.
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.
Gurbani & Jeffrey Expires October 6, 2006 [Page 9]
Internet-Draft Domain Certs April 2006
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
To put in.
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. However, it may seem appropriate that wildcards
should not be used in certificates. Even if they are used, it
appears appropriate that each host possesses a unique certificate
(i.e., unique serial number) as opposed to sharing a wildcard
certificate among all hosts. In the latter case, the private key
will need to be shared across all hosts and a compromise of the key
at any one of the hosts would render the entire proxy farm to be
Gurbani & Jeffrey Expires October 6, 2006 [Page 10]
Internet-Draft Domain Certs April 2006
insecure.
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.
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
Gurbani & Jeffrey Expires October 6, 2006 [Page 11]
Internet-Draft Domain Certs April 2006
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.
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
Gurbani & Jeffrey Expires October 6, 2006 [Page 12]
Internet-Draft Domain Certs April 2006
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] 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.
Authors' Addresses
Vijay K. Gurbani (editor)
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 October 6, 2006 [Page 13]
Internet-Draft Domain Certs April 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 October 6, 2006 [Page 14]
Internet-Draft Domain Certs April 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 October 6, 2006 [Page 15]