[VOIPSEC] IPv6 and the demise (or not) ofNAT(wasRe: Interactive Connectivity Establishment (ICE))
cboulton at ubiquity.net
Thu Nov 17 08:57:36 GMT 2005
> -----Original Message-----
> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org]
> 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
> 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
> 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
[Chris Boulton] Correct.
They have the same transitive trust issues you
(correctly) ascribe to TLS, no? For example the sip-identity one: not
because it assumes TLS be used to avoid the many weaknesses in it, but
the assumption that the authorizing agent is correct. Since it's
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
middle-man breaks the identity accuracy.
[Chris Boulton] I can see your direction and agree that you trust the
auth proxy (service). The draft recommends that TLS be used for the
first hop to the auth proxy which is not quite the same as trusting
unknown nodes further down the signaling path. The draft does talk
Accordingly, direct TLS connections SHOULD be used between the UAC
and the authentication service whenever possible. The opportunistic
nature of this mechanism, however, makes it very difficult to
constrain UAC behavior, and moreover there will be some deployment
architectures where a direct connection is simply infeasible and the
UAC cannot act as an authentication service itself. Accordingly,
when a direct connection and TLS are not possible, a UAC should use
the SIPS mechanism, Digest 'auth-int' for body integrity, or both
when it can.
[Chris Boulton] Remember that a UAC can also act as an authentication
As for SBC's breaking the hash, it's not so much the call-id (SBCs don't
have to change that),
[Chris Boulton] Agreed - but I've seen some that do.
as it is the contact address and SDP info.
[Chris Boulton] Yes.
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
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
will not match the From uri domain and shouldn't be accepted by the UA
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
well. (ie, my provider foo.com is telling me this incoming call is from
John at bar.com, so I believe it)
[Chris Boulton] Yep - an SBC could be the 'auth' service but I suspect
that in many deployments it will not (e.g. it will either be in the
endpoint or at a first hop outbound proxy).
Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding. Thank you.
More information about the Voipsec