Subject: [Sip] SIP/TLS (1): Domain certificates in SIP

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 04 Apr 2006 10:09:01 -0500

Folks: The SIP TLS draft presented during the Dallas IETF had
spawned discussions, the next step of which was to discuss
the open issues on the list.

Over the next week or so, I will open up discrete threads to
track the issues, beginning with this email.

A rather important open issue discussed during the meeting has
been that of domain certificates in SIP and their contents.

To jump start this particular discussion, I have submitted a draft
on domain certificates in SIP.  Until it becomes available in
the archives, you can get a version from:

http://www.iit.edu/~gurbvij/I-D/draft-gurbani-sip-domain-certs-00.txt
http://www.iit.edu/~gurbvij/I-D/draft-gurbani-sip-domain-certs-00.html

This draft contains some initial thoughts on the contents of a
domain certificate.  The intent is to start a discussion on
whether this is a good approach or whether we should consider
other alternatives.

Comments and feedback would be most welcome.

Thank you.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 04 Apr 2006 15:25:25 -0500

Mike: Thanks for your comments.

Michael Thomas wrote:
> One thing that strikes me about this is that it seems to imply that
> there is exactly two states:
> 
> 0) you don't speak for the domain
> 1) you do speak for the domain
> 
> Are people convinced that this is sufficiently granular? 

Yes, good question for discussion.  It has been said that in
SIP, we invest a lot of trust in our proxies.  As such, having
an explicit acknowledgement that the proxy is an authority for
a domain would back up that trust.

> What if I
> want to limit the scope of what a particular sip entity is entitled
> to speak for? In particular, what about outsourced business
> functions that I might want to allow the outsourcer to speak for
> me in a more limited capacity -- say the extent of an outsourced
> marketing campaign or somesuch?

Are you perhaps concerned about an enterprise outsourcing to a
SIP service provider (virtual SIP servers?) ... what Ian Foster
calls "SourceForge for science" (I. Foster, "Service-Oriented
Science," Science, Vol. 308, No. 5723, pp. 814-817, May 2005;
available online at
http://www.sciencemag.org/cgi/content/full/308/5723/814?ijkey=aqCCmCFix8Ll.&keytype=ref&siteid=sci)

I am trying to understand how different that would be than
an explicit permission (business level agreement) given to
the outsourcer that it can act as a point of contact for
a SIP service provider...

Thanks,

- vijay

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 04 Apr 2006 13:54:55 -0700

I don't understand the DNS name would refer to a host or conversely why the
SIP name does not. Either can refer to either. I don't see the need for
distinction - the cert needs to refer to the name used to reach the proxy -
that is typically called the "domain" but may refer to a single host or
many. 

I see no need to step into any CN disasters - they are very hard to specify
and we have no backwards compatible need to do it. SIP has been SAN from the
beginning.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 04 Apr 2006 16:11:33 -0500

Cullen Jennings wrote:
> I don't understand the DNS name would refer to a host or conversely
> why the SIP name does not. Either can refer to either. I don't see
> the need for distinction - the cert needs to refer to the name used
> to reach the proxy - that is typically called the "domain" but may
> refer to a single host or many.

If the "domain" refers to many hosts, then is the cert shared among
all the hosts?  Or does each host have a different cert with the same
domainname in SAN but a unique serial number?

If a cert only has a SAN of DNS:proxy-1.example.com" is the intent,
then that proxy-1 is the authority for example.com?  Then, if another
cert has a SAN of "DNS:proxy-1.south.example.com" is the intent that
proxy-1 is the authority for south.example.com zone AND example.com
zone?

> I see no need to step into any CN disasters - they are very hard to
> specify and we have no backwards compatible need to do it. SIP has
> been SAN from the beginning.

OK.  Thanks for the clarification.

However, in rfc3261, SAN is only mentioned in connection with S/MIME
certs (section 23.2).  For TLS certs, rfc3261 simply says "Proxy
servers, redirect servers, and registrars SHOULD possess a site
certificate whose subject corresponds to their canonical hostname".
It is probably the intent that the "subject" in that sentence refer
to SAN; but it is not clear from simply reading the sentence that
this is indeed the intent.

Thanks,

- vijay

---

From: Michael Thomas <[email-masked]>
Date: Tue, 04 Apr 2006 14:17:31 -0700

> a SIP service provider...

I'm coming at this from an analogous situation with email where
I, say, want to outsource [email-masked] to perform that
business function, but I want to constrain the outsourcer to only
speak for in this example "benefits", and not [email-masked].
This is a very common arrangement with email, and with DKIM
we wanted to explicitly allow this sort of arrangement, but limit
the exposure from an outsourcer.

I would think that similar outsourced functions for telephony, etc,
will be common for SIP as well, especially when you're talking
about call centers, etc.

You are correct that you could also limit that at a business level,
but as with most things, you'd like some layers defense, be they
for honest mistakes or malfeasance.

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 04 Apr 2006 09:27:21 -0700

Are people convinced that this is sufficiently granular? What if I

       Mike

Vijay K. Gurbani wrote:

>------------------------------------------------------------------------
>

---

From: "Sean Olson" <[email-masked]>
Date: Thu, 6 Apr 2006 10:11:00 -0700

SAML 

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]] 
Sent: Tuesday, April 04, 2006 9:27 AM
To: Vijay K. Gurbani
Cc: IETF SIP List
Subject: Re: [Sip] SIP/TLS (1): Domain certificates in SIP

