Subject: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try

From: "Stastny Richard" <[email-masked]>
Date: Fri, 9 Dec 2005 15:28:59 +0100

Now my next question:
 
Is the problem Klaus described below a problem to be sovled within
the SPEERMINT problem (scope) space?
 
"The more complicated thing is the certificate validation. RFC 3263
mandates, that the SIP domain (before NAPTR, SRV lookups) must be
identical to the domain in the certificate. If provB hosts thousands of
SIP domains for its clients, e.g. sip:[email-masked],
sip:[email-masked], .... and requires TLS for incoming connections,
provB must present a valid certificate for all hosted domains. Thus, you
have to give your private key for stastny.com to you SIP provider.
Furthermore, plain TLS requires the server to send the certificate
without any knowledge of which domain the UAC is trying to contact.
Thus, provB needs a dedicated socket for each hosted domain on its
border proxy to differ the requests and present the proper certificate.
IMO that does not scale. It can be avoided using the "server_name" TLS
extension, but this is e.g. not supported in openssl which is used most
for proxy servers.

This could be also solved by changing RFC 3263 to validate the
certificate against the domain name revealed after SRV lookups. This was
forbidden to detect DNS spoofing, but IMO DNS problems should be fixed
in DNS, not in SIP."

Richard

________________________________

Von: Klaus Darilion [mailto:[email-masked]]
Gesendet: Fr 09.12.2005 13:40
An: Stastny Richard
Cc: [email-masked]; [email-masked]; [email-masked]
Betreff: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try

Stastny Richard wrote:
> Thanx Klaus
>
> for the work ;-)
>
> Now the next question:
> What are the implications proxy vs redirect
> if you are using TLS?

Now it's getting complicated ;-)

With the redirect server, there will be 2 TLS handshakes:
   1. borderProxyA       redirectProxy
   2. borderProxyA       borderProxyB

With the forwarding proxy, one TLS connection is mandatory:
   1. borderProxyA       forwardingProxy

If the forwardin proxy is within the network of provB, there is no need
to use TLS inside the network of prov if other means can be used to
authetnicate (e.g. src_IP). But, if the forwarding proxy stays of of
signaling for in-dialog messages, there is also a must for the second
TLS conenction between
   2. borderProxyA       borderProxyB

The more complicated thing is the certificate validation. RFC 3263
mandates, that the SIP domain (before NAPTR, SRV lookups) must be
identical to the domain in the certificate. If provB hosts thousands of
SIP domains for its clients, e.g. sip:[email-masked],
sip:[email-masked], .... and requires TLS for incoming connections,
provB must present a valid certificate for all hosted domains. Thus, you
have to give your private key for stastny.com to you SIP provider.
Furthermore, plain TLS requires the server to send the certificate
without any knowledge of which domain the UAC is trying to contact.
Thus, provB needs a dedicated socket for each hosted domain on its
border proxy to differ the requests and present the proper certificate.
IMO that does not scale. It can be avoided using the "server_name" TLS
extension, but this is e.g. not supported in openssl which is used most
for proxy servers.

This could be also solved by changing RFC 3263 to validate the
certificate against the domain name revealed after SRV lookups. This was
forbidden to detect DNS spoofing, but IMO DNS problems should be fixed
in DNS, not in SIP.

regards
klaus

