# Copyright 1993 by OpenVision Technologies, Inc. # # Permission to use, copy, modify, distribute, and sell this software # and its documentation for any purpose is hereby granted without fee, # provided that the above copyright notice appears in all copies and # that both that copyright notice and this permission notice appear in # supporting documentation, and that the name of OpenVision not be used # in advertising or publicity pertaining to distribution of the software # without specific, written prior permission. OpenVision makes no # representations about the suitability of this software for any # purpose. It is provided "as is" without express or implied warranty. # # OPENVISION DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, # INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO # EVENT SHALL OPENVISION BE LIABLE FOR ANY SPECIAL, INDIRECT OR # CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF # USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR # OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. This directory contains a sample GSS-API client and server application. Each invocation of the client performs the following exchange with the server: 1. The client and server establish a GSS-API context. The server prints the identity of the client. 2. The client sends a sealed (encrypted) message to the server. 3. The server decrypts the message and prints it. 4. The server produces a signature block for the message and sends it to the client. 5. The client verifies the signature block. Obviously, this exchange does not perform a tremendously valuable function; however, it demostrates the use of primary GSS-API interfaces. The server's command line usage is gss-server [-port port] [-v2] service_name where service_name is a GSS-API service name of the form "service@host". The server will accept TCP connections on port (default 4444) and establish contexts as service_name. The -v2 option means that the GSSAPI v2 calls should be used (and tested). The client's command line usage is gss-client [-port port] [-v2] [-d] host service_name msg where host is the host running the server, service_name is the service name that the server will establish connections as, and msg is the message. The client connects to the TCP on
(default 4444) and performs the exchange. The "-d" option specifies delegation - a forwardable TGT will be sent to the server, which will put it in its credential cache (you must kinit -f for this to work). The -v2 option means that the GSSAPI v2 calls should be used (and tested). If you are using this sample application with OpenVision's Kerberos 5 GSS-API mechanism: 1. Link the client and server with -lgssapi_krb5 -lkrb5 -lcrypto -lisode -lcom_err. 2. Make sure that the principal corresponding to service_name is in the default keytab on the server host, and that the gss-server process can read the keytab. For example, the service name "host@server" corresponds to the Kerberos principal "host/server.domain.com@REALM". This sample application uses the following GSS-API functions: gss_accept_sec_context gss_release_buffer gss_acquire_cred gss_release_cred gss_delete_sec_context gss_release_name gss_display_name gss_seal gss_display_status gss_sign gss_import_name gss_unseal gss_init_sec_context gss_verify Barry Jaspan, email@example.com OpenVision Technologies, Inc.