Warning

This is a work in progress, largely intended to solicit the opinion of interested parties.

Introduction

GSSAPI is a standard for secure communications between two parties. Notably, it has become the de-facto standard portable API for Kerberos, so much so that “GSSAPI” often implies “Kerberos” despite the existence of things like SPKM and LIPKEY.

GSSAPI is, at its core, an online client/server (“initiator” and “acceptor” in its terminology) architecture. The basic flow of communication is to initiate a “context” (and have that context be accepted) before messages may be passed within that context, using, optionally, confidentiality and integrity mechanisms provided by the underlying cryptographic mechanism. That is, Alice may establish a context for secure communication with Bob, and another for Carol, and so on. (Other things are possible, including delegation of identity or rights and replay detection on the stream of messages, but these are not germane to this document.)

However, GSSAPI has no intrinsic mechanism for asynchronous communication with another party; there is no mechanism, Alice having established a context with Bob (and, optionally, Carol), for Alice (or Bob) to seal or box a message such that it can be passed to Carol, who can then forward it to Bob in a verifiable, confidential way. Bob should be able to verify that

Neither Carol nor any other agent should be able to learn anything about the message body (except an approximation of its length) or the identities of Alice, Bob, or Carol from the message itself.

Another way to think about the intended use of sealing is that Alice may wish to allow Carol to prove to Bob that Alice and Carol are in communication and to reliably prove Alice’s opinions of that communication to Bob. For intuition, imagine Alice as something akin to a Kerberos TGS, having active contexts with both Bob and Carol; Alice’s sealing of a message for Carol to give to Bob is akin to granting a service ticket. The key is that the sealed message carries the identities of its originator (Alice) and relaying party (Carol) and may only be unsealed by its recipient (Bob).

API Calls