<?Pub UDT _bookmark _target?><?Pub EntList bsol dash hellip gt lt minus?><?Pub CX solbook(book(title()bookinfo()part(7)?><glossary id="glossary-2"><?Pub Tag atict:info tracking="off" ref="0"?><?Pub Tag
atict:user user="sharonr" fullname="Sharon Veach"?><title>Glossary</title><glossentry id="glossary-53"><glossterm>Access Control List (ACL)</glossterm><glossdef><para>An
access control list (ACL) provides finer-grained file security than traditional
UNIX file protection provides. For example, an ACL enables you to allow group
read access to a file, while allowing only one member of that group to write
to the file.</para>
</glossdef>
</glossentry><glossentry id="glossary-70"><glossterm>admin principal</glossterm><glossdef><para>A user principal with a name of the form <emphasis>username</emphasis><literal>/admin</literal> (as in <literal>jdoe/admin</literal>). An admin principal
can have more privileges (for example, to change policies) than a regular
user principal. See also <olink targetptr="glossary-41" remap="internal">principal name</olink>, <olink targetptr="glossary-37" remap="internal">user principal</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-83"><glossterm>AES</glossterm><glossdef><para>Advanced Encryption Standard. A symmetric 128-bit block data
encryption technique. The U.S. government adopted the Rijndael variant of
the algorithm as its encryption standard in October 2000. AES replaces <olink targetptr="glossary-37" remap="internal">user principal</olink> encryption as the government
standard.</para>
</glossdef>
</glossentry><glossentry id="glossary-111"><glossterm>algorithm</glossterm><glossdef><para>A cryptographic algorithm. This is an established, recursive
computational procedure that encrypts or hashes input.</para>
</glossdef>
</glossentry><glossentry id="glossary-67"><glossterm>application server</glossterm><glossdef><para>See <olink targetptr="glossary-51" remap="internal">network application server</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-103"><glossterm>audit files</glossterm><glossdef><para>Binary audit logs. Audit files are stored separately in an
audit partition.</para>
</glossdef>
</glossentry><glossentry id="glossary-104"><glossterm>audit partition</glossterm><glossdef><para>A hard disk partition that is configured to hold audit files.</para>
</glossdef>
</glossentry><glossentry id="glossary-52"><glossterm>audit policy</glossterm><glossdef><para>The global and per-user settings that determine which audit
events are recorded. The global settings that apply to the audit service typically
affect which pieces of optional information are included in the audit trail.
Two settings, <literal>cnt</literal> and <literal>ahlt</literal>, affect the
operation of the system when the audit queue fills. For example, audit policy
might require that a sequence number be part of every audit record.</para>
</glossdef>
</glossentry><glossentry id="glossary-105"><glossterm>audit trail</glossterm><glossdef><para>The collection of all audit files from all hosts.</para>
</glossdef>
</glossentry><glossentry id="glossary-3"><glossterm>authentication</glossterm><glossdef><para>The process of verifying the claimed identity of a principal. </para>
</glossdef>
</glossentry><glossentry id="glossary-5"><glossterm>authenticator</glossterm><glossdef><para>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 time
stamp. 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.</para>
</glossdef>
</glossentry><glossentry id="glossary-6"><glossterm>authorization</glossterm><glossdef><para>1. In Kerberos, 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.</para><para>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.</para>
</glossdef>
</glossentry><glossentry id="glossary-120"><glossterm>basic set</glossterm><glossdef><para>The set of privileges that are assigned to a user's process
at login. On an unmodified system, each user's initial inheritable set equals
the basic set at login.</para>
</glossdef>
</glossentry><glossentry id="glossary-133"><glossterm>Blowfish</glossterm><glossdef><para>A symmetric block cipher algorithm that takes a variable-length
key from 32 bits to 448 bits. Its author, Bruce Schneier, claims that Blowfish
is optimized for applications where the key does not change often.</para>
</glossdef>
</glossentry><glossentry id="glossary-99"><glossterm>Basic Security Module (BSM)</glossterm><glossdef><para>The Solaris auditing service and device allocation. Together,
these features satisfy the C2 level of security.</para>
</glossdef>
</glossentry><glossentry id="glossary-7"><glossterm>client</glossterm><glossdef><para>Narrowly, a process that makes use of a network service on
behalf of a user; for example, an application that uses <command>rlogin</command>.
In some cases, a server can itself be a client of some other server or service.</para><para>More broadly, a host that a) receives a Kerberos credential, and b)
makes use of a service that is provided by a server.</para><para>Informally, a principal that makes use of a service.</para>
</glossdef>
</glossentry><glossentry id="glossary-57"><glossterm>client principal</glossterm><glossdef><para>(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 <structname>rpc_gss_principal_t</structname> structures.</para>
</glossdef>
</glossentry><glossentry id="glossary-56"><glossterm>clock skew</glossterm><glossdef><para>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 <filename>krb5.conf</filename> file.</para>
</glossdef>
</glossentry><glossentry id="glossary-8"><glossterm>confidentiality</glossterm><glossdef><para>See <olink targetptr="glossary-22" remap="internal">privacy</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-95"><glossterm>consumer</glossterm><glossdef><para>In the Solaris Cryptographic Framework, a consumer is a user
of the cryptographic services that come from providers. Consumers can be applications,
end users, or kernel operations. Kerberos, IKE, and IPsec are examples of
consumers. For examples of providers, see <olink targetptr="glossary-96" remap="internal">provider</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-9"><glossterm>credential</glossterm><glossdef><para>An information package that includes a ticket and a matching
session key. Used to authenticate the identity of a principal. See also <olink targetptr="glossary-34" remap="internal">ticket</olink>, <olink targetptr="glossary-33" remap="internal">session
key</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-55"><glossterm>credential cache</glossterm><glossdef><para>A storage space (usually a file) that contains credentials
that are received from the KDC.</para>
</glossdef>
</glossentry><glossentry id="glossary-110"><glossterm>cryptographic algorithm</glossterm><glossdef><para>See <olink targetptr="glossary-111" remap="internal">algorithm</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-137"><glossterm>DES</glossterm><glossdef><para>Data Encryption Standard. A symmetric-key encryption method
developed in 1975 and standardized by ANSI in 1981 as ANSI X.3.92. DES uses
a 56-bit key.</para>
</glossdef>
</glossentry><glossentry id="glossary-98"><glossterm>device allocation</glossterm><glossdef><para>Device protection at the user level. Device allocation enforces
the exclusive use of a device by one user at a time. Device data is purged
before device reuse. Authorizations can be used to limit who is permitted
to allocate a device.</para>
</glossdef>
</glossentry><glossentry id="glossary-97"><glossterm>device policy</glossterm><glossdef><para>Device protection at the kernel level. Device policy is implemented
as two sets of privileges on a device. One set of privileges controls read
access to the device. The second set of privileges controls write access to
the device. See also <olink targetptr="glossary-19" remap="internal">policy</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-154"><glossterm>Diffie-Hellman protocol</glossterm><glossdef><para>Also known as public key cryptography. An asymmetric cryptographic
key agreement protocol that was developed by Diffie and Hellman in 1976. The
protocol enables two users to exchange a secret key over an insecure medium
without any prior secrets. Diffie-Hellman is used by <olink targetptr="glossary-15" remap="internal">Kerberos</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-112"><glossterm>digest</glossterm><glossdef><para>See <olink targetptr="glossary-81" remap="internal">message digest</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-145"><glossterm>DSA</glossterm><glossdef><para>Digital Signature Algorithm. A public key algorithm with a
variable key size from 512 to 4096 bits. The U.S. Government standard, DSS,
goes up to 1024 bits. DSA relies on <olink targetptr="glossary-162" remap="internal">SHA1</olink> for
input.</para>
</glossdef>
</glossentry><glossentry id="glossary-121"><glossterm>effective set</glossterm><glossdef><para>The set of privileges that are currently in effect on a process.</para>
</glossdef>
</glossentry><glossentry id="glossary-10"><glossterm>flavor</glossterm><glossdef><para>Historically, <emphasis>security flavor</emphasis> and <emphasis>authentication flavor</emphasis> 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.</para>
</glossdef>
</glossentry><glossentry id="glossary-11"><glossterm>forwardable ticket</glossterm><glossdef><para>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 <literal>david</literal> obtains a
forwardable ticket while on user <literal>jennifer</literal>'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 <olink targetptr="glossary-24" remap="internal">proxiable
ticket</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-59"><glossterm>FQDN</glossterm><glossdef><para>Fully qualified domain name. For example, <literal>central.example.com</literal> (as opposed to simply <literal>denver</literal>).</para>
</glossdef>
</glossentry><glossentry id="glossary-12"><glossterm>GSS-API</glossterm><glossdef><para>The Generic Security Service Application Programming Interface.
A network layer that provides support for various modular security services,
including the Kerberos service. GSS-API provides for security authentication,
integrity, and privacy services. See also <olink targetptr="glossary-3" remap="internal">authentication</olink>, <olink targetptr="glossary-13" remap="internal">integrity</olink>, <olink targetptr="glossary-22" remap="internal">privacy</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-90"><glossterm>hardening</glossterm><glossdef><para>The modification of the default configuration of the operating
system to remove security vulnerabilities that are inherent in the host.</para>
</glossdef>
</glossentry><glossentry id="glossary-93"><glossterm>hardware provider</glossterm><glossdef><para>In the Solaris Cryptographic Framework, a device driver and
its hardware accelerator. Hardware providers offload expensive cryptographic
operations from the computer system, thus freeing CPU resources for other
uses. See also <olink targetptr="glossary-96" remap="internal">provider</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-42"><glossterm>host</glossterm><glossdef><para>A machine that is accessible over a network.</para>
</glossdef>
</glossentry><glossentry id="glossary-40"><glossterm>host principal</glossterm><glossdef><para>A particular instance of a service principal in which the
principal (signified by the primary name <literal>host</literal>) is set up
to provide a range of network services, such as <command>ftp</command>, <command>rcp</command>, or <command>rlogin</command>. An example of a host principal
is <literal>host/central.example.com@EXAMPLE.COM</literal>. See also <olink targetptr="glossary-58" remap="internal">server principal</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-124"><glossterm>inheritable set</glossterm><glossdef><para>The set of privileges that a process can inherit across a
call to <command>exec</command>.</para>
</glossdef>
</glossentry><glossentry id="glossary-65"><glossterm>initial ticket</glossterm><glossdef><para>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 <parameter>initial</parameter> 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).</para>
</glossdef>
</glossentry><glossentry id="glossary-39"><glossterm>instance</glossterm><glossdef><para>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. The instance the host's fully qualified domain name, as in <literal>host/central.example.com</literal>. For user principals, an instance is optional.
Note, however, that <literal>jdoe</literal> and <literal>jdoe/admin</literal> are
unique principals. See also <olink targetptr="glossary-44" remap="internal">primary</olink>, <olink targetptr="glossary-41" remap="internal">principal name</olink>, <olink targetptr="glossary-38" remap="internal">service
principal</olink>, <olink targetptr="glossary-37" remap="internal">user principal</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-13"><glossterm>integrity</glossterm><glossdef><para>A security service that, in addition to user authentication,
provides for the validity of transmitted data through cryptographic checksumming.
See also <olink targetptr="glossary-3" remap="internal">authentication</olink>, <olink targetptr="glossary-22" remap="internal">privacy</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-66"><glossterm>invalid ticket</glossterm><glossdef><para>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 <option role="nodash">VALIDATE</option> flag set,
after its start time has passed. See also <olink targetptr="glossary-20" remap="internal">postdated
ticket</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-14"><glossterm>KDC</glossterm><glossdef><itemizedlist><para>Key Distribution Center. A machine that has three Kerberos V5 components:</para><listitem><para>Principal and key database</para>
</listitem><listitem><para>Authentication service</para>
</listitem><listitem><para>Ticket-granting service</para>
</listitem>
</itemizedlist><para>Each realm has a master KDC and should have one or more slave KDCs. </para>
</glossdef>
</glossentry><glossentry id="glossary-15"><glossterm>Kerberos</glossterm><glossdef><para>An authentication service, the protocol that is used by that
service, or the code that is used to implement that service.  </para><para>The Solaris Kerberos implementation that is closely based
on Kerberos V5 implementation.</para><para>While technically different, &ldquo;Kerberos&rdquo;
and &ldquo;Kerberos V5&rdquo; are often used interchangeably in the Kerberos
documentation.</para><para>Kerberos (also spelled Cerberus) was a fierce,
three-headed mastiff who guarded the gates of Hades in Greek mythology.</para>
</glossdef>
</glossentry><glossentry id="glossary-85"><glossterm>Kerberos policy</glossterm><glossdef><para>A set of rules that governs password usage in the Kerberos
service. Policies can regulate principals' accesses, or ticket parameters,
such as lifetime.</para>
</glossdef>
</glossentry><glossentry id="glossary-43"><glossterm>key</glossterm><glossdef><itemizedlist><para>1. Generally, one of two main types of keys:</para><listitem><para>A <emphasis>symmetric key</emphasis> &ndash; An encryption
key that is identical to the decryption key. Symmetric keys are used to encrypt
files.</para>
</listitem><listitem><para>An <emphasis>asymmetric key</emphasis> or <emphasis>public
key</emphasis> &ndash; A key that is used in public key algorithms, such as
Diffie-Hellman or RSA. Public keys include a private key that is known only
by one user, a public key that is used by the server or general resource,
and a private-public key pair that combines the two. A private key is also
called a <emphasis>secret</emphasis> key. The public key is also called a <emphasis>shared</emphasis> key or <emphasis>common</emphasis> key.</para>
</listitem>
</itemizedlist><itemizedlist><listitem><para>2. An entry (principal name) in a keytab file. See also <olink targetptr="glossary-16" remap="internal">keytab file</olink>.</para><para>3. In Kerberos, an
encryption key, of which there are three types:</para>
</listitem><listitem><para>A <emphasis>private key</emphasis> &ndash; An encryption key
that is shared by a principal and the KDC, and distributed outside the bounds
of the system. See also <olink targetptr="glossary-23" remap="internal">private key</olink>.</para>
</listitem><listitem><para>A <emphasis>service key</emphasis> &ndash; This key serves
the same purpose as the private key, but is used by servers and services.
See also <olink targetptr="glossary-32" remap="internal">service key</olink>.</para>
</listitem><listitem><para>A <emphasis>session key</emphasis> &ndash; A temporary encryption
key that is used between two principals, with a lifetime limited to the duration
of a single login session. See also <olink targetptr="glossary-33" remap="internal">session
key</olink>.</para>
</listitem>
</itemizedlist>
</glossdef>
</glossentry><glossentry id="glossary-16"><glossterm>keytab file</glossterm><glossdef><para>A key table file that contains one or more keys (principals).
A host or service uses a keytab file in the much the same way that a user
uses a password. </para>
</glossdef>
</glossentry><glossentry id="glossary-36"><glossterm>kvno</glossterm><glossdef><para>Key version number. A sequence number that tracks a particular
key in order of generation. The highest kvno is the latest and most current
key.</para>
</glossdef>
</glossentry><glossentry id="glossary-122"><glossterm>limit set</glossterm><glossdef><para>The outside limit of what privileges are available to a process
and its children.</para>
</glossdef>
</glossentry><glossentry id="glossary-76"><glossterm>name service scope</glossterm><glossdef><para>The scope in which a role is permitted to operate, that is,
an individual host or all hosts that are served by a specified name service
such as NIS, NIS+, or LDAP. Scopes are applied to Solaris Management Console
toolboxes.</para>
</glossdef>
</glossentry><glossentry id="glossary-130"><glossterm>MAC</glossterm><glossdef><para>1. See <olink targetptr="glossary-80" remap="internal">message authentication
code (MAC)</olink>.</para><para>2. Also called labeling. In government security
terminology, MAC is Mandatory Access Control. Labels such as Top Secret and
Confidential are examples of MAC. MAC contrasts with DAC, which is Discretionary
Access Control. UNIX permissions are an example of DAC.</para><para>3. In
hardware, the unique machine address on a LAN. If the machine is on an Ethernet,
the MAC is the Ethernet address.</para>
</glossdef>
</glossentry><glossentry id="glossary-49"><glossterm>master KDC</glossterm><glossdef><para>The main KDC in each realm, which includes a Kerberos administration
server, <command>kadmind</command>, and an authentication and ticket-granting
daemon, <command>krb5kdc</command>. Each realm must have at least one master
KDC, and can have many duplicate, or slave, KDCs that provide authentication
services to clients.</para>
</glossdef>
</glossentry><glossentry id="glossary-84"><glossterm>MD5</glossterm><glossdef><para>An iterative cryptographic hash function that is used for
message authentication, including digital signatures. The function was developed
in 1991 by Rivest.</para>
</glossdef>
</glossentry><glossentry id="glossary-17"><glossterm>mechanism</glossterm><glossdef><para>1. A software package that specifies cryptographic techniques
to achieve data authentication or confidentiality. Examples: Kerberos V5,
Diffie-Hellman public key.</para><para>2. In the Solaris Cryptographic Framework,
an implementation of an algorithm for a particular purpose. For example, a
DES mechanism that is applied to authentication, such as CKM_DES_MAC, is a
separate mechanism from a DES mechanism that is applied to encryption, CKM_DES_CBC_PAD.</para>
</glossdef>
</glossentry><glossentry id="glossary-80"><glossterm>message authentication code (MAC)</glossterm><glossdef><para>MAC provides assurance of data integrity and authenticates
data origin. MAC does not protect against eavesdropping.</para>
</glossdef>
</glossentry><glossentry id="glossary-81"><glossterm>message digest</glossterm><glossdef><para>A message digest is a hash value that is computed from a message.
The hash value almost uniquely identifies the message. A digest is useful
for verifying the integrity of a file.</para>
</glossdef>
</glossentry><glossentry id="glossary-91"><glossterm>minimization</glossterm><glossdef><para>The installation of the minimal operating system that is necessary
to run the server.  Any software that does not directly relate to the operation
of the server is either not installed, or deleted after the installation.</para>
</glossdef>
</glossentry><glossentry id="glossary-51"><glossterm>network application server</glossterm><glossdef><para>A server that provides a network application, such as <command>ftp</command>. A realm can contain several network application servers.</para>
</glossdef>
</glossentry><glossentry sortas="" id="glossary-107"><glossterm>network policies</glossterm><glossdef><para>The settings that network utilities configure to protect network
traffic. For information on network security, see <olink targetdoc="group-sa" targetptr="ipsectm-1" remap="external">Part&nbsp;III, <citetitle remap="chapter">IP Security,</citetitle> in <citetitle remap="book">System Administration Guide: IP Services</citetitle></olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-102"><glossterm>nonattributable audit event</glossterm><glossdef><para>An audit event whose initiator cannot be determined, such
as the AUE_BOOT event.</para>
</glossdef>
</glossentry><glossentry id="glossary-71"><glossterm>NTP</glossterm><glossdef><para>Network Time Protocol. Software from the University of Delaware
that enables you to manage precise time or network clock synchronization,
or both, in a network environment. You can use NTP to maintain clock skew
in a Kerberos environment. See also clock skew.</para>
</glossdef>
</glossentry><glossentry id="glossary-18"><glossterm>PAM</glossterm><glossdef><para>Pluggable Authentication Module. A framework that allows for
multiple authentication mechanisms to be used without having to recompile
the services that use them. PAM enables Kerberos session initialization at
login.</para>
</glossdef>
</glossentry><glossentry id="glossary-101"><glossterm>passphrase</glossterm><glossdef><para>A phrase that is used to verify that a private key was created
by the passphrase user. A good passphrase is 10-30 characters long, mixes
alphabetic and numeric characters, and avoids simple prose and simple names.
You are prompted for the passphrase to authenticate use of the private key
to encrypt and decrypt communications.</para>
</glossdef>
</glossentry><glossentry id="glossary-87"><glossterm>password policy</glossterm><glossdef><para>The encryption algorithms that can be used to generate passwords.
Can also refer to more general issues around passwords, such as how often
the passwords must be changed, how many mis-entries are permitted, and other
security considerations. Security policy requires passwords. Password policy
might require passwords to be encrypted with the MD5 algorithm, and might
make further requirements related to password strength.</para>
</glossdef>
</glossentry><glossentry id="glossary-123"><glossterm>permitted set</glossterm><glossdef><para>The set of privileges that are available for use by a process.</para>
</glossdef>
</glossentry><glossentry id="glossary-19"><glossterm>policy</glossterm><glossdef><para>Generally, a plan or course of action that influences or determines
decisions and actions. For computer systems, policy typically means security
policy. Your site's security policy is the set of rules that define the sensitivity
of the information that is being processed and the measures that are used
to protect the information from unauthorized access. For example, security
policy might require that systems be audited, that devices be protected with
privileges, and that passwords be changed every six weeks.</para><para>For
the implementation of policy in specific areas of the Solaris OS, see <olink targetptr="glossary-52" remap="internal">audit policy</olink>, <olink targetptr="glossary-86" remap="internal">policy
in the cryptographic framework</olink>, <olink targetptr="glossary-97" remap="internal">device
policy</olink>, <olink targetptr="glossary-85" remap="internal">Kerberos policy</olink>, <olink targetptr="glossary-87" remap="internal">password policy</olink>, and <olink targetptr="glossary-68" remap="internal">RBAC policy</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-86"><glossterm>policy in the cryptographic framework</glossterm><glossdef><para>In the Solaris Cryptographic Framework, policy is the disabling
of existing cryptographic mechanisms. The mechanisms then cannot be used.
Policy in the cryptographic framework might prevent the use of a particular
mechanism, such as <literal>CKM_DES_CBC</literal>, from a provider, such as
DES.</para>
</glossdef>
</glossentry><glossentry id="glossary-140"><glossterm>policy for public key technologies</glossterm><glossdef><para>In the Key Management Framework (KMF), policy is the management
of certificate usage. The KMF policy database can put constraints on the use
of the keys and certificates that are managed by the KMF library.</para>
</glossdef>
</glossentry><glossentry id="glossary-20"><glossterm>postdated ticket</glossterm><glossdef><para>A postdated ticket does not become valid until some specified
time after its creation. Such a ticket is useful, for example, for batch jobs
that are intended to run late at night, since the ticket, if stolen, cannot
be used until the batch job is run. When a postdated ticket is issued, it
is issued as <parameter>invalid</parameter> and remains that way until a)
its start time has passed, and b) the client requests validation by the KDC.
A postdated ticket is normally valid until the expiration time of the ticket-granting
ticket. However, if the postdated ticket is marked <parameter>renewable</parameter>,
its lifetime is normally set to be equal to the duration of the full life
time of the ticket-granting ticket. See also <olink targetptr="glossary-66" remap="internal">invalid
ticket</olink>, <olink targetptr="glossary-28" remap="internal">renewable ticket</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-44"><glossterm>primary</glossterm><glossdef><para>The first part of a principal name. See also <olink targetptr="glossary-39" remap="internal">instance</olink>, <olink targetptr="glossary-41" remap="internal">principal
name</olink>, <olink targetptr="glossary-27" remap="internal">realm</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-21"><glossterm>principal</glossterm><glossdef><para>1. A uniquely named client/user or server/service instance
that participates in a network communication. Kerberos transactions involve
interactions between principals (service principals and user principals) or
between principals and KDCs. In other words, a principal is a unique entity
to which Kerberos can assign tickets. See also <olink targetptr="glossary-41" remap="internal">principal
name</olink>, <olink targetptr="glossary-38" remap="internal">service principal</olink>, <olink targetptr="glossary-37" remap="internal">user principal</olink>.</para><para>2. (RPCSEC_GSS
API) See <olink targetptr="glossary-57" remap="internal">client principal</olink>, <olink targetptr="glossary-58" remap="internal">server principal</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-41"><glossterm>principal name</glossterm><glossdef><para>1. The name of a principal, in the format <replaceable>primary/instance@REALM</replaceable>. See also <olink targetptr="glossary-39" remap="internal">instance</olink>, <olink targetptr="glossary-44" remap="internal">primary</olink>, <olink targetptr="glossary-27" remap="internal">realm</olink>.</para><para>2. (RPCSEC_GSS API) See <olink targetptr="glossary-57" remap="internal">client
principal</olink>, <olink targetptr="glossary-58" remap="internal">server principal</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-22"><glossterm>privacy</glossterm><glossdef><para>A security service, in which transmitted data is encrypted
before being sent. Privacy also includes data integrity and user authentication.
See also <olink targetptr="glossary-3" remap="internal">authentication</olink>, <olink targetptr="glossary-13" remap="internal">integrity</olink>, <olink targetptr="glossary-31" remap="internal">service</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-23"><glossterm>private key</glossterm><glossdef><para>A key that is given to each user principal, and known only
to the user of the principal and to the KDC.  For user principals, the key
is based on the user's password. See also <olink targetptr="glossary-43" remap="internal">key</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-46"><glossterm>private-key encryption</glossterm><glossdef><para>In private-key encryption, the sender and receiver use the
same key for encryption. See also <olink targetptr="glossary-47" remap="internal">public-key
encryption</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-82"><glossterm>privilege</glossterm><glossdef><para>A discrete right on a process in a Solaris system. Privileges
offer a finer-grained control of processes than does <literal>root</literal>.
Privileges are defined and enforced in the kernel. For a full description
of privileges, see the <olink targetdoc="group-refman" targetptr="privileges-5" remap="external"><citerefentry><refentrytitle>privileges</refentrytitle><manvolnum>5</manvolnum></citerefentry></olink> man
page.</para>
</glossdef>
</glossentry><glossentry id="glossary-116"><glossterm>privilege model</glossterm><glossdef><para>A stricter model of security on a computer system than the
superuser model. In the privilege model, processes require privilege to run.
Administration of the system can be divided into discrete parts that are based
on the privileges that administrators have in their processes. Privileges
can be assigned to an administrator's login process. Or, privileges can be
assigned to be in effect for certain commands only.</para>
</glossdef>
</glossentry><glossentry id="glossary-117"><glossterm>privilege set</glossterm><glossdef><para>A collection of privileges. Every process has four sets of
privileges that determine whether a process can use a particular privilege.
See <olink targetptr="glossary-122" remap="internal">limit set</olink>, <olink targetptr="glossary-121" remap="internal">effective set</olink> set, <olink targetptr="glossary-123" remap="internal">permitted set</olink> set, and <olink targetptr="glossary-124" remap="internal">inheritable set</olink> set.</para><para>Also, the <olink targetptr="glossary-120" remap="internal">basic set</olink> set of privileges is the collection
of privileges that are assigned to a user's process at login.</para>
</glossdef>
</glossentry><glossentry id="glossary-73"><glossterm>privileged application</glossterm><glossdef><para>An application that can override system controls. The application
checks for security attributes, such as specific UIDs, GIDs, authorizations,
or privileges.</para>
</glossdef>
</glossentry><glossentry id="glossary-75"><glossterm>profile shell</glossterm><glossdef><para>In RBAC, a shell that enables a role (or user) to run from
the command line any privileged applications that are assigned to the role's
rights profiles. The profile shells are <command>pfsh</command>, <command>pfcsh</command>,
and <command>pfksh</command>. They  correspond to the Bourne shell (<command>sh</command>),
C shell (<command>csh</command>), and Korn shell (<command>ksh</command>),
respectively. </para>
</glossdef>
</glossentry><glossentry id="glossary-96"><glossterm>provider</glossterm><glossdef><para>In the Solaris Cryptographic Framework, a cryptographic service
that is provided to consumers. PKCS #11 libraries, kernel cryptographic modules,
and hardware accelerators are examples of providers. Providers plug in to
the Solaris Cryptographic Framework, so are also called <emphasis>plugins</emphasis>.
For examples of consumers, see <olink targetptr="glossary-95" remap="internal">consumer</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-24"><glossterm>proxiable ticket</glossterm><glossdef><para>A ticket that can be used by a service on behalf of a client
to perform an operation for the client. Thus, the service is said to act as
the client's proxy. With the ticket, the service can take on the identity
of the client. The service can use a proxiable ticket to obtain a service
ticket to another service, but it cannot obtain a ticket-granting ticket.
The difference between a proxiable ticket and a forwardable ticket is that
a proxiable ticket is only valid for a single operation. See also <olink targetptr="glossary-11" remap="internal">forwardable ticket</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-47"><glossterm>public-key encryption</glossterm><glossdef><para>An encryption scheme in which each user has two keys, one
public key and one private key. In public-key encryption, the sender uses
the receiver's public key to encrypt the message, and the receiver uses a
private key to decrypt it. The Kerberos service is a private-key system. See
also <olink targetptr="glossary-46" remap="internal">private-key encryption</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-25"><glossterm>QOP</glossterm><glossdef><para>Quality of Protection. A parameter that is used to select
the cryptographic algorithms that are used in conjunction with the integrity
service or privacy service.</para>
</glossdef>
</glossentry><glossentry id="glossary-79"><glossterm>RBAC</glossterm><glossdef><para>Role-Based Access Control. An alternative to the all-or-nothing
superuser model. RBAC lets an organization separate superuser's capabilities
and assign them to special user accounts called roles. Roles can be assigned
to specific individuals according to their responsibilities.</para>
</glossdef>
</glossentry><glossentry id="glossary-68"><glossterm>RBAC policy</glossterm><glossdef><para>The security policy that is associated with a command. Currently, <literal>suser</literal> and <literal>solaris</literal> are the valid policies. The <literal>solaris</literal> policy recognizes privileges and <command>setuid</command> security
attributes. The <literal>suser</literal> policy recognizes only <command>setuid</command> security
attributes. <trademark>Trusted Solaris</trademark> systems, which can interoperate
with a Solaris system, provide a <literal>tsol</literal> policy, which recognizes
privileges, <command>setuid</command> security attributes, and labels on processes.</para>
</glossdef>
</glossentry><glossentry id="glossary-27"><glossterm>realm</glossterm><glossdef><para>1. The logical network that is served by a single Kerberos
database and a set of Key Distribution Centers (KDCs). </para><para>2. The
third part of a principal name. For the principal name <literal>jdoe/admin@ENG.EXAMPLE.COM</literal>, the realm is <literal>ENG.EXAMPLE.COM</literal>. See also <olink targetptr="glossary-41" remap="internal">principal name</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-1"><glossterm>relation</glossterm><glossdef><para>A configuration variable or relationship that is defined in
the <filename>kdc.conf</filename> or <filename>krb5.conf</filename> files.</para>
</glossdef>
</glossentry><glossentry id="glossary-28"><glossterm>renewable ticket</glossterm><glossdef><para>Because having tickets with very long lives is a security
risk, tickets can be designated as <parameter>renewable</parameter>. A renewable
ticket has two expiration times: a) the time at which the current instance
of the ticket expires, and b) maximum lifetime for any ticket. If a client
wants to continue to use a ticket, the client renews the ticket before the
first expiration occurs. For example, a ticket can be valid for one hour,
with all tickets having a maximum lifetime of ten hours. If the client that
holds the ticket wants to keep it for more than an hour, the client must renew
the ticket. When a ticket reaches the maximum ticket lifetime, it automatically
expires and cannot be renewed.</para>
</glossdef>
</glossentry><glossentry id="glossary-74"><glossterm>rights profile</glossterm><glossdef><para>Also referred to as a right or a profile. A collection of
overrides used in RBAC that can be assigned to a role or user. A rights profile
can consist of authorizations, commands with security attributes, and other
rights profiles.</para>
</glossdef>
</glossentry><glossentry id="glossary-72"><glossterm>role</glossterm><glossdef><para>A special identity for running privileged applications that
only assigned users can assume.</para>
</glossdef>
</glossentry><glossentry id="glossary-159"><glossterm>RSA</glossterm><glossdef><para>A method for obtaining digital signatures and public key cryptosystems.
The method was first described in 1978 by its developers, Rivest, Shamir,
and Adleman.</para>
</glossdef>
</glossentry><glossentry id="glossaryscanengine"><glossterm>scan engine</glossterm><glossdef><para>A third-party application, residing on an external host, that
examines a file for known viruses.</para>
</glossdef>
</glossentry><glossentry id="glossary-45"><glossterm>SEAM</glossterm><glossdef><para>Sun Enterprise Authentication Mechanism. The product name
for the initial versions of a system for authenticating users over a network,
based on the Kerberos V5 technology that was developed at the Massachusetts
Institute of Technology. The product is now called the Kerberos service. SEAM
refers to parts the Kerberos service that were not included in various Solaris
releases.</para>
</glossdef>
</glossentry><glossentry id="glossary-29"><glossterm>secret key</glossterm><glossdef><para>See <olink targetptr="glossary-23" remap="internal">private key</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-77"><glossterm>Secure Shell</glossterm><glossdef><para>A special protocol for secure remote login and other secure
network services over an insecure network.</para>
</glossdef>
</glossentry><glossentry id="glossary-114"><glossterm>security attributes</glossterm><glossdef><para>In RBAC, overrides to security policy that enable an administrative
command to succeed when the command is run by a user other than superuser.
In the superuser model, the <command>setuid</command> and <command>setgid</command> programs
are security attributes. When these attributes are applied to a command, the
command succeeds no matter who runs the command. In the privilege model, security
attributes are privileges. When a privilege is given to a command, the command
succeeds. The privilege model is compatible with the superuser model, in that
the privilege model also recognizes the <command>setuid</command> and <command>setgid</command> programs as security attributes.</para>
</glossdef>
</glossentry><glossentry id="glossary-63"><glossterm>security flavor</glossterm><glossdef><para>See <olink targetptr="glossary-10" remap="internal">flavor</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-69"><glossterm>security mechanism</glossterm><glossdef><para>See <olink targetptr="glossary-17" remap="internal">mechanism</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-106"><glossterm>security policy</glossterm><glossdef><para>See <olink targetptr="glossary-19" remap="internal">policy</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-61"><glossterm>security service</glossterm><glossdef><para>See <olink targetptr="glossary-31" remap="internal">service</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-92"><glossterm>seed</glossterm><glossdef><para>A numeric starter for generating random numbers. When the
starter originates from a random source, the seed is called a <emphasis>random
seed</emphasis>.</para>
</glossdef>
</glossentry><glossentry id="glossary-30"><glossterm>server</glossterm><glossdef><para>A principal that provides a resource to network clients. For
example, if you <command>rlogin</command> to the machine <literal>central.example.com</literal>, then that machine is the server that provides the <command>rlogin</command> service.
See also <olink targetptr="glossary-38" remap="internal">service principal</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-58"><glossterm>server principal</glossterm><glossdef><para>(RPCSEC_GSS API) A principal that provides a service. The
server principal is stored as an ASCII string in the form <emphasis>service</emphasis><literal>@</literal><emphasis>host</emphasis>. See also <olink targetptr="glossary-57" remap="internal">client
principal</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-31"><glossterm>service</glossterm><glossdef><para>1. A resource that is provided to network clients, often by
more than one server. For example, if you <command>rlogin</command> to the
machine <literal>central.example.com</literal>, then that machine is the server
that provides the <command>rlogin</command> service.</para><para>2. A security service (either integrity or privacy) that
provides a level of protection beyond authentication. See also <olink targetptr="glossary-13" remap="internal">integrity</olink> and <olink targetptr="glossary-22" remap="internal">privacy</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-32"><glossterm>service key</glossterm><glossdef><para>An encryption key that is shared by a service principal and
the KDC, and is distributed outside the bounds of the system. See also <olink targetptr="glossary-43" remap="internal">key</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-38"><glossterm>service principal</glossterm><glossdef><para>A principal that provides Kerberos authentication for a service
or services. For service principals, the primary name is a name of a service,
such as <command>ftp</command>, and its instance is the fully qualified host
name of the system that provides the service. See also <olink targetptr="glossary-40" remap="internal">host principal</olink>, <olink targetptr="glossary-37" remap="internal">user
principal</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-162"><glossterm>SHA1</glossterm><glossdef><para>Secure Hashing Algorithm. The algorithm operates on any input
length less than 2<superscript>64</superscript> to produce a message digest.
The SHA1 algorithm is input to <olink targetptr="glossary-145" remap="internal">DSA</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-126"><glossterm>single-system image</glossterm><glossdef><para>A single-system image is used in Solaris auditing to describe
a group of audited machines that use the same naming service. These machines
send their audit records to a central audit server, where the records can
be compared as if the records came from one machine.</para>
</glossdef>
</glossentry><glossentry id="glossary-94"><glossterm>software provider</glossterm><glossdef><para>In the Solaris Cryptographic Framework, a kernel software
module or a PKCS #11 library that provides cryptographic services. See also <olink targetptr="glossary-96" remap="internal">provider</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-33"><glossterm>session key</glossterm><glossdef><para>A key that is generated by the authentication service or the
ticket-granting service. A session key is generated to provide secure transactions
between a client and a service. The lifetime of a session key is limited to
a single login session. See also <olink targetptr="glossary-43" remap="internal">key</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-50"><glossterm>slave KDC</glossterm><glossdef><para>A copy of a master KDC, which is capable of performing most
functions of the master. Each realm usually has several slave KDCs (and only
one master KDC). See also <olink targetptr="glossary-14" remap="internal">KDC</olink>, <olink targetptr="glossary-49" remap="internal">master KDC</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-62"><glossterm>stash file</glossterm><glossdef><para>A stash file contains an encrypted copy of the master key
for the KDC. This master key is used when a server is rebooted to automatically
authenticate the KDC before it starts the <command>kadmind</command> and <command>krb5kdc</command> processes. Because the stash file includes the master key,
the stash file and any backups of it should be kept secure. If the encryption
is compromised, then the key could be used to access or modify the KDC database.</para>
</glossdef>
</glossentry><glossentry id="glossary-115"><glossterm>superuser model</glossterm><glossdef><para>The typical UNIX model of security on a computer system. In
the superuser model, an administrator has all-or-nothing control of the machine.
Typically, to administer the machine, a user becomes superuser (<literal>root</literal>)
and can do all administrative activities.</para>
</glossdef>
</glossentry><glossentry id="glossary-34"><glossterm>ticket</glossterm><glossdef><para>An information packet that is used to securely pass the identity
of a user to a server or service. A ticket is valid for only a single client
and a particular service on a specific server. A ticket contains the principal
name of the service, the principal name of the user, the IP address of the
user's host, a time stamp, and a value that defines the lifetime of the ticket.
A ticket is created with a random session key to be used by the client and
the service. Once a ticket has been created, it can be reused until the ticket
expires. A ticket only serves to authenticate a client when it is presented
along with a fresh authenticator. See also <olink targetptr="glossary-5" remap="internal">authenticator</olink>, <olink targetptr="glossary-9" remap="internal">credential</olink>, <olink targetptr="glossary-31" remap="internal">service</olink>, <olink targetptr="glossary-33" remap="internal">session
key</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-64"><glossterm>ticket file</glossterm><glossdef><para>See <olink targetptr="glossary-55" remap="internal">credential cache</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-48"><glossterm>TGS</glossterm><glossdef><para>Ticket-Granting Service. That portion of the KDC that is responsible
for issuing tickets. </para>
</glossdef>
</glossentry><glossentry id="glossary-35"><glossterm>TGT</glossterm><glossdef><para>Ticket-Granting Ticket. A ticket that is issued by the KDC
that enables a client to request tickets for other services.</para>
</glossdef>
</glossentry><glossentry id="glossary-37"><glossterm>user principal</glossterm><glossdef><para>A principal that is attributed to a particular user. A user
principal's primary name is a user name, and its optional instance is a name
that is used to described the intended use of the corresponding credentials
(for example, <literal>jdoe</literal> or <literal>jdoe/admin</literal>). Also
known as a user instance. See also <olink targetptr="glossary-38" remap="internal">service
principal</olink>.</para>
</glossdef>
</glossentry><glossentry id="glossary-78"><glossterm>virtual private network (VPN)</glossterm><glossdef><para>A network that provides secure communication by using encryption
and tunneling to connect users over a public network.</para>
</glossdef>
</glossentry>
</glossary><?Pub *0000049797 0?>