GSS-API Programming Guide

mutual authentication

When a context is established, a context initiator must authenticate itself to the context acceptor. In some cases the initiator might request that the acceptor authenticate itself back. If the acceptor does so, the two are said to be mutually authenticated.

name

The name of a principal, such as "joe@machine." Names in the GSS-API are handled through the gss_name_t structure, which is opaque to applications. See also exported name, Mechanism Name (MN), name type, principal.

name type

The particular form that a name is given in. Name types are stored as gss_OID types and are used to indicate the format used for a name. For example, the name "joe@machine" would have a name type of GSS_C_NT_HOSTBASED_SERVICE. See also exported name, Mechanism Name (MN), name.

opacity

See opaque.

opaque

A particular piece of data is said to be opaque if its value or format is not normally visible to functions that use it. For example, the input_token parameter to gss_init_sec_context() is opaque to the application, but significant to the GSS-API; similarly, the input_message parameter to gss_wrap() is opaque to the GSS-API but important to the application doing the wrapping.

out-of-sequence detection

Many security mechanisms can detect if messages in a message stream are received out of their proper order. Message detection, if available, must be requested at context-establishment time.

per-message token

See token.

principal

A uniquely named client/user or server/service instance that participates in a network communication; GSS-API-based transactions involve interactions between principals. Examples of principal names include:

joe
joe@machine
nfs@machine
123.45.678.9
ftp://ftp.company.com


	MN See Mechanism Name (MN). mutual authentication When a context is established, a context initiator must authenticate itself to the context acceptor. In some cases the initiator might request that the acceptor authenticate itself back. If the acceptor does so, the two are said to be mutually authenticated. name The name of a principal, such as "joe@machine." Names in the GSS-API are handled through the gss_name_t structure, which is opaque to applications. See also exported name, Mechanism Name (MN), name type, principal. name type The particular form that a name is given in. Name types are stored as gss_OID types and are used to indicate the format used for a name. For example, the name "joe@machine" would have a name type of GSS_C_NT_HOSTBASED_SERVICE. See also exported name, Mechanism Name (MN), name. opacity See opaque. opaque A particular piece of data is said to be opaque if its value or format is not normally visible to functions that use it. For example, the input_token parameter to `gss_init_sec_context()` is opaque to the application, but significant to the GSS-API; similarly, the input_message parameter to `gss_wrap()` is opaque to the GSS-API but important to the application doing the wrapping. out-of-sequence detection Many security mechanisms can detect if messages in a message stream are received out of their proper order. Message detection, if available, must be requested at context-establishment time. per-message token See token. principal A uniquely named client/user or server/service instance that participates in a network communication; GSS-API-based transactions involve interactions between principals. Examples of principal names include: `joe` `joe@machine` `nfs@machine` `123.45.678.9` `ftp://ftp.company.com` See also name, name type. privacy See confidentiality. QOP See Quality of Protection (QOP). Quality of Protection (QOP) A parameter used to select the cryptographic algorithms to be used in conjunction with the integrity or confidentiality service. With integrity, the QOP specifies the algorithm for producing a Message Integrity Code (MIC); with confidentiality, it specifies the algorithm for both the MIC and message encryption. replay detection Many security mechanisms can detect if a message in a message stream has been incorrectly repeated. Message replay detection, if available, must be requested at context-establishment time. security flavor See flavor. security mechanism See mechanism. security service See service. server A principal that provides a resource to network clients. For example, if you `rlogin` to the machine `boston.eng.acme.com`, then that machine is the server providing the `rlogin` service. service 1. (Also, network service) A resource provided to network clients; often provided by more than one server. For example, if you `rlogin` to the machine `boston.eng.acme.com`, then that machine is the server providing the `rlogin` service. 2. A security service can be either integrity or confidentiality, providing a level of protection beyond authentication. See also authentication, integrity and confidentiality. token A data packet in the form of a GSS-API `gss_buffer_t` structure. Tokens are produced by GSS-API functions for transfer to peer applications. Tokens come in two types. Context-level tokens contain information used to establish or manage a security context. For example, `gss_init_sec_context()` bundles a context initiator's credential handle, the target machine's name, flags for various requested services, and more into a token to be sent to the context acceptor. Message tokens (also known as per-message tokens or message-level tokens) contain information generated by a GSS-API function from messages to be sent to a peer application. For example, `gss_get_mic()` produces an identifying cryptographic tag for a given message and stores it in a token to be sent to a peer with the message. (Technically, a token is considered to be separate from a message, which is why `gss_wrap()` is said to produce an output_message and not an output_token.) See also message.