Subject: SIP certificate profile - another possible use case for SRV SAN

From: Stefan Santesson <[email-masked]>
Date: Fri, 23 Mar 2007 11:55:26 +0000

I talked to some people from the SIP side yesterday about their need to distinguish a certificate as one that support SIP services without further constraining it.

From what I was told, SIP has an IANA registered service tag and discovery of SIP resources is currently supported through query to DNS SRV RR.
We therefore concluded in our discussion that use of the new SRV SAN name form would provide SIP with exactly the functionality they need.

More thoughts on this?

Stefan Santesson
Senior Program Manager
Windows Security, Standards

---

From: Russ Housley <[email-masked]>
Date: Fri, 23 Mar 2007 17:59:58 -0400

From the previous discussions on this point, I think that they really
only need an EKU OID assignment.  The document that I read a few
months ago tells how to use the certificate for S/MIME and TLS in this
context.  SIP does not use the certificate directly.

Russ

At 07:55 AM 3/23/2007, Stefan Santesson wrote:

I talked to some people from the
SIP side yesterday about their need to distinguish a certificate as one
that support SIP services without further constraining it.

From what I was told, SIP has an IANA registered service tag and
discovery of SIP resources is currently supported through query to DNS
SRV RR.

We therefore concluded in our discussion that use of the new SRV SAN name
form would provide SIP with exactly the functionality they need.

More thoughts on this?

Stefan Santesson

Senior Program Manager

---

From: Scott Lawrence <[email-masked]>
Date: Sat, 24 Mar 2007 09:37:44 +0100

On Fri, 2007-03-23 at 11:55 +0000, Stefan Santesson wrote:
> I talked to some people from the SIP side yesterday about their need
> to distinguish a certificate as one that support SIP services without
> further constraining it.

> We therefore concluded in our discussion that use of the new SRV SAN
> name form would provide SIP with exactly the functionality they need.

I don't believe that it meets all of our needs.  

The first problem is that SIP domain resolution is a two step process
[RFC 3263]: given a SIP domain ("sip:example.net"), the first step is to
look for one or more NAPTR records for the authority ("example.com");
these provide the SRV names which then must be resolved in a second step
to find the host(s) and port numbers providing SIP service.  The spec
explicitly allows the SRV name suffix be different from the target name
used to find the NAPTR, so this would be legal:

example.com  IN NAPTR 50   50  "s"  "SIPS+D2T"     ""  _sips._tcp.example.net.

        (the spec does also say that in such a case there MUST also be a
        record that does have the same name, for backward compatibility
        with an earlier version of SIP that did not use NAPTR.  However,
        that MUST is a requirement on people who write DNS records, not
        protocol implementors; it cannot be relied on in practice).

The client making the connection to its original target needs to
authenticate that server it ultimately connects to is authoritative for
the original target URI name.  Since the NAPTR translation of that
original name may not be trustworthy, getting authentication of the
output of that translation is not sufficient.

The second problem is that of how to do authentication of the TLS
client.  A SIP server may want to authenticate the SIP domain of a TLS
client; for example, it may have access control policies that allow
connections only from specified domains (as in the case of "SIP Trunk"
provider of PSTN connectivity over SIP - any request may be a billable
event, so only customers in good standing should be allowed to make
requests).  If client authentication is needed, the TLS server (or, more
specifically, the SIP application running over TLS) needs to know the
SIP domain(s) for which the client is authoritative.  The server cannot
use the DNS to translate a SIP domain name to a service or host name to
make this decision, since it is common in SIP deployments to use
different servers to make outbound requests from a domain from those
used for inbound requests; in such a configuration, only the inbound
servers would have NAPTR or SRV records for the domain.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXpbx project coordinator - SIPfoundry    http://www.sipfoundry.org/sipX
  Chief Technology Officer    - Pingtel Corp. http://www.pingtel.com/