[VOIPSEC] H.235

Thu May 25 04:09:59 CDT 2006

Simon,

Thanks a lot for all your references, I  am discovering  your softphone
pacphone which is quite interesting.. I am also discovering that gungk has a
h323 nat traversal feature which pacphone supports, I will definitely have a
deep look at it.

Your references are quite interesting but most of the time, when you want to
setup advanced mecanism, the main blocking issue, is interoperability and
support of this advanced mecanism by CPE/Softphone/SBC/GK/Softswitch
vendors, same for the support of open standards like ENUM, most of the time
vendors are pushing their proprietary technologies.

Your site (packetizer) is great, I recently found this site
http://www.tech-invite.com/ which is also very detailed on SIP/IMS.

Regards,
Abdelkader

On 5/25/06, Simon Horne <s.horne at packetizer.com> wrote:
>
>  At 04:33 AM 25/05/2006, you wrote:
>
> Simon,
>
> There is certainly a huge number of potential use case of H235, but
> CAT/Radius authentication is the easiest way from what i've seen yet. I
> haven't seen much CPEs/softphone supporting more advanced mode of H235
> authentication and same for AGK/SBC. But I would be interested in having
> your feedback on this and sources/references of such devices/deployment.
>
>
> Certainly you can chain CAT,MD5 and H.235.1 together in one registration
> message and the server can choose one method to authenticate by. The same
> can apply for the call setup message (invite message in SIP) where you might
> have a subscription based support line service where you don't want your
> subscribers to unnecessarily register on your network but you would like
> them to be able to call in . You can provide them with a ENUM or alike which
> they can call however the access is protected from SPITers by a user name
> and password which you issue to your subscribers. Support for this is
> available open source in the OpenH323 project (
> http://sourceforge.net/projects/openh323)
>
> You may have the situation of a bank (as I posted some months back) where
> both the customer and the bank employee must ensure they know who they are
> talking to. You may want to issue Digital Certificates to authenticate bank
> customers and employees directly with eachother end to end.
>
> The real power of H.235 is that you can embed key exchanges (for media
> encryption) within existing messages, so as the normal call setup
> progresses, the caller is authenticated and media keys are being negotiated.
> This methodology allows the ubiquitous negotiation of encryption keys BEFORE
> the first ring on the remote phone (0-ring pickup) and does not require any
> additional messaging and if you media encrypt over standard RTP it should
> work with (in non-encrypted mode) and through any standard H.323gatekeeper/proxy. It is very possible to setup a call, authenticate each
> party (PKI), generate a session key (diffie-hellman) in under 400ms on a
> mid-range standard PC.
>
> See PacPhone (softclient) www.pacphone.com for a real world working
> example of how this is done. It can also manage multiple encrypted calls at
> the same time and if you use GnuGK www.gnugk.org you can do it all
> ubiquitously from behind a NAT.
>
>
>
> And regarding the PKI, let me quote Zimmerman's draft on zrtp, because I
> have the same opinion moreover I originaly am from the security field before
> moving to voip/telecom. Note that this is my opinion for a carrier grade
> deployment... I truly believe that a PKI for a small scale could remain
> managable...
>
>
> "  A decade of industry experience has shown that deploying centrally
>    managed PKIs can be a painful and often futile experience.  PKIs are
>    just too messy, and require too much activation energy to get them
>
>    started.  Setting up a PKI requires somebody to run it, which is not
>    practical for an equipment provider.  A service provider like a
>    carrier might venture down this path, but even then you have to deal
>
>    with cross-carrier authentication, certificate revocation lists, and
>    other complexities.  It is much simpler to avoid PKIs altogether,
>    especially when developing secure commercial products."
>
>
> Certainly where there is a need for PKI there is a market.
> SKYPE generates keys and uses a central key store and it had 6 million
> on-line last time I looked. TLS, (which uses PKI) to secure the SIP
> signalling channel which is a must especially if you are using sdesc,  HTTPS
> which uses PKI to encrypt traffic to secure websites, DKIM, VPN's etc are
> all examples of secure commercial PKI, Versign is a entire business based on
> PKI.
>
> Certainly there is complexity however if the implementation is automated
> and done properly the impact on the user can be minimal.
>
> Simon
>
>
>
>
>
>
> On 5/22/06, *Simon Horne* <s.horne at packetizer.com> wrote:
>
>
> Abdelkader
>
> H.235 has a lot more than just CAT and Radius support, it can be used to
> embed user/pass, digital certificates, encrypted shared secret material into
> almost any H.323 message which means that potentially any message (or all)
> can be authenticated or used for key exchange or both. It is quite legal to
> put a user/pass (H.235.1) and a PKI & diffie-hellman (H.235.2) in the same
> H.235 field of a single H.323 message to do 2 different functions
> Per-Call admission control at the border element (with radius support) and
> end-to-end certificate based authentication and encryption.
>
> Simon
>
>
>
> At 12:50 AM 22/05/2006, Qos Lab wrote:
>
> Michael,
>
> From what i've seen, cisco like implementation of H235 (search for H235
> CAT cisco access token) is very nice, more over you can have  H235
> authentication through a Radius authentication server thanks to this
> implementation.
>
> Abdelkader
>
> On 5/10/06, *Simon Horne* <s.horne at packetizer.com> wrote:
>
> Michael
>
> They are in the most part final drafts (and almost identical to the
> standards document) and free, They are kept up to date by a college who is
> closely associated with the ITU, all 'official' standards have to be
> purchased from the ITU.
>
> Simon
>
> Also, a concise list of SIP related RFC's are also available
> http://www.packetizer.com/voip/sip/standards.html
>
>
> At 04:21 PM 10/05/2006, Michael Prochaska wrote:
> >thanks,
> >but are these the official standards or only drafts for the year 2006?
> >
> >i've thought i have to pay for them...
> >
> >regards,
> >michael
> >
> >
> >Simon Horne schrieb:
> >>The ITU last year changed the numbering system for the H.235 series from
> >>Annex D,E etc to H235.x notation.
> >>Basically the following were renamed
> >>H.235AnnexD  -> H.235.1
> >>H.235AnnexE  -> H.235.2
> >>A complete list of draft standards are available free from
> >>http://www.packetizer.com/voip/h323/standards.html
> >>Simon
> >>
> >>At 06:44 AM 10/05/2006, you wrote:
> >>>hi,
> >>>it would be great if there is anybody out there who can give me a short
> >>>overview over H.235.
> >>>
> >>>everytime i read annex D, annex e, and so on. but on the itu-t homepage
> >>>there are no annexes but substandards (h.235.1, ....).
> >>>
> >>>i thought that the annexes became substandards, but i've read a
> >>>scientific paper from the year 2005 which speaks from annexes....i'm
> >>>really confused
> >>>
> >>>thanks very much in advance,
> >>>michael
> >>>
> >>>_______________________________________________
> >>>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
>
>