Are people convinced that this is sufficiently granular? What if I want
to limit the scope of what a particular sip entity is entitled to speak
for? In particular, what about outsourced business functions that I
might want to allow the outsourcer to speak for me in a more limited
capacity -- say the extent of an outsourced marketing campaign or
somesuch?

       Mike

Vijay K. Gurbani wrote:

> Folks: The SIP TLS draft presented during the Dallas IETF had spawned 
> discussions, the next step of which was to discuss the open issues on 
> the list.
>
> Over the next week or so, I will open up discrete threads to track the

> issues, beginning with this email.
>
> A rather important open issue discussed during the meeting has been 
> that of domain certificates in SIP and their contents.
>
> To jump start this particular discussion, I have submitted a draft on 
> domain certificates in SIP.  Until it becomes available in the 
> archives, you can get a version from:
>
> This draft contains some initial thoughts on the contents of a domain 
> certificate.  The intent is to start a discussion on whether this is a

> good approach or whether we should consider other alternatives.
>
>This list is for NEW development of the core SIP Protocol Use 
>[email-masked] for questions on current sip Use 
>[email-masked] for new developments on the application of sip
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[email-masked] for questions on current sip Use
[email-masked] for new developments on the application of sip

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 06 Apr 2006 10:59:45 -0700

SAML, or the outsourced entity routes thought the main domain for identity
services, or a contract that limits how they can use the key

---

From: "Sean Olson" <[email-masked]>
Date: Thu, 6 Apr 2006 11:01:38 -0700

Yep, that's an excellent point 

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: Thursday, April 06, 2006 11:00 AM
To: Sean Olson; Mike Thomas; Vijay K. Gurbani
Cc: [email-masked]
Subject: Re: [Sip] SIP/TLS (1): Domain certificates in SIP

SAML, or the outsourced entity routes thought the main domain for
identity services, or a contract that limits how they can use the key

On 4/6/06 10:11 AM, "Sean Olson" <[email-masked]> wrote:

> want to limit the scope of what a particular sip entity is entitled to

> speak for? In particular, what about outsourced business functions 
> that I might want to allow the outsourcer to speak for me in a more 
> limited capacity -- say the extent of an outsourced marketing campaign

> or somesuch?

>> ---------------------------------------------------------------------
>> --
>> -
>>

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 09 Apr 2006 23:22:43 -0700

> proxy-1 is the authority for south.example.com zone AND example.com

It's like TLS for https. There could be 10 host that server web pages for
www.example.com. All the hosts could use the same certificate or they could
have different certificates but all the certificates would assert a name of
www.example.com

The fact that the a reverse dns lookup of the IP address of one of the hosts
might return server1.example.com has nothing to do with what the certificate
needs to say. The user was trying to connect to www.example.com and if the
certificate asserts an identity other than what the user was trying to
connect to, an error needs to be raised.

> this is indeed the intent.

I suspect that canonical hostname meant what the name by which the previous
hop would try to connect. This is more what you would call domain - ie
example.com not proxy-1.example.com. This phrase has caused much confusion
and we should clarify it in the spec.

---

From: Alan Jeffrey <[email-masked]>
Date: Mon, 10 Apr 2006 09:42:01 -0500

The requirement for all SIP proxies handling incoming traffic have a DNS 
entry "example.com" is a reasonable one.  However, requiring all SIP 
proxies handling outbound traffic to also have DNS entry "example.com" 
seems less reasonable.

Imagine an architecture where example.com is a proxy which does nothing 
but forward messages to proxyN.example.com for processing.  These 
proxies do not have a DNS entry example.com, but they are authorized as 
authoritative proxies for the domain example.com.

The HTTP analogy is true for proxies handling incoming traffic, but not 
for proxies handling outgoing traffic.

Alan.

-- 
Alan Jeffrey                                           +1 630 224 0175
Bell Labs, Lucent Technologies   http://cm.bell-labs.com/who/ajeffrey/
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 10 Apr 2006 15:12:44 -0700

