Showing posts with label authentication. Show all posts
Showing posts with label authentication. Show all posts

Thursday, December 3, 2015

GNU Gatekeeper 4.0 available

I am pleased to announce the release of GNU Gatekeeper 4.0.

It is now available from https://www.gnugk.org/h323download.html.

This release includes source code suitable for Linux, Windows, MacOS X,
FreeBSD, NetBSD, OpenBSD and Solaris and executables for Linux.

GnuGk 4.0 includes many new features as well as some important bug
fixes, but remains fully compatible with your previous configuration
files.

Whats new ?
  • rewrite of the H.235 password authentication - much better interoperability and much more secure (it is high time to get ride of MD5 based authentication!)
  • IP authentication for all RAS and Q.931 messages
  • important IPv6 updates and fixes
  • support for TCS0 call transfers ("reroute") that can be initiated from applications
  • better NAT traversal support for unregistered endpoints
  • better blocking of spam calls using SQLAuth
  • per endpoint codec filtering
  • DisplayIE rewriting
  • more secure handling of status port passwords (only hash stored)
  • important fix for ODBC database driver
  • CalledPartyNumber IE rewriting for better Polycom interoperability
  • bug fixes

Some of the new 4.0 features are discussed in more detail this post:
https://blog.gnugk.org/2015/11/gnu-gatekeeper-40-features.html


Changes from 3.9 to 4.0
  • [...PasswordAuth] CheckID switch is now deprecated, use [H235] CheckSendersID instead
  • provide vendor informations from ARQ or Setup as %{Vendor} in SQLAuth CallQuery
  • prepend timestamp to events in status port backlog
  • BUGFIX(Routing.cxx) remove newlines from vendor string before sending out  RouteRequest to virtual queue
  • BUGFIX(gksql_odbc.cxx) fix DSN initialization when having multiple DSNs at the same time
  • new switch: [RoutedMode] UpdateCalledPartyToH225Destination=1 to always rewrite the CalledPartyNumberIE in Setup to the first E.164 of the H.225 destinationAddress
  • BUGFIX(ProxyChannel.cxx) fix crash on shutdown
  • new settings for [RoutedMode] ScreenDisplayIE=: 'Calling', 'Called', 'CallingCalled' to set the DisplayIE to the (rewritten) caller ID
  • new switch: [RoutedMode] AppendToDisplayIE= to add a string to the DisplayIE when ScreenDisplayIE= is on
  • changed default: H.460.18 keep-alive in traversal zone between neighbors now defaults to 19 sec (was 29)
  • new switch: [RoutedMode] H46018KeepAliveInterval=
  • BUGFIX(ProxyChannel.cxx) better port detection for H.239 when IgnoreSignaledPrivateH239IPs=1
  • BUGFIX(gkacct.cxx) %{caller-port} and %{called-port} now default to "0" instead of the empty string when not available (eg. in direct mode) to avoid SQL errors when they are stored in a numeric column
  • BUGFIX(RasSrv.cxx) fix additive registration with parent gatekeeper
  • BUGFIX(ProxyChannel.cxx) fix IPv6 dual-stack proxy on Linux and Windows
  • dump file descriptor usage on USR2 signal (Linux only)
  • new switch [RoutedMode] DisableFastStart=1
  • support for H.235.1, incl. setting and checking tokens in all RAS and Q.931 messages
  • extend SimplePasswordAuth and FileIPAuth to all RAS and all Q.931 messages
  • store only PBKDF2 hash for [GkStatus::Auth] password in config, not a recoverable password
  • BUGFIX(ProxyChannel.cxx) fix crash when receiving message without UUIE
  • new switch [EP::] DisabledCodecs=
  • much improved TCS0 3rd-party call transfer using 'Reroute' command on status port
  • BUGFIX(Routing.cxx) add field for destination alias in ARQ if missing and a dynamic routing policy sets it
  • BUGFIX(ProxyChannel.cxx) fix crash in H.235 Media for endpoints with more than 64 capability entries in TCS
  • new switch [Proxy] AllowSignaledIPs= to skip to skip auto-detect for network when IgnoreSignaledIPs=1

Sunday, November 1, 2015

New GNU Gatekeeper 4.0 Features

H.235 password authentication

Until now, GnuGk only supported MD5 password tokens well. The password
only secured RRQ and ARQ messages in the direction from the endpoint to
the gatekeeper and MD5 is considered a pretty weak algorithm. MD5
tokens are widely supported by vendors and are usually called "H.235",
but strictly speaking they aren't part of any ITU spec.

