Simple use of GSSAPI


preview of usenix submission

Mark Eichin
Cygnus Solutions

Why Security

Now that everybody is on the Internet, it's about time that application protocols started using real security. Intrusion is the news (and junk mail) of the day; even Microsoft is taking it seriously.

Implementing security in an application isn't trivial; it isn't as hard as it generally seems, however. There has been a lack of clear examples, and a strong need for examples with clear design information.

We only discuss the client to server transaction here; local security on the client, as well as security of the data as held on the server, is also beyond the scope of this paper. Consider that there are already existing examples of systems where data were provided securely and then later stolen from the server host.[1]

[1]

The theft of credit card info from ESPN in July 1997 is a well-known example.

Why GSSAPI in particular

GSSAPI provides a security interface that allows a design to be expressed in more abstract terms and then mapped directly to an actual underlying implementation. If the application obeys all the constrains of GSSAPI and doesn't take shortcuts, it should be possible to change security implementations and have the application still work.

Several GSSAPI implementations exist:

Others are used privately. Several large software systems (Oracle and SAP for example) use GSSAPI as their interface to whatever security layer the customer might want.

Design

As with any good programming project, we need to figure out what our requirements and design are first. Our high level requirement is simply "secure the transaction between a finger client and the finger server." "secure" in this case can mean a number of things; we'll limit ourselves to

These happen to cover most things people ever want out of a secure application. Atomic commit/rollback schemes are beyond the scope of this paper, as are higher level electronic payment details; we merely cover basic integrity and protection of the data.

In broader terms, a few basic security models suffice for most applications.

There are more complicated models[2] but these cover most practical applications.
[2]

such as the Zephyr notification system, that involves authentication from a client to a set of servers and then having the server authenticate back down to the destination client.

In order to protect the transaction, we must first identify it. The Finger User Information Protocol is described in RFC1288. The existing protocol has some interesting constraints:

The request itself is described by a simple BNF grammar. There isn't a clear indication of what syntax is appropriate for extensions to the protocol, but we can derive from the grammar a few possibilities for messages that would always be invalid in the current protocol, and treat them as our extensions. It appears that we can only count on characters that are unlikely to appear in usernames. It also appears that if usernames can not contain spaces, any command with two or more runs of spaces is not valid. This would mean that we could use a command string such as "EXTENSION SECURITY GSSAPI xxxxxx" where xxxxxx is the actual encoded GSSAPI token, and the string is terminated with a CRLF. Any existing server should treat such a request as an error. Using multiple words allows the same mechanism to be used for other extensions in the future. The first extension message has to appear in the initial line, because a secure server supporting non-secure clients can't read past the first line before deciding.

Since this extension is what is referred to in the literature as "unspeakably gross", it is best if we can bury it under some wrapper functions so that it doesn't obscure the mechanism of the protocol.[3]

[3]

It isn't clear whether the Eiffel Tower or the Centre Georges Pompidou is more architecturally analogous.

Another possibility is to run the protocol on a different port. This has been done in the past, and is widely considered a mistake. The IANA will not register more ports for an existing protocol; existing services (klogin, eklogin, kpop) use randomly chosen ports, some of which have been assigned to other services.

Finger isn't a particular well designed protocol, and doesn't have extension in mind. The FTP protocol has well defined commands and response codes that identify that a command was not recognized; this made it easy to add AUTH, ADAT, and other security-specific commands. This also means that a client can, at the user's discretion, fall back to a non-secure version of the protocol if the security commands are not recognized.

GSSAPI Finger Client

after connect, do a GSS_init_sec_context, use ftp style host@ vs. finger@ fallback. Pass this token in the request.

Initialize Security Context

	see extract of gssfinger-client.c later

*must* handle CONTINUE_NEEDED, send additional lines as needed, but that's only part of init_sec_context.

use GSS_Wrap with conf_flag set optionally

wait for response; if the first line isn't an "EXTENSION SECURITY GSSAPI" response, conclude that it is normal unprotected finger giving an error, flush it, and either try again with an insecure request or complain to the user.

GSSAPI Finger Server

After accept, look for extension request string in command; if found, GSS_accept_sec_context.

if continue needed, loop and send/read more lines.

use gss_unwrap to get the request

if request was confi, the reply will be too? or have some other flag to allow server to force it?

Design Extensions

Remember that any *real* protocol isn't going to be complete as originally specified, and we will come upon additional demands later.

Add access control lists for users/user classes, for generic features like forwarding, load checking...

Add per-user acl's (in user's homedir) for release of their own info, to themselves or to others