I don't think that any of the current SIP RFCs requires a proxy to have a
DNS entry if it only sends requests. Personally I'm not sure I see the big
deal in giving them a DNS entry because I am suspicious that there won't be
many cases where "outbound only" is possible but I'm not seeing any reason
that we do need to make them have a DNS entry either.

---

From: Dean Willis <[email-masked]>
Date: Mon, 10 Apr 2006 18:12:01 -0500

> that we do need to make them have a DNS entry either.

I believe that according to this terminology, the IMS P-CSCF is  
"outbound only". It is not listed as the responsible proxy for an AOR  
in the DNS, as those records point at I-CSCF.

But I suspect that buried somewhere in this discussion thread is a  
failure to conceptualize the distinction between a proxy serving  
users of a domain and a proxy serving to relay between domains.

This probably relates to the "guess my registrar from my AOR" problem  
that Juha has raised, too.

In what I think of as "typical" cases, the proxy that my phone routes  
everything through (my "outbound proxy") is not what I would see if I  
did an DNS lookup on the domain of my AOR -- ESPECIALLY if that  
lookup occurs in the "public" DNS rather than a local stub.

For example, take my "atypical" house as of earlier this year (ok,  
late last year).

I had a proxy at sip.softarmor.com with an A record of  
206.176.144.210 (can't use SRV, idiot DNS hoster doesn't do it),  
supporting AOR sip:[email-masked]

But since my phone had an IP address of 192.168.2.100, it used a  
proxy at 192.168.2.2 (the proxy was dual-homed). I either didn't have  
a DNS record for this proxy interface, or if I did, it was in an  
internally-visible stub domain and had some bogus name on it.

I configured this default proxy address into my SIP clients manually,  
but could have used a DHCP option (were it actually supported) to  
have done the same thing.

--
Dean

---

From: Alan Jeffrey <[email-masked]>
Date: Tue, 11 Apr 2006 04:19:43 -0500

Ah, you spotted my not-very-well-hidden IMS scenario :-)

Indeed, one place where outbound proxy != inbound proxy is IMS, which 
distinguishes between the I-CSCF (which deals with all incoming 
requests) and the S-CSCF (which actually processes requests, and 
forwards them to other proxies if necessary).  The IMS picture is even 
trickier, in that in roaming mode the P-CSCF is under administrative 
control of a different network.

Of all these SIP proxies, only the I-CSCF would have a DNS entry of 
example.com, the others would be proxyN.example.com (or 
proxyN.visited.com for the P-CSCF), but they should all be considered as 
speaking authoritatively for example.com (or visited.com for the P-CSCF).

Alan.

Dean Willis wrote:
> failure to conceptualize the distinction between a proxy serving  users 
> of a domain and a proxy serving to relay between domains.
> 
> did an DNS lookup on the domain of my AOR -- ESPECIALLY if that  lookup 
> occurs in the "public" DNS rather than a local stub.
> 
> For example, take my "atypical" house as of earlier this year (ok,  late 
> last year).
> 
> I had a proxy at sip.softarmor.com with an A record of  206.176.144.210 
> (can't use SRV, idiot DNS hoster doesn't do it),  supporting AOR 
> sip:[email-masked]
> 
> But since my phone had an IP address of 192.168.2.100, it used a  proxy 
> at 192.168.2.2 (the proxy was dual-homed). I either didn't have  a DNS 
> record for this proxy interface, or if I did, it was in an  
> but could have used a DHCP option (were it actually supported) to  have 
> done the same thing.
> 
> -- 
> Dean
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Apr 2006 09:10:25 -0400

> speaking authoritatively for example.com (or visited.com for the P-CSCF).

Considered as speaking authoritatively in what sense?

IMS uses P-Asserted-Identity rather than certs for identity, and has its 
own rules for what elements are trusted to insert it. That is outside 
the scope of this discussion.

IMS also doesn't (yet, AFAIK) specify how to use TLS. So we have to read 
the tea leaves to figure out how it should do that. The place it would 
be most applicable to this discussion is between the UA and the P-CSCF. 
The UA has its own process for discovering the P-CSCF. The cert the 
P-CSCF uses needs to be consistent with this process, but that doesn't 
necessarily require each P-CSCF proxyN.example.com to have a cert for 
example.com.

Then the P-CSCF needs to make a connection to an I-CSCF when 
registering. If that is to be done via TLS then the I-CSCF probably does 
need a cert for the example.com domain, since all the P-CSCF has to go 
on the the public user id being registered.

All the interconnections of proxies within the domain are a private matter.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 11 Apr 2006 14:22:10 -0500

> Alan Jeffrey wrote:
[...]
>> proxyN.visited.com for the P-CSCF), but they should all be
>> considered as speaking authoritatively for example.com (or
>> visited.com for the P-CSCF).
> 
> IMS uses P-Asserted-Identity rather than certs for identity, and has
> its own rules for what elements are trusted to insert it. That is
> outside the scope of this discussion.

