Subject: RE: [Sip] impractical keying requirement in sip identity draft

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 20 Oct 2005 16:40:29 -0400

Juha,

As has been pointed out on this mailing list before, this constraint already exists in the core SIP standard. Specifically, in RFC3263. (From 4.1)

   For NAPTR records with SIPS protocol fields, (if the server is using
   a site certificate), the domain name in the query and the domain name
   in the replacement field MUST both be valid based on the site
   certificate handed out by the server in the TLS exchange. 

If you send a request to a URI of the form sips:[email-masked], then the certificate of the responding server (which is delivered via TLS in the backwards domain) must be for valid the domain 'sip.example.com'. This goes even for the sorts of hosting cases where the DNS NAPTR/SRV records for sip.example.com point you to siphosting.com, and siphosting.com is the server that actually replies. In that instance, siphosting.com must hold a certificate valid for 'sip.example.com'.

For us to deviate from this principle for the sip-identity draft really doesn't make sense, because the constraint already exists in RFC3263. We've gone to some trouble to make sure that the authority for a given domain from an identity perspective mirrors the authority over the domain for inbound requests to the domain.

Regarding your concern about how the hosting service would know what hosted domain the user agent is requesting, since as you rightly point out a TLS connection is formed before any SIP requests are sent, the same problem exists of course for HTTP. Thus, the caretakers of TLS wisely added a server name indication to the extended client hello, which defined in RFC3546 Section 3.1. So, this problem is addressed at the TLS layer.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Juha Heinanen
> Sent: Monday, October 10, 2005 11:40 AM
> To: [email-masked]
> Subject: [Sip] impractical keying requirement in sip identity draft
> 
> 
> in my opinion, it is no practical to require that a company would supply
> private keying material regarding its domain to whoever party that
> happens to host its sip proxy service.  that simply does not happen.
> 
> if sip srv record of, say, cisco.com, points to sip.provider.com, then
> it must suffice that sip.provider.com uses its own keying material to
> sign the identity of cisco.com users.
> 
> and even if sip.provider.com proxy would posses keying material of
> domain cisco.com, i don't understand how it could know which server
> certificate it should present to a sip ua when it establishes tls
> connection with the proxy, because that happens before the sip ua has
> sent any sip requests and because it is impractical to require that each
> domain would have its own ip address or port at the proxy.
> 
> it may be that i'm missing something, but if not, it makes no sense for
> ietf to write specifications that cannot have real worldimplementations.
> 
> -- juha
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Rohan Mahy <[email-masked]>
Date: Sat, 22 Oct 2005 11:21:30 -0700

Hi,

To try to further answer Juha's questions, the way that
provider.net<http://provider.net>decides what credentials to send is
exactly the same way this works in HTTP.
Provider.net <http://Provider.net> today determines what domain it is
serving based on the port number (set via SRV).
Provider.net<http://Provider.net>is hosting several TLS domains and
for good providers, each hosted domain
can have separate certs and private keys. Example-A.com does not have access
to Example-B.com's private key and vice versa.

Another standardized but not yet deployed way to solve this problem is to
use the TLS extended client hello extension to provide the name of the
server. When implemented, this allows the server to provide the certificate
of the expected domain on a single port. This is documented in RFC 3546.

thanks,
-rohan

On 10/20/05, Peterson, Jon <[email-masked]> wrote:
>
>
> Juha,
>
> As has been pointed out on this mailing list before, this constraint
> already exists in the core SIP standard. Specifically, in RFC3263. (From
> 4.1)
>
> If you send a request to a URI of the form sips:[email-masked], then
> the certificate of the responding server (which is delivered via TLS in the
> backwards domain) must be for valid the domain 'sip.example.com<http://sip.example.com>'.
> This goes even for the sorts of hosting cases where the DNS NAPTR/SRV
> records for sip.example.com <http://sip.example.com> point you to
> siphosting.com <http://siphosting.com>, and siphosting.com<http://siphosting.com>is the server that actually replies. In that instance,
> siphosting.com <http://siphosting.com> must hold a certificate valid for '
> sip.example.com <http://sip.example.com>'.
>
> For us to deviate from this principle for the sip-identity draft really
> doesn't make sense, because the constraint already exists in RFC3263. We've
> gone to some trouble to make sure that the authority for a given domain from
> an identity perspective mirrors the authority over the domain for inbound
> requests to the domain.
>
> Regarding your concern about how the hosting service would know what
> hosted domain the user agent is requesting, since as you rightly point out a
> TLS connection is formed before any SIP requests are sent, the same problem
> exists of course for HTTP. Thus, the caretakers of TLS wisely added a server
> name indication to the extended client hello, which defined in RFC3546
> Section 3.1. So, this problem is addressed at the TLS layer.
>
> Jon Peterson
> NeuStar, Inc.
>
> > if sip srv record of, say, cisco.com <http://cisco.com>, points to
> sip.provider.com <http://sip.provider.com>, then
> > it must suffice that sip.provider.com <http://sip.provider.com> uses its
> own keying material to
> > sign the identity of cisco.com <http://cisco.com> users.
> >
> > and even if sip.provider.com <http://sip.provider.com> proxy would
> posses keying material of
> > domain cisco.com <http://cisco.com>, i don't understand how it could
> know which server

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 24 Oct 2005 04:19:01 +0300

