[VOIPSEC] IPv6 and the demise (or not) ofNAT(wasRe: Interactive Connectivity Establishment (ICE))

[Hadriel Kaplan]

> -----Original Message-----
> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
> Behalf Of Chris Boulton
> 
> [Chris Boulton] TLS is fine for 'hop-by-hop' security but you are
> placing your security trust in elements that are routing further down
> the signaling path.  SIP has no means to force an unknown element to use
> TLS and security can easily be downgraded at a rogue proxy (making
> end-to-end important).
> 
> I dont see why identity/privacy is an issue with an SBC... perhaps Im
> missing something
> 
> [Chris Boulton] Identity uses a hash of key SIP components such as
> Call-ID and the message body to name a few.  As soon as a B2BUA (or SBC)
> alters ANY components in the message that are used for the hash -
> Identity breaks.

By this "Identity" I assume you mean the ietf sip-identity draft (and the
response-auth one)?  They have the same transitive trust issues you
(correctly) ascribe to TLS, no?  For example the sip-identity one: not only
because it assumes TLS be used to avoid the many weaknesses in it, but also
the assumption that the authorizing agent is correct.  Since it's basically
up to the authorizing provider/agent to decide how strong to make the
identity check, isn't that transitive trust in a way?  A weak or malicious
middle-man breaks the identity accuracy.

As for SBC's breaking the hash, it's not so much the call-id (SBCs don't
have to change that), as it is the contact address and SDP info.  Of course
since the SBC sits at the edge of the trust domain, it could be the
authorizing agent and sign the modified values, as any device could.  If the
invite crosses another carrier's SBC, that second one could verify it,
remove it, and re-sign it.  The only rub there is the ultimate cert domain
will not match the From uri domain and shouldn't be accepted by the UA per
the draft, but since the receiving UA in such cases trusts his local
provider domain, one would expect that UA to accept the local domain cert as
well. (ie, my provider foo.com is telling me this incoming call is from
John at bar.com, so I believe it)

-hadriel