I don't think the distinction being drawn here is P-A-I vs. certs.
While a SIP AoR in a cert binds that cert to a specific user, TLS
certs are not specific to a user, but a host representing the domain
(the inbound proxy, for instance).

Cullen's earlier email sheds some light in that when a user wants
to talk to a URI of sip:[email-masked], then the inbound proxy
(example.com) presenting a cert with a SAN of "sip:example.com"
suffices.  Now what if the inbound proxy wants to mutually authenticate
the outbound proxy (visited.com) from which the request was sent?
To do so, it asks for a cert from the outbound proxy.  What should be
the identity in the cert presented by the outbound proxy?  And how is
that identity correlated to the SIP vectors?  The From header
is no help due to retargetting.  The only header that correlates
the identity of the the outbound proxy to the cert is the sent-by
production in the topmost Via.  And that will most probably be in
the form of proxyN.visited.com.

Thanks,

- vijay

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 11 Apr 2006 12:11:25 -0700

Ok, I think we all agree that could be proxies that were authorities for
example.com that the SIP DNS resolution for example.com would never end up
resolving to that proxy. (Note I don't think this is the same as the proxy
never sends a request). But given we agree on this, I'm actually lost on
where this thread was going :-)

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Apr 2006 18:03:55 -0400

> (the inbound proxy, for instance).

OK. But then what is meant by "speaking authoritatively for"?

> the form of proxyN.visited.com.

So in the proxy-proxy case all the receiving proxy can do is check the 
sending proxy's cert against the via. That doesn't say a lot. For 
instance it doesn't provide an easy way for the receiving proxy to 
decide if it should trust a P-A-I from that proxy.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 12 Apr 2006 11:04:26 -0500

> OK. But then what is meant by "speaking authoritatively for"?

Paul: Thanks for your comments.

I will summarize this issue in a followup email to Cullen's note
on where this thread is headed.

> decide if it should trust a P-A-I from that proxy.

Yes, exactly.  All the receiving proxy can do is to ensure that the
request is coming from where it should be coming from.

Thanks.

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 12 Apr 2006 11:27:03 -0500

> where this thread was going :-)

Cullen: Thanks for your comments.

Fair enough ... so lets recap.  We were drilling down to examine
the identities stored in the certs and tying this identity to
the notion of an authoritative proxy (more on the latter in a bit).

The specific agreement that we appear to have reached is the
mechanics of identifying the proxy when the said proxy presents
a cert (the "inbound" proxy case).  That is, when a user agent
receives a cert, the cert should assert an identity corresponding
to the name that the agent performed a RFC3263-type resolution
on.  A cert asserting an identity of "sip:example.com" provides a
sufficient anchor for identifying the said proxy if the user agent
was attempting to connect to a R-URI that contained a domainname of
"example.com" using RFC3263.  In this direction (i.e., the proxy
server presenting a cert for verification), there is no need to
search for a canonical hostname as an identity in the cert (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 mentions an example of 3263 resolution on
"sip:[email-masked]" leading to a service located at
"sip1.example.org").

The following items are open to discussion:

(1) What is the meaning of a proxy "speaking authoritatively for
     a domain?".  To me, this is a trait that we have given to
     a proxy that allows it to act as an authority for incoming
     requests as well as outgoing requests.  And these may be
     different proxies; i.e., inbound != outbound.

     In my conceptualization of the problem, the notion of speaking
     authoritatively for a domain also exists in sip-identity.  When
     the proxy as a holder of the private key of the domain asserts
     that the originator of this request has been authenticated and
     is indeed authorized to claim the identity in the From header,
     the proxy is essentially acting as an authority for that domain.

(2) Is the notion of being an authoritative proxy an all-or-none
     proposition?  Do we need to make it more granular?  (cf.
     Mike Thomas' "outsourcing" scenario).

(3) While we appear to have reached an agreement on the identities
     stored in a cert for an inbound proxy case, what about
     the outbound proxy case?  The outbound proxies may not receive
     session setup requests as a result of RFC3263-type resolution,
     but they do *send out* requests to other domains.  What sort
     of identities need to be stored in the cert (i.e.,
     "sip:proxyN.example.com", and "sip:example.com", ...)

And there has not been any discussion on othe other issues in the
domain certs draft, such as the notion of of having two identities
("sip:example.com", "sip:proxy-1.example.com") that actually neatly
ties up (3) above.  The receiving proxy can, at the very least,
have some guarantees that the request orginated from the said
domain (Via sent-by will contain "proxy-1.example.com", which matches
the identity in the cert, and the From *may* contain the domainname
of example.com).

Also there has not been any discussion about proxy clusters and
wildcarding that are contained in the document.

Thanks,

- vijay