GSS-TOKEN

gss-token is simple program that generates and consumes BASE64 encoded GSS tokens. It comes in handy when testing as you can cut and paste the tokens between terminal windows to test the Kerberos rather than having to have a client/server (like knc(1)) program to do it. It’s especially helpful when you have firewalls to configure to let extra ports through.

BUILDING

To build:

	$ autoreconf -f -i
	$ ./configure
	$ make

INTERESTING USE CASES

Using a command line curl that doesn’t support Negotiate (GSS) Auth

HTTP SPNEGO authentication just uses base64 tokens exactly like those generated by gss-token(1). You add a header that looks like this:

	Authorization: Negotiate YIICgQYGKwYBBQUCoIICdTCCAnGgDTALBgkqhkiG...PLM

gss-token(1) will prepend "Negotiate " to its output if you supply a -N flag, and so:

	$ curl -H "Authorization: $(gss-token -N HTTP@server)" \
	> https://server/path/to/file

will opportunistically send a GSSAPI authentication with your HTTP request.

This technique can be used if curl or wget are compiled without Kerberos support at your site or for clients that don’t support Kerberos at all.

Poor logging on a Kerberos server

Let’s say that you are GSS to authenticate to an HTTP server and it is failing. Many servers do not return useful error messages to clients and they often do not log much of interest either. In this situation, gss-token can come to the rescue. Just:

	$ curl -v --negotiate -u: http://my.server.name
	*   Trying 10.137.0.16:81...
	* Connected to my.server.name (10.137.0.16) port 80 (#0)
	* Server auth using Negotiate with user ''
	> GET / HTTP/1.1
	> Host: my.server.name
	> Authorization: Negotiate YIICgQYGKwYBBQUCoIICdTCCAnGgDTALBgkqhkiG...PLM
	> User-Agent: curl/7.88.1
	> Accept: */*
	>

Note the Authorization that is returned. On the web server host, as the web server’s user, with KRB5_KTNAME set the same as the web server, run:

	$ gss-token -r

and past the contents of the Authorization header and you will get the error message that the web server should have logged.

Some web servers may log the Authorization header. In this case, you can still use gss-token(1) to examine what’s wrong. If the log message is older than clock-skew, just setup /tmp/my-krb5.conf and increase clock-skew for the purposes of your test.

Benchmarking

gss-token(1) can be used to perform basic benchmarking, however, you must be very careful to disable certain Kerberos behaviours such as using DNS to canonicalise hostnames or you will find that you are just testing nscd’s speed. Once you have crafted a host configuration where:

	$ strace -o /tmp/tr gss-token -n host@host.name

isn’t contacting any external services (assuming that a ticket for host/host.name@REALM is in your ccache), then you are reading to benchmark your Kerberos client implementation:

	$ time gss-token -n -c 1024 host@host.name

When divided by 1024 will let you know how long it takes your local client implementation to generate a base64 gss token.

	$ time gss-token -n -M -c 1024 host@host.name

The -M flag empties the ccache before each authentication. Now you are measuring how long it takes to generate a gss token including the KDC communication. If you subtract the results from the prior benchmark, it should be (on average) the time that it takes for this client to get a response from the KDC infrastructure.

This test is only run serially, but you can get a very rough idea how a KDC responds to load using:

	$ for i in $(seq 32); do
	>	time gss-token -n -M -c 1024 host@host.name &
	> done
	$ wait

Keep in mind:

1. you are only getting a rough idea using this methodology,

2. you are in danger of measuring the client’s performance rather than the KDC’s performance,

3. don’t do this on your production KDCs, spin up a quick local Kerberos REALM and test against a single local KDC.