PreviousNext

GSSAPI and Protection Levels

Unlike authenticated RPC, where the client chooses a protection level that is then applied automatically to all data transferred in either direction, applications that use GSSAPI must explicitly protect data on a message-by-message basis. This allows an application the option of protecting only particularly sensitive messages, and avoids the overhead of security processing for other messages. (That is possible with RPC too, of course, provided that the programmer is willing to specify security attributes on an RPC call-by-call basis.)

GSSAPI offers two distinct types of protection through the gss_sign( )/ gss_verify( ) routines and the gss_seal( )/gss_unseal( ) routines, as follows:

· The gss_sign( ) routine creates a token containing an encrypted signature to protect the integrity of the message data. The token contains only the signature (not the message data). The application must send both the token and the message to which it applies to the peer application for verification. The receiving application calls the gss_verify( ) routine to check the signature.

· The gss_seal( ) routine creates a token containing both an encrypted signature and the message data, and may optionally encrypt the message data. Only the token need be sent to the peer application, which processes it by using the gss_unseal( ) routine to verify the signature and extract the message data.

Three distinct signature algorithms are supported by the per-message protection routines. An algorithm may be requested by providing one of several constants to the qop_request parameter (qop stands for "quality of protection'') of either the gss_sign( ) or the gss_seal( ) routine. The constants are as follows:

GSSDCE_C_QOP_DES_MAC
Conventional DES MAC. Slow but well understood.

GSSDCE_C_QOP_DES_MD5
DES MAC of an MD5 (Message Digest #5) signature. Faster than DES MAC.

GSSDCE_C_QOP_MD5
MD5 signature. Fastest supported signature algorithm. The default.