GSSAPI Authentication

This page describes how to configure GSSAPI authentication.

Overview

Dante supports the SOCKS version 5 GSSAPI authentication mechanism, that allows secure authentication and encryption of data transferred. GSSAPI is typically used with Kerberos and this is what is documented in this page.

GSSAPI authentication with SOCKS works as follows. The client first obtains a Kerberos ticket from the Key Distribution Center (KDC). The client then connects to the socks server and offers the GSSAPI authentication method. During the GSSAPI SOCKS negotiation with the socks server, the client uses the ticket as a basis for authenticating to the socks server, and a GSSAPI-authenticated context will be established between the client and the socks server if successful.

Environment setup

The Dante server supports GSSAPI authentication via Kerberos, with both MIT Kerberos and Heimdal supported. This page assumes that Kerberos has been configured and is working. Descriptions on how to configure Kerberos can be found several places on the Internet, including the following:

Dante specific setup

Before use, a principal for the Dante socks server will need to be added to the KDC and a keytab file extracted. The Dante socks server will by default use a service name of rcmd, and expects to find its keytab file as "/etc/sockd.keytab" on the machine it is running, but these defaults can be changed with the gssapi.servicename and gssapi.keytab keywords in the Dante configuration file. A typical principal name for a Dante socks server would be "rcmd/socks.example.com@REALM".

The /etc/krb5.conf file (or Kerberos implementation equivalent) should also be set up correctly on the machine running the Dante socks server.

While building Dante, it should be verified that the GSSAPI implementation on the machine has been found. At the end of the configure output, under the header "Configure status", there should be an entry for GSSAPI, and if found, it should look like this:

GSSAPI:            Enabled

Starting the Dante socks server with the -d2 option to enable debugging can be helpful during initial testing.

Client operation

Before authentication with a SOCKS server with GSSAPI it is necessary to obtain a Kerberos ticket. Depending on the OS configuration, a ticket might be obtained at login, or it might be necessary to run kinit or a similar program. By using the klist command it should generally be possible to verify whether a valid ticket exists, in which case, output similar to this should be printed:

Credentials cache: FILE:/tmp/krb5cc_1001
        Principal: user@EXAMPLE.ORG

  Issued           Expires          Principal           
Oct 25 16:38:28  Oct 26 17:38:28  krbtgt/EXAMPLE.ORG@EXAMPLE.ORG

Without a valid ticket it will not be possible to authenticate. By enabling logging in both the server and client it should be possible to analyze any problems. The client and server configuration pages describe how to do this.

Server configuration

These defaults are used when gssapi is enabled:

#gssapi.enctype: clear integrity confidentiality
#gssapi.keytab: FILE:/etc/sockd.keytab
#gssapi.servicename: rcmd

The clear value usable with the gssapi.enctype will cause data to be transmitted without being ecrypted, and should not be used unless this is desired.

Several GSSAPI related keywords, such as those above, can be used in the server configuration file, but it should generally not be necessary to change these from their default values. It is currently not possible to change the defaults globally, but they can be overridden in the pass rules like this:

#server compatibility with NEC-style gssapi clients
client pass {
        from: 192.0.2.0/24 to: 0.0.0.0/0
	log: error # connect disconnect
        clientcompatibility: necgssapi
}

Interoperability with legacy NEC clients or server

If the server needs to work with clients that rely on the GSSAPI handling behavior of the NEC SOCKS server, it might be necessary to enable this type of behavior by setting the clientcompatibility keyword to necgssapi in the client pass rules in the server.

The server will still work with clients that do not require this. It should only be enabled if clients that require this need to access the server because they depend on a bug in the GSSAPI implementation in SOCKS servers based on the NEC SOCKS code.

Note that this bug results in a less secure session than would otherwise be used; it is thus not recommended that this option is enabled unless it is needed.

#client compatibility with NEC-style gssapi servers
route {                                                                        
        from: 0.0.0.0/0 to: 0.0.0.0/0 via: 192.0.2.1 port = 1080            
        proxyprotocol: socks_v4 socks_v5
        method: gssapi
        clientcompatibility: necgssapi
}

A similar clientcompatibility value can be set in the client configuration file, in order for the Dante client to work with servers that rely on the non-standard behavior of the NEC SOCKS client.

Server privileges

No special privileges will typically be required to use this authentication method, but the Dante server must be able to access the keytab file.

Example clientmethod usage

There is no separate gssapi clientmethod.

Example method usage

#authentication methods
method: gssapi

client pass {
        from: 0.0.0.0/0 to: 0.0.0.0/0
	log: error # connect disconnect

        ## gssapi defaults
        #gssapi.enctype: clear integrity confidentiality
        #gssapi.keytab: /etc/sockd.keytab
        #gssapi.servicename: rcmd
}

#generic pass statement - bind/outgoing traffic
pass {  
        from: 0.0.0.0/0 to: 0.0.0.0/0
        command: bind connect udpassociate
        log: error # connect disconnect iooperation
        method: gssapi
}

The authentication configuration template can be used directly for outgoing traffic, it is only necessary to specify the method name.

The gssapi method cannot be used for incoming traffic (bindreply, udpreply).