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.
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:
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
In broader terms, a few basic security models suffice for most 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:
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.
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.
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?
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