> serving based on the port number (set via SRV).

are you saying that each time a provider adds a new domain to its proxy,
the proxy would need to start listening on a new port?  in all proxies
that i know, this would mean restarting the proxy, which is very bad.

looks like the extended client hello that jon pointed to, might be a
better solution.  but as far as i know, it is not yet supported by
openssl library, for example.

 > to Example-B.com's private key and vice versa.

but provider needs access to both, which is my original concern.

 > of the expected domain on a single port. This is documented in RFC

yes.

all this hassle seems to result from not being able to trust dns.  why
not simply sign the dns records pointing to the proxy after which the
proxy would only need to sign itself?

-- juha

---

From: Klaus Darilion <[email-masked]>
Date: Thu, 27 Oct 2005 17:57:47 +0200

Peterson, Jon wrote:
> already exists in the core SIP standard. Specifically, in RFC3263.
> (From 4.1)
> 

Hi Jon!

And what is the practical solution for in-dialog requests and reponses 
which establish a new TLS connection (e.g. the initial TLS connection 
was terminated)? All SIP proxies I know put IP addresses into the Via 
and Record-Route headers. Thus, the proxy would also need a certificate 
with its IP address?

regards
Klaus

> If you send a request to a URI of the form sips:[email-masked],
> then the certificate of the responding server (which is delivered via
> TLS in the backwards domain) must be for valid the domain
> 'sip.example.com'. This goes even for the sorts of hosting cases
> where the DNS NAPTR/SRV records for sip.example.com point you to
> siphosting.com, and siphosting.com is the server that actually
> replies. In that instance, siphosting.com must hold a certificate
> valid for 'sip.example.com'.
> 
> For us to deviate from this principle for the sip-identity draft
> really doesn't make sense, because the constraint already exists in
> RFC3263. We've gone to some trouble to make sure that the authority
> for a given domain from an identity perspective mirrors the authority
> over the domain for inbound requests to the domain.
> 
> hosted domain the user agent is requesting, since as you rightly
> point out a TLS connection is formed before any SIP requests are
> sent, the same problem exists of course for HTTP. Thus, the
> caretakers of TLS wisely added a server name indication to the
> extended client hello, which defined in RFC3546 Section 3.1. So, this
> problem is addressed at the TLS layer.
> 
> Jon Peterson NeuStar, Inc.
> 
> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]]On Behalf Of Juha Heinanen Sent:
>> Monday, October 10, 2005 11:40 AM To: [email-masked] Subject: [Sip]
>> impractical keying requirement in sip identity draft
>> 
>> 
>> in my opinion, it is no practical to require that a company would
>> supply private keying material regarding its domain to whoever
>> party that happens to host its sip proxy service.  that simply does
>> not happen.
>> 
>> if sip srv record of, say, cisco.com, points to sip.provider.com,
>> then it must suffice that sip.provider.com uses its own keying
>> material to sign the identity of cisco.com users.
>> 
>> connection with the proxy, because that happens before the sip ua
>> has sent any sip requests and because it is impractical to require
>> that each domain would have its own ip address or port at the
>> proxy.
>> 
>> it may be that i'm missing something, but if not, it makes no sense
>> for ietf to write specifications that cannot have real
>> worldimplementations.
>> 
>> -- juha
>> 
>> _______________________________________________ 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
>> 
> 
> 
> _______________________________________________ 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
> 
>