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

[Chris Boulton]

> -----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)?

[Chris Boulton] Correct.

  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.

[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
about this:-

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
service.

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.

  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)

[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).

-hadriel
 




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.