JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Developer's Guide to Oracle Solaris 11 Security     Oracle Solaris 11.1 Information Library
search filter icon
search icon

Document Information

Preface

1.  Oracle Solaris Security for Developers (Overview)

2.  Developing Privileged Applications

3.  Writing PAM Applications and Services

4.  Writing Applications That Use GSS-API

5.  GSS-API Client Example

6.  GSS-API Server Example

7.  Writing Applications That Use SASL

8.  Introduction to the Oracle Solaris Cryptographic Framework

9.  Writing User-Level Cryptographic Applications

10.  Introduction to the Oracle Solaris Key Management Framework

A.  Secure Coding Guidelines for Developers

B.  Sample C-Based GSS-API Programs

C.  GSS-API Reference

D.  Specifying an OID

E.  Source Code for SASL Example

F.  SASL Reference Tables

Glossary

Index

Glossary

Access Control List (ACL)

A file containing a list of principals with certain access permissions. Typically, a server consults an access control list to verify that a client has permission to use its services. Note that a principal authenticated by GSS-API can still be denied services if an ACL does not permit them.

authentication

A security service that verifies the claimed identity of a principal.

authorization

The process of determining whether a principal can use a service, which objects the principal is allowed to access, and the type of access allowed for each.

client

Narrowly, a process that makes use of a network service on behalf of a user, for example, an application that uses rlogin. In some cases, a server can itself be a client of some other server or service. Informally, a principal that makes use of a service.

confidentiality

A security service that encrypts data. Confidentiality also includes integrity and authentication services. See also authentication, integrity, service.

consumer

An application, library, or kernel module that uses system services.

context

A state of trust between two applications. When a context has successfully been established between two peers, the context acceptor is aware that the context initiator is who it claims to be, and can verify and decrypt messages sent to it. If the context includes mutual authentication, then the initiator knows the acceptor's identity is valid and can also verify and decrypt messages from the acceptor.

context-level token

See token.

credential

An information package that identifies a principal and a principal's identification. A credential specifies who the principal is and, often, what privileges the principal has. Credentials are produced by security mechanisms.

credential cache

A storage space (usually a file) containing credentials stored by a given mechanism.

CRL

Certificate Revocation List

CSR

Certificate Signing Request

data replay

When a single message in a message stream is received more than once. Many security mechanisms support data replay detection. Replay detection, if available, must be requested at context-establishment time.

data type

The form that a given piece of data takes, for example, an int, a string, a gss_name_t structure, or a gss_OID_set structure.

delegation

If permitted by the underlying security mechanism, a principal (generally the context initiator) can designate a peer principal (usually the context acceptor) as a proxy by delegating its credentials to it. The delegated credentials can be used by the recipient to make requests on behalf of the original principal, as might be the case when a principal uses rlogin from machine to machine to machine.

exported name

A mechanism name that has been converted from the GSS-API internal-name format to the GSS-API Exported Name format by gss_export_name(). An exported name can be compared with names that are in non-GSS-API string format with memcmp(). See also mechanism name (MN), name.

flavor

Historically, security flavor and authentication flavor were equivalent terms, as a flavor indicated a type of authentication, such as AUTH_UNIX, AUTH_DES, AUTH_KERB. RPCSEC_GSS is also a security flavor, even though it provides integrity and confidentiality services in addition to authentication.

GSS-API

The Generic Security Service Application Programming Interface. A network layer providing support for various modular security services. GSS-API provides for security authentication, integrity, and confidentiality services, and allows maximum portability of applications with regard to security. See also authentication, confidentiality, integrity.

host

A machine accessible over a network.

integrity

A security service that, in addition to user authentication, provides proof of the validity of transmitted data through cryptographic tagging. See also authentication, confidentiality, message integrity code (MIC).

keystore

A storage system for PKI objects. The following examples are popular keystores:

  • OpenSSL stores keys and certificates on disk in files (PEM, DER, or PKCS#12 format).

  • NSS is a private database that stores objects. NSS also supports PKCS#11 tokens.

  • PKCS#11 storage depends on the token selected: Local files use Oracle Solaris softtoken. Smart cards, for example, use hardware tokens.

KMF

Oracle Solaris Key Management Framework

mechanism

A software package that specifies cryptographic techniques to achieve data authentication or confidentiality. Examples include Kerberos v5 and Diffie-Hellman public key.

mechanism name (MN)

A special instance of a GSS-API internal-format name. A normal internal-format GSS-API name can contain several instances of a name, each in the format of an underlying mechanism. A mechanism name, however, is unique to a particular mechanism. Mechanism names are generated by gss_canonicalize_name().

message

Data in the form of a gss_buffer_t object that is sent from one GSS-API-based application to a peer. An example of a message is “ls” sent to a remote ftp server.

A message can contain more than just the user-provided data. For example, gss_wrap() takes an unwrapped message and produces a wrapped one to be sent. The wrapped message includes both the original message and an accompanying MIC. GSS-API-generated information that does not include a message is a token. See token.

message integrity code (MIC)

A cryptographic tag that is attached to transmitted data to ensure the data's validity. The recipient of the data generates another MIC and compares this MIC to the one that was sen. If the MICs are equal, the message is valid. Some MICs, such as those generated by gss_get_mic(), are visible to the application, while others, such as those generated by gss_wrap() or gss_init_sec_context(), are not.

message–level token

See token.

MIC

See message integrity code (MIC).

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 user@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 in which a name is given. Name types are stored as gss_OID types and are used to indicate the format used for a name. For example, the name user@machine would have a name type of GSS_C_NT_HOSTBASED_SERVICE. See also exported name, mechanism name (MN), name.

OCSP

Online Certificate Status Protocol

opaque

Applies to a piece of data whose 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 whether 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.

PKCS

Public Key Cryptography Standards

PKI

Public Key Infrastructure

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:

  • user

  • user@machine

  • nfs@machine

  • 123.45.678.9

  • ftp://ftp.company.com

See also name, name type.

privacy

See confidentiality.

provider

An application, library, or kernel module that provides services to consumers.

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, the QOP specifies the algorithm for both the MIC and message encryption.

replay detection

Many security mechanisms can detect whether 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 use rlogin to log in 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 use rlogin to log in 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.

SSL

Secure Sockets Layer

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 possibly other items 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.