> 
> Richard
>
> ________________________________
>
> Von: Klaus Darilion [mailto:[email-masked]]
> Gesendet: Fr 09.12.2005 12:52
> An: Stastny Richard
> Cc: [email-masked]; [email-masked]; [email-masked]
> Betreff: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try
>
>
>
> Stastny Richard wrote:
>
>>Thanx Klaus
>>
>>Also for answering a question I did not (yet) ask
>>regarding redirect vs proxy
>>
>>
>>
>>
>>>I personally prefer relaying instead of redirect.
>>
>>
>>Me too and I see your arguments.
>>Are there any arguments out there why to prefer redriect?
>
>
> I just made some signaling pictures to visualize the difference:
>  From the signaling, there is no big difference. Both versions do need
> approximately the same amount of signaling packets sent (depends onthe
> actual SIP network design).
>
> I do not see any technical reason why to prefer one version over the
> other. It's just a personal preference.
>
> regards
> klaus
>
>
> UAC  proxyA  borderProxyA       redirectProxy borderProxyB  proxyB  UAS
> |        |          |                  |             |        |      |
> |-INVITE>|          |                  |             |        |        |
> |<-100---|-INVITE-->|                  |             |        |        |
> |        |<--100----|-------INVITE---->|             |        |        |
> |        |          |                  |             |        |        |
> |        |          |<------302--------|             |        |        |
> |        |<-302-----|-------ACK------->|             |        |        |
> |        |--ACK---->|                  |             |        |        |
> |        |--INVITE->|                  |             |        |        |
> |        |<-100-----|--------------INVITE----------->|        |        |
> |        |          |<--------------100--------------|-INVITE>|        |
> |        |          |                  |             |<-100---|-INVITE>|
> |        |          |                  |             |        |<-100---|
> |        |          |                  |             |        |        |
> |        |          |                  |             |        |<-180---|
> |        |          |                  |             |<--180--|        |
> |        |          |<---------------180-------------|        |        |
> |        |<--180----|                  |             |        |        |
> |<--180--|          |                  |             |        |<--200--|
> |        |          |                  |             |<--200--|        |
> |        |          |<---------------200-------------|        |        |
> |        |<---200---|                  |             |        |        |
> |<---200-|          |                  |             |        |        |
> |        |          |                  |             |        |        |
> |--ACK-->|          |                  |             |        |        |
> |        |----ACK-->|                  |             |        |        |
> |        |          |--------------ACK-------------->|        |        |
> |        |          |                  |             |--ACK-->|        |
> |        |          |                  |             |        |--ACK-->|
> |        |          |                  |             |        |        |
> |        |          |                  |             |        |        |
> |        |          |                  |             |        |        |
>
> 32 Packets
>
>
> UAC   proxyA  borderProxyA       forwardProxy  borderProxyB  proxyB  UAS
> |        |          |                  |             |        |        |
> |-INVITE>|          |                  |             |        |        |
> |<-100---|-INVITE-->|                  |             |        |        |
> |        |<--100----|-------INVITE---->|             |        |        |
> |        |          |<-------100-------|---INVITE--->|        |        |
> |        |          |                  |<----100-----|-INVITE>|        |
> |        |          |                  |             |<-100---|-INVITE>|
> |        |          |                  |             |        |<-100---|
> |        |          |                  |             |        |        |
> |        |          |                  |             |        |<-180---|
> |        |          |                  |             |<--180--|        |
> |        |          |                  |<---180------|        |        |
> |        |          |<----- -180-------|             |        |        |
> |        |<--180----|                  |             |        |        |
> |<--180--|          |                  |             |        |<--200--|
> |        |          |                  |             |<--200--|        |
> |        |          |                  |<---200------|        |        |
> |        |          |<-------200-------|             |        |        |
> |        |<---200---|                  |             |        |        |
> |<---200-|          |                  |             |        |        |
> |        |          |                  |             |        |        |
> |--ACK-->|          |                  |             |        |        |
> |        |----ACK-->|                  |             |        |        |
> |        |          |--------------ACK-------------->|        |        |
> |        |          |                  |             |--ACK-->|        |
> |        |          |                  |             |        |--ACK-->|
>
> 29 Packets
>
>
>
>

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Klaus Darilion <[email-masked]>
Date: Fri, 09 Dec 2005 15:40:10 +0100

> the SPEERMINT problem (scope) space?

IMHO yes, as long as the SIP WGs do not provide a solution which fit 
real life scenarios.

klaus

---

From: "Peter Williams" <[email-masked]>
Date: Fri, 09 Dec 2005 08:12:54 -0800

>From: Klaus Darilion <[email-masked]>
>To: Stastny Richard <[email-masked]>
>CC: [email-masked], [email-masked], [email-masked]
>Subject: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try
>Date: Fri, 09 Dec 2005 15:40:10 +0100
>

>>provB must present a valid certificate for all hosted domains.

ok. so we are in the same situation as were the website hosters of 1000 
sites in 1995, who selected the certificate to idendity the TLS responder 
based on the HTTP-level header created by the initiator (versus initiator 
TCP/ICMP info determined from the server-side socket).

>>Thus, you

Well...the responder must deliver a cert with value "cn=*.stastny.com", and 
it must have a private key the corresponds to the embedded public key. 
However, these two assertions are not linked, beyond the AND. TLS for HTTP 
hosting (which is analagous to TLS for SIP 'user hosting'")  does NOT impose 
any obligtation to deliver any particular private keys around. Another 
solution is that the hosting site hoster issues suitable certs, for those 
"sites/ENUMusers that it webhosts/siphosts. And, there are yet other 
solutions, not involving hierarchical PKI, and its well-known hangups.

>>without any knowledge of which domain the UAC is trying to contact.

_plain_ TLS has NO rules concerning the selection of the cert, given an 
inbound handshake on a conenction, or a session restart. SSL and its IETF 
variety was architected to ensure that upper layers drive cert selection - 
originally intended to be a hook function in the winsock API. Never forget, 
despite the popularity of https profile, that TLS itself is not a cert-based 
handshake design, per se. How public keys are inidicated in one of the 
handshake types (.e.g the standardized handshake), and how said public keys 
are authenticated is not a TLS matter. its a matter for ftps, https, pptps 
etc etc profiling of SSL to any problem domain that has a reliable channel 
in support (.e.g. TCP)

>>extension, but this is e.g. not supported in openssl which is used most

well done openssl. IETF hacking of SSL architecture to impose PKI into the 
body of a T-layer protocol machine is subjectively the wrong thing to do. Go 
back to 1000 winsock hooks, the way we intended it to all work so we could 
have a 1000 varieties of re-handshaking (and session key storage), during 
session restarts.

>>forbidden to detect DNS spoofing, but IMO DNS problems should be fixed

TLS/SSL is a TCP-level solution. Dont attempt to solve N-layer security 
issues at the T-layer. I know SSL is popular; we know all IPSEC application 
on end-user host is a miserable deployment experience. Given SIP URI can 
already be resolved with or without DNS-based ENUM, with SSL involvement, 
lets not force IETF changes into the SSL architecturem just becuase we are 
forcing DNS security issues into the SSL equation. The DNS hammer and DNS 
nails metaphor comes to mind.