[VOIPSEC] H.235
Simon Horne
s.horne at packetizer.com
Thu May 25 12:34:23 CDT 2006
At 05:09 PM 25/05/2006, you wrote:
>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.
The Nat traversal feature is very powerful and allows the softphone to work
anywhere without the NAT hassles. In the open source community we are also
working on inplementing the H.460.18/19 standard for NAT traversal.
>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.
The soft phone encryption mechanism is completely end-to-end and
independent of any intermediaries and is interoperable with most if not all
existing equipment So it is possible to place both non-encrypted and
encrypted calls across the same pre-existing H.323 network ubiquitously. If
the remote endpoint supports the mechanism it uses it if not it reverts to
a standard H.323 call. For instance you could use it to make encrypted
calls using an existing Asterisk PBX's or use Cisco call manager to control
both secure and unsecured endpoints and calls. It's quite versatile.
Simon
>Your site (packetizer) is great, I recently found this site
><http://www.tech-invite.com/>http://www.tech-invite.com/ which is also
>very detailed on SIP/IMS.
>
>Regards,
>Abdelkader
>
>On 5/25/06, Simon Horne
><<mailto:s.horne at packetizer.com>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>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.323 gatekeeper/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) <http://www.pacphone.com/>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
>><http://www.gnugk.org/>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
>>><<mailto:s.horne at packetizer.com>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
>>>>><<mailto:s.horne at packetizer.com>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>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>http://www.pack
>>>>>> etizer.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
>>>>>> >>><mailto:Voipsec at voipsa.org>Voipsec at voipsa.org
>>>>>> >>>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>_______________________________________________
>>>>>>Voipsec mailing list
>>>>>><mailto:Voipsec at voipsa.org>Voipsec at voipsa.org
>>>>>>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
More information about the Voipsec
mailing list