The new implementation in GnuGk closely follows the H.235.1
specification. It secures all RAS (RRQ, ARQ, BRQ, DRQ etc.) and all
Q.931 (Setup, Alerting etc.) messages. It also secures both directions,
so the gatekeeper can check every message if it is really from the
endpoint and also the endpoint can make sure its really talking to its
gatekeeper.

The interpretation of H.235.1 varies between vendors (or their
implementation is just buggy, your call). Thats why GnuGk defaults to
rather strict checks, but has configuration switches ([H235] config
section) to enable interoperability with vendor implementations.

During development I ran tests with AudioCodes, Polycom, Inovaphone and
H323Plus endpoints.

For example if you are using a AudioCodes gateway, you should set

[Gatekeeper::Auth]
SimplePasswordAuth=required;RRQ,ARQ,DRQ,RAI,Setup,Alerting,Connect,ReleaseComplete,Facility

[H235]
UseEndpointIdentifier=1
RequireH2351GeneralID=0
FullQ931Checking=1

You can even tighten security with CheckID=1 in [SimplePasswordAuth].


Per endpoint codec filtering

Suppose you have this MCU, that works fine when endpoints use H.263,
but a lot of calls using H.264 fail. Now you can simply disable H.264
in your GnuGk config, even if that MCU doesn't give you that option:

[RoutedMode]
H245Routed=1

[EP::MyMCU]
DisabledCodecs=genericVideoCapability

Now that MCU can't negotiate H.264 any more and all calls will use
H.263. All other endpoint can still use all codecs.

Or suppose you have a Radvision MCU that is rather strict about using
symmetric codecs. Many endpoints don't handle symmetric codec
requirements correctly, but it often helps to simply disable H.239 if
you aren't using it away:

[EP::RadvisionMCU]
DisabledCodecs=extendedVideoCapability;genericControlCapability

If all your endpoints follow all the specs, you'll probably never need
this feature. Unfortunately not all do and thats when this feature
comes in handy.

IPv6 and IPv4-IPv6 conversion

Actually this is not a new feature in GnuGk 4.0, but 4.0 brings some
significant bug fixes and improvements.

We all know IPv6 will come some day, but hasn't so far, because some
equipment still works better with IPv4 or some network doesn't support
it, yet etc.

With GnuGk, you don't have to convert your network to IPv6, you can
simply add it as another option and GnuGk will convert between IPv4 and
IPv6 whenever necessary. So you can keep all your legacy endpoints that
only support IPv4 and still have them reach other endpoints that work
on IPv6.

I would suggest you give IPv6 a try in your network now, before things
get very urgent and must be done in a rush.

The config part in GnuGk is rather easy:

[Gatekeeper::Main]
EnableIPv6=1

In all places where you can put an IPv4 address, you can also place an
IPv6 address.

BTW: If you want to see your IPv6 H.323 calls in Wireshark, you need a
new version. I worked with the Wireshark developers to get the
disection fixed. That patch will probably be in 2.0.0rc1.

Wednesday, January 8, 2014

Whats new in GnuGk 3.5 ? Part 1: New encryption features

Easier TLS configuration

H.323 encryption as implemented by virtually all commercial vendors is easily circumvented by Man-in-the-Middle attacks. So it is very important to secure at least your gatekeeper-to-gatekeeper signaling connections over the internet with TLS. See https://www.gnugk.org/h323-encryption.html for background information. (Its a bit like installing a huge lock and then leaving the key under the doormat for everybody to use.)

GnuGk can close this security hole by encrypting the signaling connection using TLS and verifying  the certificates of clients and servers.

With GnuGk 3.5, you don't have explicitly configure TLS for each partner. On all RAS connections GnuGk will use H.460.22 to signal support for TLS encryption and will automatically use it as when the partner supports it.

Stronger RTP encryption with larger keys

When the media encryption spec (H.235.6) was published by the ITU in 2005, it contained an error that prevents all vendors from using Diffie-Hellman tokens larger than 2048 bits. This error is being corrected by the ITU now and the new spec is about to be published.

GnuGk 3.5 supports the upcoming specification and can be configured to use AES256 with tokens of up to 8192 bits when you configure it to add media encryption to your calls.

Support for legacy authentication with DES-ECB

GnuGk 3.5 adds support for username / password authentication using the DES standard. This kind of authentication is very weak and should only be used for interoperability with old equipment that doesn't support anything else (eg. some Avaya endpoints).