Glossary
- admin principal
A user principal with a name of the form username/admin (as in joe/admin). An admin principal can have more privileges (for example, to change policies) than a regular user principal. See also principal name, user principal.
- application server
- authentication
The process of verifying the claimed identity of a principal.
- authenticator
Authenticators are passed by clients when requesting tickets (from a KDC) and services (from a server). They contain information that is generated by using a session key known only by the client and server, that can be verified as of recent origin, thus indicating that the transaction is secure. When used with a ticket, an authenticator can be used to authenticate a user principal. An authenticator includes the principal name of the user, the IP address of the user's host, and a timestamp. Unlike a ticket, an authenticator can be used only once, usually when access to a service is requested. An authenticator is encrypted by using the session key for that client and that server.
- authorization
1. The process of determining if a principal can use a service, which objects the principal is allowed to access, and the type of access that is allowed for each object.
2. In role-based access control (RBAC), a permission that can be assigned to a role or user (or embedded in a rights profile) for performing a class of actions that are otherwise prohibited by security policy.
- 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.
More broadly, a host that a) receives a Kerberos credential, and b) makes use of a service that is provided by a server.
Informally, a principal that makes use of a service.
- client principal
(RPCSEC_GSS API) A client (a user or an application) that uses RPCSEC_GSS-secured network services. Client principal names are stored in the form of rpc_gss_principal_t structures.
- clock skew
The maximum amount of time that the internal system clocks on all hosts that are participating in the Kerberos authentication system can differ. If the clock skew is exceeded between any of the participating hosts, requests are rejected. Clock skew can be specified in the krb5.conf file.
- confidentiality
See privacy.
- credential
An information package that includes a ticket and a matching session key. Used to authenticate the identity of a principal. See also ticket, session key.
- credential cache
A storage space (usually a file) that contains credentials that are received from the KDC.
- flavor
Historically, security flavor and authentication flavor had the same meaning, as a flavor that indicated a type of authentication (AUTH_UNIX, AUTH_DES, AUTH_KERB). RPCSEC_GSS is also a security flavor, even though it provides integrity and privacy services in addition to authentication.
- forwardable ticket
A ticket that a client can use to request a ticket on a remote host without requiring the client to go through the full authentication process on that host. For example, if the user david obtains a forwardable ticket while on user jennifer's machine, he can log in to his own machine without being required to get a new ticket (and thus authenticate himself again). See also proxiable ticket.
- FQDN
Fully qualified domain name. For example, denver.mtn.example.com (as opposed to simply denver).
- GSS-API
The Generic Security Service Application Programming Interface. A network layer that provides support for various modular security services (including SEAM). GSS-API provides for security authentication, integrity, and privacy services. See also authentication, integrity, privacy.
- host
A machine that is accessible over a network.
- host principal
A particular instance of a service principal in which the principal (signified by the primary name host) is set up to provide a range of network services, such as ftp, rcp, or rlogin. An example of a host principal is host/boston.eng.example.com@ENG.EXAMPLE.COM. See also server principal.
- initial ticket
A ticket that is issued directly (that is, not based on an existing ticket-granting ticket). Some services, such as applications that change passwords, might require tickets to be marked initial so as to assure themselves that the client can demonstrate a knowledge of its secret key. This assurance is important because an initial ticket indicates that the client has recently authenticated itself (instead of relying on a ticket-granting ticket, which might existed for a long time).
- instance
The second part of a principal name, an instance qualifies the principal's primary. In the case of a service principal, the instance is required and is the host's fully qualified domain name, as in host/boston.eng.example.com. For user principals, an instance is optional. Note, however, that joe and joe/admin are unique principals. See also primary, principal name, service principal, user principal.
- integrity
A security service that, in addition to user authentication, provides for the validity of transmitted data through cryptographic checksumming. See also authentication, privacy.
- invalid ticket
A postdated ticket that has not yet become usable. An invalid ticket is rejected by an application server until it becomes validated. To be validated, an invalid ticket must be presented to the KDC by the client in a TGS request, with the VALIDATE flag set, after its start time has passed. See also postdated ticket.
- KDC
Key Distribution Center. A machine that has three Kerberos V5 components:
Principal and key database
Authentication service
Ticket-granting service
Each realm has a master KDC and should have one or more slave KDCs.