1 - 3 - 4 - 7 - 8 - A - B - C - D - E - F - G - H - I - K - L - M - N - O - P - Q - R - S - T - U - V - W - X
Kerberos
Click on the red underlined text to get to the source
...
This document describes the concepts and model upon which the
Kerberos network authentication system is based. It also specifies
Version ...
... network authentication system is based. It also specifies
Version 5 of the Kerberos protocol. The motivations, goals,
assumptions, and rationale behind most design decisions are treated
cursorily; they are more fully described in a paper available in IEEE ...
... IEEE
communications [NT94] and earlier in the Kerberos portion of the
Athena Technical Plan [MNSS87].
...
... MNSS87].
This document is not intended to describe Kerberos to the end user,
system administrator, or application developer. Higher-level papers
...
... system administrator, or application developer. Higher-level papers
describing Version 5 of the Kerberos system [NT94] and documenting
version 4 ...
... SNS88] are available elsewhere.
The Kerberos model is based in part on Needham and Schroeder's
trusted third-party authentication protocol ...
... modifications suggested by Denning and Sacco [DS81]. The original
design and implementation of Kerberos Versions 1 through 4 was the
work of two former Project Athena staff members, Steve Miller of
...
... Campus Network Manager. Many other
members of Project Athena have also contributed to the work on
Kerberos.
Version ...
...
Version 5 of the Kerberos protocol (described in this document) has
evolved because of new requirements and desires for features not
...
... Reference implementations of both Version 4 and Version 5 of Kerberos
are publicly available, and commercial implementations have been
developed and are widely used. Details on the differences between
...
... The Kerberos Protocol ...
...
Kerberos provides a means of verifying the identities of principals,
(e.g., a workstation user or a network server ...
... network, and under the assumption that packets traveling along
the network can be read, modified, and inserted at will. Kerberos
performs authentication under these conditions as a trusted third-
...
... authentication service by using conventional (shared secret
key) cryptography. Extensions to Kerberos (outside the scope of this
document) can provide for the use of public key cryptography during
...
... certain phases of the authentication protocol. Such extensions
support Kerberos authentication for users registered with public key
...
... public key
cryptography in situations where they are needed.
The basic Kerberos authentication process proceeds as follows: A
client ...
... sub-session key to be used to encrypt further
communication. Note that many applications use Kerberos' functions
only upon the initiation of a stream-based network connection ...
... secret keys. Code libraries provide
encryption and implement the Kerberos protocol. In order to add
authentication to its transactions ...
... transactions, a typical network application
adds calls to the Kerberos library directly or through the Generic
Security Services Application Programming Interface ...
... authentication.
The Kerberos protocol consists of several sub-protocols (or
exchanges). There are two basic methods by which a client ...
... methods by which a client can ask a
Kerberos server for credentials. In the first approach, the client
...
... TGS in the same manner as if it were
contacting any other application server that requires Kerberos
authentication. The reply is encrypted ...
... TGS
as separate servers, in practice they are implemented as different
protocol entry points within a single Kerberos server.
Once obtained, credentials ...
... The authentication exchanges mentioned above require read-only access
to the Kerberos database. Sometimes, however, the entries in the
database ...
... principal's key. This is done using a protocol between a
client and a third Kerberos server, the Kerberos Administration
Server (KADM). There is also a protocol for maintaining multiple
...
... client and a third Kerberos server, the Kerberos Administration
Server (KADM). There is also a protocol for maintaining multiple
copies of the Kerberos ...
... Kerberos Administration
Server (KADM). There is also a protocol for maintaining multiple
copies of the Kerberos database. Neither of these protocols are
described in this document.
...
...
The Kerberos protocol is designed to operate across organizational
boundaries. A client in one organization can be authenticated ...
... client in one organization can be authenticated to a
server in another. Each organization wishing to run a Kerberos
server establishes its own "realm". The name of the realm in which a
client ...
...
The Kerberos protocol provides the means for verifying (subject to
the assumptions in Section 1.6) that the entity ...
... prefix specified in the application protocol specification, and a
mapping to a Kerberos realm derived syntactically from the domain
part of the specified hostname and information from the local
...
... domain
part of the specified hostname and information from the local
Kerberos realms database.
...
... the party.
Implementations of Kerberos and protocols based on Kerberos MUST NOT
use insecure DNS queries ...
...
Implementations of Kerberos and protocols based on Kerberos MUST NOT
use insecure DNS queries to canonicalize the hostname components of
...
...
As an authentication service, Kerberos provides a means of verifying
the identity of principals ...
... client is allowed to access, and the type of access allowed for each.
Kerberos does not, by itself, provide authorization. Possession of a
client ...
... Applications should not accept the mere issuance of a service ticket
by the Kerberos server (even by a modified Kerberos server) as
granting authority ...
... service ticket
by the Kerberos server (even by a modified Kerberos server) as
granting authority to use the service ...
... Extending Kerberos without Breaking Interoperability ...
...
As the deployed base of Kerberos implementations grows, extending
Kerberos becomes more important. Unfortunately, some extensions to
...
... As the deployed base of Kerberos implementations grows, extending
Kerberos becomes more important. Unfortunately, some extensions to
the existing Kerberos protocol create ...
... Kerberos becomes more important. Unfortunately, some extensions to
the existing Kerberos protocol create interoperability issues because
...
... interoperability.
Kerberos provides a general mechanism for protocol extensibility.
Some protocol messages ...
...
Note that existing Kerberos message formats cannot readily be
extended by adding fields to the ASN.1 types. Sending additional
...
... interoperability problem.
In the meantime, all new or modified implementations of Kerberos that
receive an unknown message extension SHOULD preserve the encoding ...
...
Kerberos imposes a few assumptions on the environment in which it can
properly function, including the following:
...
... * "Denial of service" attacks are not solved with Kerberos. There
are places in the protocols where an intruder can prevent an
application from participating in the proper authentication ...
... * "Password guessing" attacks are not solved by Kerberos. If a user
chooses a poor password, it is possible for an attacker ...
... token that grants the bearer permission to access an object or
service. In Kerberos, this might be a ticket whose use is
restricted by the contents of the authorization data field ...
...
Each Kerberos ticket contains a set of flags that are used to
indicate attributes of that ticket. Most flags may be requested by a
client ...
... client when the ticket is obtained; some are automatically turned on
and off by a Kerberos server as required. The following sections
explain what the various flags mean and give examples of reasons to
use them. With the exception of the INVALID flag, clients ...
... option was not honored because it was not understood or because it
was rejected through either configuration or policy. When adding a
new option to the Kerberos protocol, designers should consider
whether the distinction is important for their option. If it is, a
mechanism for the KDC ...
...
In order to complicate the use of stolen credentials, Kerberos
tickets are often valid only from those network ...
...
In Kerberos, the application server is ultimately responsible for
accepting or rejecting authentication ...
... login. Authentication of
such peers may be supported by Kerberos in its user-to-user variant.
The ENC-TKT-IN-SKEY ...
... AS) Exchange between the client and the
Kerberos Authentication Server is initiated by a client when it
...
... AS_REQ from the client
to Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for
these messages are described in Sections 5.4.1, 5.4.2, and 5.9.1.
...
... The format for the ticket is described in Section 5.3.
Because Kerberos can run over unreliable transports such as UDP, the
...
... encryption keys
registered for a client in the Kerberos database, then the etype
field from the AS ...
... appropriate type using the list of methods provided and information
from the Kerberos database indicating acceptable encryption methods
...
... encryption key extracted from the server
principal's record in the Kerberos database using the encryption type
...
... user-to-user authentication on all
messages in the Kerberos protocol.
Because it is possible for the server to be registered in multiple
...
... extracted from the ticket.
Note that in the Kerberos Version 4 protocol, the timestamp in the
...
... encryption or checksum type) to the application programmer. The
Kerberos protocol does not constrain the implementation options, but
an example of how this might be done follows.
...
... TGS_REQ message recursively). The
Kerberos server MAY return a TGT for the desired realm, in which case
one can proceed. Alternatively, the Kerberos ...
... Kerberos server MAY return a TGT for the desired realm, in which case
one can proceed. Alternatively, the Kerberos server MAY return a TGT
for a realm that is 'closer' to the desired realm (further along the
...
... client's realm and the
requested realm server's realm). Note that in this case
misconfiguration of the Kerberos servers may cause loops in the
resulting authentication path, which the client ...
... detect and avoid.
If the Kerberos server returns a TGT for a realm 'closer' than the
desired realm, the client ...
... client MAY choose its own authentication path,
rather than rely on the Kerberos server to select one. In either
case, any policy or configuration information used to choose or
...
... validate authentication paths, whether by the Kerberos server or by
the client, MUST be obtained from a trusted source.
...
... client obtains a TGT for the appropriate realm, it
determines which Kerberos servers serve that realm and contacts one
of them. The list might be obtained through a configuration file or
...
... secret keys exchanged by realms are kept secret, only
denial of service results from using a false Kerberos server.
As in the AS ...
... client can select a sub-
session key under which the response from the Kerberos server will be
encrypted. If the client ...
... KRB_AS_REQ message, but there are many additional checks to be
performed. First, the Kerberos server MUST determine which server
the accompanying ticket is for, and it MUST select the appropriate
key to decrypt it. For a normal KRB_TGS ...
... ticket granting server of an intermediate KDC to be contacted to
obtain the requested ticket. The Kerberos database is queried to
retrieve the record for the appropriate server (including the key
...
... TGT for a remote realm, and if no key is shared with the requested
realm, then the Kerberos server will select the realm 'closest' to
the requested realm with which it does share a key and use that realm
instead. This is the only case where the response for the KDC ...
... identity to a
server that does not have access to a persistent key. Section 3.7
describes the effect of this option on the entire Kerberos protocol.
When generating the KRB_TGS_REP message, this option in the
...
... own realm. Instead, its responsibility is to add the name of the
previous realm. This prevents a malicious Kerberos server from
intentionally leaving out its own name (it could, however, omit other
realms' names).
...
... The KRB_CRED message MAY be used by clients requiring the ability to
send Kerberos credentials from one host to another. It achieves this
...
... token, the MIT implementation
of Kerberos will not encrypt the KRB_CRED message if the session key
...
... version 1.2.5,
MIT Kerberos can receive and decode either encrypted or unencrypted
KRB_CRED tokens ...
... tokens in the GSSAPI exchange. The Heimdal implementation
of Kerberos can also accept either encrypted or unencrypted KRB_CRED
messages. Since the KRB_CRED message in a GSSAPI ...
... authenticator, the MIT behavior does not present a security
problem, although it is a violation of the Kerberos specification.
...
...
To address this problem, the Kerberos protocol allows the client to
request that the ticket issued by the KDC ...
... TGT must be obtained from the verifier by means
of an exchange external to the Kerberos protocol, usually as part of
the application protocol. This message is shown in the summary above
...
...
The Kerberos protocols described in this document are designed to
encrypt messages of arbitrary sizes, using stream ...
... encryption and checksum
mechanisms for use with Kerberos. It also defines several such
mechanisms, and more may be added in future updates to that document.
...
... key usage values for encrypting or checksumming Kerberos messages are
indicated in Section 5 along with the message definitions. The key
usage ...
... indicated in Section 5 along with the message definitions. The key
usage values 512-1023 are reserved for uses internal to a Kerberos
implementation. (For example, seeding a pseudo-random number
...
... encryption independent of
this framework, by directly using the key resulting from the Kerberos
authentication exchange.) New protocols ...
... authentication exchange.) New protocols defined in terms of the
Kerberos encryption and checksum types SHOULD use their own key usage
...
... currently existing protocol specifications. An implementation
intended to support general Kerberos applications may therefore need
to make key data available, as well as the attributes and operations
described in [RFC3961 ...
... encryption algorithm (in the
context of a given application). Although Kerberos does not directly
provide a facility for negotiating encryption types between the
...
... application client and server, there are approaches for using
Kerberos to facilitate this negotiation. For example, a client may
...
... shall take precedence.
The Kerberos protocol is defined here in terms of Abstract Syntax
Notation One (ASN.1) [X680 ...
... Encoding Rules (PER), are used. This theoretical
incompatibility should not be relevant for Kerberos, since Kerberos
explicitly specifies the use of the Distinguished Encoding Rules ...
... PER), are used. This theoretical
incompatibility should not be relevant for Kerberos, since Kerberos
explicitly specifies the use of the Distinguished Encoding Rules
...
... Distinguished Encoding Rules
(DER). It might be an issue for protocols seeking to use Kerberos
types with other encoding rules. (This practice is not recommended.)
...
... implementors should heed the following
specific notes regarding the use of ASN.1 in Kerberos. These notes
do not describe deviations from standard usage of ASN.1. The purpose
...
... encoding that
contains an empty SEQUENCE OF encoding. The Kerberos protocol does
not semantically distinguish between an absent optional SEQUENCE OF
type and a present optional but empty SEQUENCE OF type.
...
... marked OPTIONAL, but SHOULD accept them as being equivalent to an
omitted OPTIONAL type. In the ASN.1 syntax describing Kerberos
messages, instances of these problematic optional SEQUENCE OF types
are indicated with a comment.
...
... denial of service attacks. For non-KDC
applications, the Kerberos implementation typically indicates an
error to the application which takes appropriate steps based on the
application protocol ...
... Basic Kerberos Types ...
...
This section defines a number of basic types that are potentially
used in multiple Kerberos protocol messages.
...
...
The original specification of the Kerberos protocol in RFC 1510prop(-> 4120prop) uses
GeneralString in numerous places for human-readable ...
... GeneralString in numerous places for human-readable string data.
Historical implementations of Kerberos cannot utilize the full power
of GeneralString. This ASN.1 type requires the use of designation
...
... interoperability issues
when conflicting character encodings are utilized by the Kerberos
clients, services ...
... This unfortunate situation is the result of improper documentation of
the restrictions of the ASN.1 GeneralString type in prior Kerberos
specifications.
...
... }
Kerberos realm names are encoded as KerberosStrings. Realms shall
not contain a character with the code 0 (the US-ASCII NUL). Most
...
...
The timestamps used in Kerberos are encoded as GeneralizedTimes. A
KerberosTime value shall not include any fractional portions of the
...
... plaintext part of the ticket. The types of the
encapsulating elements are specified as part of the Kerberos
specification because the behavior based on these values should be
understood across implementations, whereas other elements ...
... KDC-issued ad-data field is intended to provide a means for
Kerberos principal credentials to embed within themselves privilege ...
...
This field MAY also contain information needed by certain
extensions to the Kerberos protocol. For example, it might be
used to verify the identity of a client ...
... decrypting the response. This form of the padata is useful for
supporting the use of certain token cards with Kerberos. The
details of such extensions are specified in separate documents.
See [Pat92 ...
... bits is not necessarily
a multiple of eight bits long. The use in Kerberos of a bit string
as a compact boolean vector ...
... forwardable".
Most existing implementations of Kerberos unconditionally send 32
bits on the wire when encoding bit strings ...
... principal
identifier. Since a Kerberos server can only issue tickets for
servers within its realm, the two will always be identical.
...
... encoding of the EncTicketPart
sequence. It is encrypted in the key shared by Kerberos and the
end server (the server's secret key), using a key usage ...
... KDC response and is used
to pass the session key from Kerberos to the application server
and the client ...
... transited
This field lists the names of the Kerberos realms that took part
in authenticating the user to whom this ticket was issued. It
does not specify the order in which the realms were transited.
...
... authentication
(KRB_AS_REP), this is the current time on the Kerberos server. It
is NOT recommended that this time value be used to adjust the
workstation's clock, as the workstation cannot reliably determine
...
... KDC to issue or by
the end server to accept addressless tickets is a policy decision
and is left to the Kerberos and end-service administrators; they
...
... rights to those objects. The format for this field is described
in Section 5.2.6. Although Kerberos is not concerned with the
format of the contents of the subfields, it does carry type
information (ad-type).
...
... This section specifies the format of the messages used in the
exchange between the client and the Kerberos server. The format of
possible error messages appears in Section 5.9.1.
...
...
This section specifies the format of a message that can be used to
send Kerberos credentials from one principal to another. It is
...
...
Implementation note: Implementations of certain applications, most
notably certain implementations of the Kerberos GSS-API mechanism,
do not separately encrypt ...
... error-code
This field contains the error code returned by Kerberos or the
server when a request fails. To interpret the value of this field
see the list of error codes ...
... only ASN.1 types intended as top-level types of the Kerberos
protocol, and are the only types that may be used as elements in
...
... protocol, and are the only types that may be used as elements in
another protocol that makes use of Kerberos.
...
... neighbors.
Kerberos realm names are case sensitive. Realm names that differ
only in the case of the characters are not equivalent. There are
presently three styles of realm names: domain ...
... string representations of the names with components separated by
slashes. Leading and trailing slashes will not be included. Note
that the slash separator is consistent with Kerberos implementations
based on RFC 1510prop(-> 4120prop), but it is different from the separator recommended
...
... SRV-INST SHOULD be
used. An example of this name type is the Kerberos ticket-granting
service whose name has a first component of krbtgt and a second
component identifying the realm for which the ticket is valid ...
... PRINCIPAL SHOULD be used when a name from an
X.509 certificate is translated into a Kerberos name. The encoding
of the X.509 ...
...
Names of any type with an initial component of 'krbtgt' are reserved
for the Kerberos ticket-granting service. See Section 7.3 for the
form of such names.
...
... loopback
address SHOULD NOT appear in a Kerberos PDU. The type of IPv4
addresses is two (2).
...
... IPv6 addresses is twenty-four (24). The following addresses MUST
NOT appear in any Kerberos PDU:
...
... This restriction applies to the inclusion in the address fields of
Kerberos PDUs, but not to the address fields of packets that might
...
... they will send their request.
Implementation note: Some extensions to the Kerberos protocol will
not succeed if any client or KDC ...
... client implementations MUST provide a means for the client
to determine the location of the Kerberos Key Distribution Centers
(KDCs). Traditionally, Kerberos implementations have stored such
...
... to determine the location of the Kerberos Key Distribution Centers
(KDCs). Traditionally, Kerberos implementations have stored such
configuration information in a file on each client ...
...
In Kerberos, realm names are case sensitive. Although it is strongly
encouraged that all realm names be all uppercase, this recommendation
has not been adopted by all sites. Some sites use all lowercase
...
... The Service name for Kerberos is always "kerberos".
The Proto can be either "udp" or "tcp". If these SRV records ...
... deployments.
The Realm is the Kerberos realm that this record corresponds to. The
realm MUST be a domain-style realm name.
...
... 2782prop, the Port number used for "_udp" and "_tcp" SRV
records SHOULD be the value assigned to "kerberos" by the Internet
Assigned Number Authority: 88 (decimal), unless the KDC is configured
...
...
These are DNS records for a Kerberos realm EXAMPLE.COM. It has two
Kerberos servers, kdc1.example.com and kdc2.example.com. Queries ...
... DNS records for a Kerberos realm EXAMPLE.COM. It has two
Kerberos servers, kdc1.example.com and kdc2.example.com. Queries
should be directed to kdc1.example.com first as per the specified
...
... priority. Weights are not used in these sample records.
_kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
...
... 15. KRB-SAFE cksum, keyed with a key chosen by the
application (Section 5.6.1)
16-18. Reserved for future use in Kerberos and related
protocols.
19. AD ...
... checksum (ad-checksum in 5.2.6.4)
20-21. Reserved for future use in Kerberos and related
protocols.
22-25. Reserved for use in the Kerberos ...
... mechanisms [RFC4121].
26-511. Reserved for future use in Kerberos and related
protocols.
512-1023. Reserved for uses internal to a Kerberos ...
... Kerberos and related
protocols.
512-1023. Reserved for uses internal to a Kerberos implementation.
1024. Encryption for application use in protocols that do not
...
... Kerberos Message Types ...
...
Version 5 of the Kerberos protocol supports a myriad of options.
Among these are multiple encryption and checksum types ...
... This section defines the second specification of these options.
Implementations which are configured in this way can be said to
support Kerberos Version 5 Specification 2 (5.2). Specification 1
(deprecated) may be found in RFC 1510prop(-> 4120prop) ...
... principals known to support them also.
Implementation note: Earlier implementations of Kerberos generate
messages using the CRC-32 and RSA ...
... interoperability of multiple
implementations. Until a subsequent RFC specifies otherwise, or the
Kerberos working group is shut down, allocations of additional
protocol constants ...
... protocol constants and other defined values required for extensions
to the Kerberos protocol will be administered by the Kerberos working
group. Following the recommendations outlined in [RFC2434 ...
... protocol constants and other defined values required for extensions
to the Kerberos protocol will be administered by the Kerberos working
group. Following the recommendations outlined in [RFC2434], guidance
...
... private use. Assignment of additional positive numbers is
subject to review by the Kerberos working group or other expert
review.
...
... key usage numbers, as defined in Section 7.5.1, will be
assigned subject to review by the Kerberos working group or other
expert review.
...
... data type values, as defined in section
7.5.2, will be assigned subject to review by the Kerberos working
group or other expert review.
...
... authorization data types as defined in Section 7.5.4, will
be assigned subject to review by the Kerberos working group or other
expert review. Although it is anticipated that there may be
...
... interoperability with existing
implementations. As such, such assignments will only be made by
standards action, except that the Kerberos working group or another
other working group ...
... process.
Additional Kerberos message types, as described in Section 7.5.7,
will be assigned subject to review by the Kerberos ...
... Kerberos message types, as described in Section 7.5.7,
will be assigned subject to review by the Kerberos working group or
other expert review.
...
... Additional name types, as described in Section 7.5.8, will be
assigned subject to review by the Kerberos working group or other
expert review.
...
... error codes described in Section 7.5.9 will be assigned
subject to review by the Kerberos working group or other expert
review.
...
...
As an authentication service, Kerberos provides a means of verifying
the identity of principals ...
... identity of principals on a network. By itself, Kerberos does
not provide authorization. Applications should not accept the
...
... authorization. Applications should not accept the
issuance of a service ticket by the Kerberos server as granting
authority to use the service ...
...
Denial of service attacks are not solved with Kerberos. There are
places in the protocols where an intruder can prevent an application
from participating in the proper authentication ...
... services,
successful denial of service attacks on a Kerberos server might
result in the denial of other network services that rely on Kerberos ...
... Kerberos server might
result in the denial of other network services that rely on Kerberos
for authentication. Kerberos ...
... Kerberos
for authentication. Kerberos is vulnerable to many kinds of denial
of service attacks: those on the network, which would prevent clients ...
... prevent a client from finding the IP address of the Kerberos server;
and those by overloading the Kerberos KDC ...
... IP address of the Kerberos server;
and those by overloading the Kerberos KDC itself with repeated
requests.
...
... denial of service for clients that utilize
character-sets in Kerberos strings other than those stored in the KDC
database ...
... Password-guessing attacks are not solved by Kerberos. If a user
chooses a poor password, it is possible for an attacker ...
... the user's password. For this reason it is strongly encouraged that
Kerberos realms require the use of pre-authentication. Even with
...
... security weakness.
Kerberos credentials contain clear-text information identifying the
principals ...
... and can no longer be successfully replayed.
Implementations of Kerberos should not use untrusted directory
servers to determine the realm of a host. To allow this would allow
...
... host was not registered).
Implementations of Kerberos must not use DNS to map one name to
another (canonicalize) in order to determine the host ...
... communicate.
If the Kerberos server returns a TGT for a realm 'closer' than the
desired realm, the client ...
... client may choose its own authentication path rather
than rely on the Kerberos server to select one. In either case, any
policy or configuration information used to choose or validate ...
... validate
authentication paths, whether by the Kerberos server or client, must
be obtained from a trusted source.
...
... be obtained from a trusted source.
The Kerberos protocol in its basic form does not provide perfect
forward secrecy for communications. If traffic has been recorded by
...
... application-specific encryption under
keys exchanged using Kerberos can be decrypted if the user's,
application server's, or KDC ...
... requiring perfect forward secrecy must exchange keys through
mechanisms that provide such assurance, but may use Kerberos for
authentication of the encrypted ...
... This document is a revision to RFC 1510prop(-> 4120prop) which was co-authored with
John Kohl. The specification of the Kerberos protocol described in
this document is the result of many years of effort. Over this
period, many individuals have contributed to the definition of the
...
...
Among those contributing to the development and specification of
Kerberos were Jeffrey Altman, John Brezak, Marc Colan, Johan
Danielsson, Don Davis, Doug Engert, Dan Geer, Paul Hill, John Kohl,
Marc Horowitz, Matt Hur, Jeffrey Hutzelman, Paul Leach, John Linn,
...
... Athena, the MIT networking group, and the Kerberos and CAT working
groups of the IETF contributed but are not listed.
...
... use of public key cryptography for
initial authentication in Kerberos by reference. RFC 1510prop(-> 4120prop) did not
include such a reference.
...
... include such a reference.
Section 1.3 was added to explain that while Kerberos provides
authentication of a named principal ...
... encryption and checksum
specification specific to Kerberos are now specified in Section 4.
Significant changes were made to the layout of Section 5 to clarify
...
... made necessary because of improper ASN.1 description in the original
Kerberos specification which left the correct behavior
underspecified. Additionally, the wording in this section was
tightened wherever possible to ensure that implementations conforming
...
...
(*TM) Project Athena, Athena, and Kerberos are trademarks of the
Massachusetts Institute of Technology (MIT ...
... Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961prop, February 2005. ...
... Don Davis, Daniel Geer, and Theodore Ts'o, "Kerberos With Clocks Adrift: History, Protocols, and Implementation", USENIX Computing Systems 9:1, January 1996. ...
... John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The Evolution of the Kerberos Authentication System". In Distributed Open Systems, pages 78-94. IEEE Computer Society Press, 1994. ...
... S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer, Section E.2.1: Kerberos Authentication and Authorization System, M.I.T. Project Athena, Cambridge, Massachusetts, December 21, 1987. ...
... Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510prop(-> 4120prop) ...
... J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Kerberos: An Authentication Service for Open Network Systems," p. 191-202, Usenix Conference Proceedings, Dallas, Texas, February 1988. ...
... Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API ...