[VOIPSEC] An issue of trust?

[Weidong Shao]

It is not that simple yet. It comes down to the trust model again.

Which Annex option will you follow with H.235?

 shared secret? - impractical with scale
 digital certificate ?    - is  PKI there ?

If PKI exists and works in your system, they are plenty of ways to
achieve true end-to-end security using existing protocols. PKI or a
trust forest is feasible in an enterprise and limited federations but
is difficult at the consumer level on the Internet.

but do consumers really care about security?

Weidong

On 6/15/06, Simon Horne <s.horne at packetizer.com> wrote:
>
> Tyler
>
> Again...Well actually you can...:-)
> In H.323 the call signalling channel H.225 is designed to run end-to-end
> and independent of any intermediaries however it can optionally be routed
> via intermediaries. The decision to route the signalling can be done on a
> case by case basis. When the user registers with the intermediary, a radius
> query can determine if for legal reason (interception) the signalling and
> media must be routed. If so then the signalling is routed otherwise it is
> not. This makes lawful interception very scalable The routing of the
> signalling does not necessarily mean a decrease in security, if you use a
> certificate based or a strong shared secret encryption mechanism to protect
> the media key exchange then the intermediary will not be able to
> reconstruct the media keys easily. For lawful interception the only option
> in this case is to inspect the call signalling and remove the media key
> exchange messages and have the call revert back to a standard non-encrypted
> call.
>
> In H.323, security is already designed into the protocol. The applicable
> group of standards are H.235.x and covers authentication (hop by hop and
> end-to-end) and encryption over both RTP and SRTP (with mikey). Almost all
> H.323 messages are capable of carrying security information. (They are
> called cryptoTokens)
>
> Hopefully, H.325 will streamline the security process a lot more and remove
> some of unnecessary complexity in H.323 however it is only currently in the
> planning phase and it will be several years before it will be implemented.
>
> Simon
>
> At 08:35 AM 16/06/2006, Tyler Johnson wrote:
> >You can't. That's why you have to implement security at the application
> >layer. That means end to end encryption of media an signaling. However, US
> >regulations for CALEA break that. If you do hop to hop security you really
> >don't have any assurance of security beyond the next hop unless you are in a
> >limited federation, but that doesn't scale to the whole Internet.
> >
> >I think the bottom line is to work to get coherent policy implemented at the
> >federal level in the U.S.
> >
> >The other possibility is to think about a new protocol that is designed with
> >security from the ground up, with wiretap in mind. H.325 offers an
> >opportunity here, I think. I don't think it's going to work to reverse
> >engineer this into SIP or H.323.
> >
> >
> >----- Original Message -----
> >From: <Ron_Cramer at cargill.com>
> >To: <Voipsec at voipsa.org>
> >Sent: Thursday, June 15, 2006 6:46 PM
> >Subject: Re: [VOIPSEC] An issue of trust?
> >
> >
> > > It appears I should clarify my question in regards to a Telecom Service
> > > Provider
> > > vs an Internet Service Provider.
> > >
> > > Based on my experience, many enterprises would choose to trust telecom
> > > service providers
> > > to keep data traffic private on a traditional layer 2 service such as
> > > frame relay or voice
> > > services on POTS.  And, would choose not to trust Internet based
> > > communication, but to
> > > mitigate the Internet based risk with firewalls, encryption tunnels, etc.
> > >
> > > Part of the logic used to differentiate between these two choices was that
> > > the traditional layer 2
> > > services provided separation between the virtual private networks of the
> > > many customers serviced
> > > by the Telecom Provider.  Since the packets are being forwarded at layer 2
> > > the Telecom Provider
> > > had no awareness of anything related to the Internet Protocol.  This also
> > > meant that the
> > > Telecom Service Providers customers could not use IP based attacks against
> > > the carrier infrastructure.
> > >
> > > As Telecom Service Providers move to offer IP-ware services - MPLS, VoIP
> > > or whatever
> > > the Telecom Service Providers are vulnerable to IP based attacks.  I know
> > > there
> > > are many papers that state MPLS *can* be deployed with the same level of
> > > security
> > > as a layer 2 service, but how can I *trust* the Telecom Service Provider
> > > will invest
> > > the effort to operate a secure MPLS network.  Or, VoIP, or whatever?
> > >
> > > Thanks and regards,
> > >
> > > Ron
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Cramer, Ron - Ron_Cramer at cargill.com
> > > Sent: Thursday, June 15, 2006 1:19 PM
> > > To: 'Voipsec at voipsa.org'
> > > Subject: An issue of trust?
> > >
> > >
> > > The issue of trust for your Telecom service provider,
> > > either traditional or VoIP based seems to be a fundamental
> > > component for secure communications.
> > >
> > > Can anyone identify an industry standard that an
> > > Enterprise can use to establish trust with a Telecom
> > > vendor?  Something with well established decision
> > > criteria, not just a high level guide to performing a
> > > risk assessment.
> > >
> > > Thanks in advance,
> > >
> > > Ron
> > >
> > > _______________________________________________
> > > Voipsec mailing list
> > > Voipsec at voipsa.org
> > > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> > >
> >
> >
> >_______________________________________________
> >Voipsec mailing list
> >Voipsec at voipsa.org
> >http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
>
>
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>