6 jul 2011 kl. 16.01 skrev Iñaki Baz Castillo:
> 2011/7/6 Olle E. Johansson <o...@edvina.net>:
>> Now, consider that a UA has configured a proxy as an outbound proxy. The
>> connection between them is out of scope for now.
>>
>> The UA issues a call to SIPS:al...@georgia.example.com
>> The proxy does NAPTR/SRV resolution and comes up with a server that presents
>> a certificate
>>
>> A) that is expired
>> B) that is showing "evilstate.example.com" as the domain
>
> As a sidenote: a TLS certificate can contain various SIP domains by
> using the AltSubject field.
>
>
>> C) that is valid
>>
>> Now, in the case of C, the proxy adds a via header with "sips:192.168.40.20"
>> and forwards the message to the next proxy, which forwards to a UA. On
>> return, the proxy tries to set up a secure connection for the response to
>> 192.168.40.20, but fails since the certificate is valid for
>> "alabama.example.com" only.
>>
>> D) What is the valid action? Drop the response?
>
> Good question. However, checking a server certificate (matching the
> domain) just makes sense (IMHO) for requests. This is, an UAC sends a
> request to a proxy/server (depending Route or RURI). The proxy/server
> presents a TLS certificate including N certified domains. The UAC
> match the request destination domain against the domains in the
> certificate.
>
> But in case of a response I see no way to apply the same. Which is the
> destination of a SIP response? it must only be routed according to
> section XX.XX (sorry, no time now) of RFC 3261, this is, typically
> using the same connection if it's TCP/TLS or inspecting the Via
> sent-by/received/rport in case of UDP. So I don't fully understand
> when you say "the proxy tries to set up a secure connection for the
> response to 192.168.40.20".
Unless the proxy receiving the request requested a client certificate it can
NOT reuse the connection for the response here if the Via has a SIPS: uri. It
needs to validate the SIPS session and get the server certificate for the
response... The UA can and should send the response trying to reuse the same
connection though. THat's why I used two proxys in this example.
>
>
>
>
>> So my question is what to do in case of A, B, C and D?
>
> I expect:
>
>
>> A) that is expired
>
> In this case, the TLS communication fails to be established so it's
> like a transport error and the UAC should internally generate a 503
> error (and maybe perform SRV failover and so).
>
>
>> B) that is showing "evilstate.example.com" as the domain
>
> IMHO the same as above. Internal 503 error.
In that case, we need a warning or reason code that explains.
>
>
>
>> Side notes:
>>
>> One can imagine a large number of failures here if one messes with Contact:,
>> Record-route and Route headers and others. RFC 6216 is not very helpful:
>>
>> "If a client is trying to set up a TLS
>> connection to good.example.com and it gets a TLS connection set up
>> with a server that presents a valid certificate but with the name
>> evil.example.com, it will typically generate an error or warning of
>> some type. "
>>
>> "some type" is not very exact and doesn't really cover proxy2proxy.
>
> I expect it means errors like in web browsers when navigating through
> pages with invalid certificate (a pop-up, a warning somewhere). IMHO
> this point is not related to SIP protocol itself. If I'm not wrong,
> the client SIP stack must only generate an internal 503 error, maybe
> including a Warning header (if exists) telling about the certificate
> error, so the core layer could pop-up a visible error to the user
> ("the certificate is invalid because....").
A SIP proxy is a middleman and can't show an UI popup to the user of the UA...
It's really hard trying to compare SIP with HTTP in regards to use of TLS.
>
>
>
>> IANA has two warning messages registred for the SIPS usage.
>>
>> We've checked RFC 3261 and the clarifications in RFC 5630 and are still
>> confused. Seems like a 480 response should be used - but theres' not really
>> any good warning messages back more than " 380 "SIPS Not Allowed". There's
>> room for some new warning codes here, like "Invalid server certificate".
>> I'm not sure that 480 is a response I think is valid in all these situations.
>
> IMHO at SIP level this is a transport error so 503 is the correct
> choice. However a Warning header could indicate the exact error. This
> would be useful in order proxy-A to indicate to the UAC the reason it
> couldn't contact another proxy-B (due to invalid certification in
> proxy-B).
>
>
>
>
>> WHo can say whether it's global or local, what would be the global code - if
>> there are no servers in the SRV record set that can show a valid cert?
>> Should we try all servers for _sips._tcp before issuing a global error?
>
> IMHO if there are SRV records and they fail due to invalid
> certificate, RFC 3263 procedures should no continue. This is, don't
> try to perform A query for the domain and so on. Instead fail and
> generate a transport error (503).
...with a proper warning...
>
>
>
>> There are just too many sources of information here even after RFC 5630. And
>> some of us think there are still usecases for ";transport=tls" even though
>> both RFC3261 and RFC 5630 deprecates it. Seems like there's always room for
>> improvement...
>
> After these long debates I'm pretty sure that sips and TLS has failed
> in SIP due to its incredible complexity. There is a specific RFC 5630
> trying to clarify it, and still most of the people don't understand
> it. -1 for IETF in this area.
There's a chicken-and-egg issue here. Maybe the IETF has a lack of feedback
from implementations and developers. And because of that it's too complex and
developers doesn't implement. We really need to work on this and help the SIP
community to be able to secure signalling. In many cases, SIP with TLS is a
requirement for media security (SRTP) since almost all implementations use
SDES, key exchange in the SDP - clear text. If we can't work with TLS, then
media security also is a no-go. And then we're in deep trouble.
/O
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
