Love Hörnquist Åstrand
eada81c4d8
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@15654 ec53bebd-3082-4978-b11e-865c3cabbd6b
1124 lines
43 KiB
Plaintext
1124 lines
43 KiB
Plaintext
|
|
|
|
|
|
|
|
|
|
|
|
Network Working Group L. Zhu
|
|
Request for Comments: 4121 K. Jaganathan
|
|
Updates: 1964 Microsoft
|
|
Category: Standards Track S. Hartman
|
|
MIT
|
|
July 2005
|
|
|
|
|
|
The Kerberos Version 5
|
|
Generic Security Service Application Program Interface (GSS-API)
|
|
Mechanism: Version 2
|
|
|
|
Status of This Memo
|
|
|
|
This document specifies an Internet standards track protocol for the
|
|
Internet community, and requests discussion and suggestions for
|
|
improvements. Please refer to the current edition of the "Internet
|
|
Official Protocol Standards" (STD 1) for the standardization state
|
|
and status of this protocol. Distribution of this memo is unlimited.
|
|
|
|
Copyright Notice
|
|
|
|
Copyright (C) The Internet Society (2005).
|
|
|
|
Abstract
|
|
|
|
This document defines protocols, procedures, and conventions to be
|
|
employed by peers implementing the Generic Security Service
|
|
Application Program Interface (GSS-API) when using the Kerberos
|
|
Version 5 mechanism.
|
|
|
|
RFC 1964 is updated and incremental changes are proposed in response
|
|
to recent developments such as the introduction of Kerberos
|
|
cryptosystem framework. These changes support the inclusion of new
|
|
cryptosystems, by defining new per-message tokens along with their
|
|
encryption and checksum algorithms based on the cryptosystem
|
|
profiles.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Standards Track [Page 1]
|
|
|
|
RFC 4121 Kerberos Version 5 GSS-API July 2005
|
|
|
|
|
|
Table of Contents
|
|
|
|
1. Introduction ....................................................2
|
|
2. Key Derivation for Per-Message Tokens ...........................4
|
|
3. Quality of Protection ...........................................4
|
|
4. Definitions and Token Formats ...................................5
|
|
4.1. Context Establishment Tokens ...............................5
|
|
4.1.1. Authenticator Checksum ..............................6
|
|
4.2. Per-Message Tokens .........................................9
|
|
4.2.1. Sequence Number .....................................9
|
|
4.2.2. Flags Field .........................................9
|
|
4.2.3. EC Field ...........................................10
|
|
4.2.4. Encryption and Checksum Operations .................10
|
|
4.2.5. RRC Field ..........................................11
|
|
4.2.6. Message Layouts ....................................12
|
|
4.3. Context Deletion Tokens ...................................13
|
|
4.4. Token Identifier Assignment Considerations ................13
|
|
5. Parameter Definitions ..........................................14
|
|
5.1. Minor Status Codes ........................................14
|
|
5.1.1. Non-Kerberos-specific Codes ........................14
|
|
5.1.2. Kerberos-specific Codes ............................15
|
|
5.2. Buffer Sizes ..............................................15
|
|
6. Backwards Compatibility Considerations .........................15
|
|
7. Security Considerations ........................................16
|
|
8. Acknowledgements................................................17
|
|
9. References .....................................................18
|
|
9.1. Normative References ......................................18
|
|
9.2. Informative References ....................................18
|
|
|
|
1. Introduction
|
|
|
|
[RFC3961] defines a generic framework for describing encryption and
|
|
checksum types to be used with the Kerberos protocol and associated
|
|
protocols.
|
|
|
|
[RFC1964] describes the GSS-API mechanism for Kerberos Version 5. It
|
|
defines the format of context establishment, per-message and context
|
|
deletion tokens, and uses algorithm identifiers for each cryptosystem
|
|
in per-message and context deletion tokens.
|
|
|
|
The approach taken in this document obviates the need for algorithm
|
|
identifiers. This is accomplished by using the same encryption
|
|
algorithm, specified by the crypto profile [RFC3961] for the session
|
|
key or subkey that is created during context negotiation, and its
|
|
required checksum algorithm. Message layouts of the per-message
|
|
tokens are therefore revised to remove algorithm indicators and to
|
|
add extra information to support the generic crypto framework
|
|
[RFC3961].
|
|
|
|
|
|
|
|
Zhu, et al. Standards Track [Page 2]
|
|
|
|
RFC 4121 Kerberos Version 5 GSS-API July 2005
|
|
|
|
|
|
Tokens transferred between GSS-API peers for security context
|
|
establishment are also described in this document. The data elements
|
|
exchanged between a GSS-API endpoint implementation and the Kerberos
|
|
Key Distribution Center (KDC) [RFC4120] are not specific to GSS-API
|
|
usage and are therefore defined within [RFC4120] rather than this
|
|
specification.
|
|
|
|
The new token formats specified in this document MUST be used with
|
|
all "newer" encryption types [RFC4120] and MAY be used with
|
|
encryption types that are not "newer", provided that the initiator
|
|
and acceptor know from the context establishment that they can both
|
|
process these new token formats.
|
|
|
|
"Newer" encryption types are those which have been specified along
|
|
with or since the new Kerberos cryptosystem specification [RFC3961],
|
|
as defined in section 3.1.3 of [RFC4120]. The list of not-newer
|
|
encryption types is as follows [RFC3961]:
|
|
|
|
Encryption Type Assigned Number
|
|
----------------------------------------------
|
|
des-cbc-crc 1
|
|
des-cbc-md4 2
|
|
des-cbc-md5 3
|
|
des3-cbc-md5 5
|
|
des3-cbc-sha1 7
|
|
dsaWithSHA1-CmsOID 9
|
|
md5WithRSAEncryption-CmsOID 10
|
|
sha1WithRSAEncryption-CmsOID 11
|
|
rc2CBC-EnvOID 12
|
|
rsaEncryption-EnvOID 13
|
|
rsaES-OAEP-ENV-OID 14
|
|
des-ede3-cbc-Env-OID 15
|
|
des3-cbc-sha1-kd 16
|
|
rc4-hmac 23
|
|
|
|
Conventions used in this document
|
|
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|
document are to be interpreted as described in [RFC2119].
|
|
|
|
The term "little-endian order" is used for brevity to refer to the
|
|
least-significant-octet-first encoding, while the term "big-endian
|
|
order" is for the most-significant-octet-first encoding.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Standards Track [Page 3]
|
|
|
|
RFC 4121 Kerberos Version 5 GSS-API July 2005
|
|
|
|
|
|
2. Key Derivation for Per-Message Tokens
|
|
|
|
To limit the exposure of a given key, [RFC3961] adopted "one-way"
|
|
"entropy-preserving" derived keys, from a base key or protocol key,
|
|
for different purposes or key usages.
|
|
|
|
This document defines four key usage values below that are used to
|
|
derive a specific key for signing and sealing messages from the
|
|
session key or subkey [RFC4120] created during the context
|
|
establishment.
|
|
|
|
Name Value
|
|
-------------------------------------
|
|
KG-USAGE-ACCEPTOR-SEAL 22
|
|
KG-USAGE-ACCEPTOR-SIGN 23
|
|
KG-USAGE-INITIATOR-SEAL 24
|
|
KG-USAGE-INITIATOR-SIGN 25
|
|
|
|
When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is
|
|
used as the usage number in the key derivation function for deriving
|
|
keys to be used in MIC tokens (as defined in section 4.2.6.1).
|
|
KG-USAGE-ACCEPTOR-SEAL is used for Wrap tokens (as defined in section
|
|
4.2.6.2). Similarly, when the sender is the context initiator,
|
|
KG-USAGE-INITIATOR-SIGN is used as the usage number in the key
|
|
derivation function for MIC tokens, while KG-USAGE-INITIATOR-SEAL is
|
|
used for Wrap tokens. Even if the Wrap token does not provide for
|
|
confidentiality, the same usage values specified above are used.
|
|
|
|
During the context initiation and acceptance sequence, the acceptor
|
|
MAY assert a subkey in the AP-REP message. If the acceptor asserts a
|
|
subkey, the base key is the acceptor-asserted subkey and subsequent
|
|
per-message tokens MUST be flagged with "AcceptorSubkey", as
|
|
described in section 4.2.2. Otherwise, if the initiator asserts a
|
|
subkey in the AP-REQ message, the base key is this subkey; if the
|
|
initiator does not assert a subkey, the base key is the session key
|
|
in the service ticket.
|
|
|
|
3. Quality of Protection
|
|
|
|
The GSS-API specification [RFC2743] provides Quality of Protection
|
|
(QOP) values that can be used by applications to request a certain
|
|
type of encryption or signing. A zero QOP value is used to indicate
|
|
the "default" protection; applications that do not use the default
|
|
QOP are not guaranteed to be portable across implementations, or even
|
|
to inter-operate with different deployment configurations of the same
|
|
implementation. Using a different algorithm than the one for which
|
|
the key is defined may not be appropriate. Therefore, when the new
|
|
method in this document is used, the QOP value is ignored.
|
|
|
|
|
|
|
|
Zhu, et al. Standards Track [Page 4]
|
|
|
|
RFC 4121 Kerberos Version 5 GSS-API July 2005
|
|
|
|
|
|
The encryption and checksum algorithms in per-message tokens are now
|
|
implicitly defined by the algorithms associated with the session key
|
|
or subkey. Therefore, algorithm identifiers as described in
|
|
[RFC1964] are no longer needed and are removed from the new token
|
|
headers.
|
|
|
|
4. Definitions and Token Formats
|
|
|
|
This section provides terms and definitions, as well as descriptions
|
|
for tokens specific to the Kerberos Version 5 GSS-API mechanism.
|
|
|
|
4.1. Context Establishment Tokens
|
|
|
|
All context establishment tokens emitted by the Kerberos Version 5
|
|
GSS-API mechanism SHALL have the framing described in section 3.1 of
|
|
[RFC2743], as illustrated by the following pseudo-ASN.1 structures:
|
|
|
|
GSS-API DEFINITIONS ::=
|
|
|
|
BEGIN
|
|
|
|
MechType ::= OBJECT IDENTIFIER
|
|
-- representing Kerberos V5 mechanism
|
|
|
|
GSSAPI-Token ::=
|
|
-- option indication (delegation, etc.) indicated within
|
|
-- mechanism-specific token
|
|
[APPLICATION 0] IMPLICIT SEQUENCE {
|
|
thisMech MechType,
|
|
innerToken ANY DEFINED BY thisMech
|
|
-- contents mechanism-specific
|
|
-- ASN.1 structure not required
|
|
}
|
|
|
|
END
|
|
|
|
The innerToken field starts with a two-octet token-identifier
|
|
(TOK_ID) expressed in big-endian order, followed by a Kerberos
|
|
message.
|
|
|
|
Following are the TOK_ID values used in the context establishment
|
|
tokens:
|
|
|
|
Token TOK_ID Value in Hex
|
|
-----------------------------------------
|
|
KRB_AP_REQ 01 00
|
|
KRB_AP_REP 02 00
|
|
KRB_ERROR 03 00
|
|
|
|
|
|
|
|
Zhu, et al. Standards Track [Page 5]
|
|
|
|
RFC 4121 Kerberos Version 5 GSS-API July 2005
|
|
|
|
|
|
Where Kerberos message KRB_AP_REQUEST, KRB_AP_REPLY, and KRB_ERROR
|
|
are defined in [RFC4120].
|
|
|
|
If an unknown token identifier (TOK_ID) is received in the initial
|
|
context establishment token, the receiver MUST return
|
|
GSS_S_CONTINUE_NEEDED major status, and the returned output token
|
|
MUST contain a KRB_ERROR message with the error code
|
|
KRB_AP_ERR_MSG_TYPE [RFC4120].
|
|
|
|
4.1.1. Authenticator Checksum
|
|
|
|
The authenticator in the KRB_AP_REQ message MUST include the optional
|
|
sequence number and the checksum field. The checksum field is used
|
|
to convey service flags, channel bindings, and optional delegation
|
|
information.
|
|
|
|
The checksum type MUST be 0x8003. When delegation is used, a
|
|
ticket-granting ticket will be transferred in a KRB_CRED message.
|
|
This ticket SHOULD have its forwardable flag set. The EncryptedData
|
|
field of the KRB_CRED message [RFC4120] MUST be encrypted in the
|
|
session key of the ticket used to authenticate the context.
|
|
|
|
The authenticator checksum field SHALL have the following format:
|
|
|
|
Octet Name Description
|
|
-----------------------------------------------------------------
|
|
0..3 Lgth Number of octets in Bnd field; Represented
|
|
in little-endian order; Currently contains
|
|
hex value 10 00 00 00 (16).
|
|
4..19 Bnd Channel binding information, as described in
|
|
section 4.1.1.2.
|
|
20..23 Flags Four-octet context-establishment flags in
|
|
little-endian order as described in section
|
|
4.1.1.1.
|
|
24..25 DlgOpt The delegation option identifier (=1) in
|
|
little-endian order [optional]. This field
|
|
and the next two fields are present if and
|
|
only if GSS_C_DELEG_FLAG is set as described
|
|
in section 4.1.1.1.
|
|
26..27 Dlgth The length of the Deleg field in
|
|
little-endian order [optional].
|
|
28..(n-1) Deleg A KRB_CRED message (n = Dlgth + 28)
|
|
[optional].
|
|
n..last Exts Extensions [optional].
|
|
|
|
The length of the checksum field MUST be at least 24 octets when
|
|
GSS_C_DELEG_FLAG is not set (as described in section 4.1.1.1), and at
|
|
least 28 octets plus Dlgth octets when GSS_C_DELEG_FLAG is set. When
|
|
|
|
|
|
|
|
Zhu, et al. Standards Track [Page 6]
|
|
|
|
RFC 4121 Kerberos Version 5 GSS-API July 2005
|
|
|
|
|
|
GSS_C_DELEG_FLAG is set, the DlgOpt, Dlgth, and Deleg fields of the
|
|
checksum data MUST immediately follow the Flags field. The optional
|
|
trailing octets (namely the "Exts" field) facilitate future
|
|
extensions to this mechanism. When delegation is not used, but the
|
|
Exts field is present, the Exts field starts at octet 24 (DlgOpt,
|
|
Dlgth and Deleg are absent).
|
|
|
|
Initiators that do not support the extensions MUST NOT include more
|
|
than 24 octets in the checksum field (when GSS_C_DELEG_FLAG is not
|
|
set) or more than 28 octets plus the KRB_CRED in the Deleg field
|
|
(when GSS_C_DELEG_FLAG is set). Acceptors that do not understand the
|
|
|
|
Extensions MUST ignore any octets past the Deleg field of the
|
|
checksum data (when GSS_C_DELEG_FLAG is set) or past the Flags field
|
|
of the checksum data (when GSS_C_DELEG_FLAG is not set).
|
|
|
|
4.1.1.1. Checksum Flags Field
|
|
|
|
The checksum "Flags" field is used to convey service options or
|
|
extension negotiation information.
|
|
|
|
The following context establishment flags are defined in [RFC2744].
|
|
|
|
Flag Name Value
|
|
---------------------------------
|
|
GSS_C_DELEG_FLAG 1
|
|
GSS_C_MUTUAL_FLAG 2
|
|
GSS_C_REPLAY_FLAG 4
|
|
GSS_C_SEQUENCE_FLAG 8
|
|
GSS_C_CONF_FLAG 16
|
|
GSS_C_INTEG_FLAG 32
|
|
|
|
Context establishment flags are exposed to the calling application.
|
|
If the calling application desires a particular service option, then
|
|
it requests that option via GSS_Init_sec_context() [RFC2743]. If the
|
|
corresponding return state values [RFC2743] indicate that any of the
|
|
above optional context level services will be active on the context,
|
|
the corresponding flag values in the table above MUST be set in the
|
|
checksum Flags field.
|
|
|
|
Flag values 4096..524288 (2^12, 2^13, ..., 2^19) are reserved for use
|
|
with legacy vendor-specific extensions to this mechanism.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Standards Track [Page 7]
|
|
|
|
RFC 4121 Kerberos Version 5 GSS-API July 2005
|
|
|
|
|
|
All other flag values not specified herein are reserved for future
|
|
use. Future revisions of this mechanism may use these reserved flags
|
|
and may rely on implementations of this version to not use such flags
|
|
in order to properly negotiate mechanism versions. Undefined flag
|
|
values MUST be cleared by the sender, and unknown flags MUST be
|
|
ignored by the receiver.
|
|
|
|
4.1.1.2. Channel Binding Information
|
|
|
|
These tags are intended to be used to identify the particular
|
|
communications channel for which the GSS-API security context
|
|
establishment tokens are intended, thus limiting the scope within
|
|
which an intercepted context establishment token can be reused by an
|
|
attacker (see [RFC2743], section 1.1.6).
|
|
|
|
When using C language bindings, channel bindings are communicated to
|
|
the GSS-API using the following structure [RFC2744]:
|
|
|
|
typedef struct gss_channel_bindings_struct {
|
|
OM_uint32 initiator_addrtype;
|
|
gss_buffer_desc initiator_address;
|
|
OM_uint32 acceptor_addrtype;
|
|
gss_buffer_desc acceptor_address;
|
|
gss_buffer_desc application_data;
|
|
} *gss_channel_bindings_t;
|
|
|
|
The member fields and constants used for different address types are
|
|
defined in [RFC2744].
|
|
|
|
The "Bnd" field contains the MD5 hash of channel bindings, taken over
|
|
all non-null components of bindings, in order of declaration.
|
|
Integer fields within channel bindings are represented in little-
|
|
endian order for the purposes of the MD5 calculation.
|
|
|
|
In computing the contents of the Bnd field, the following detailed
|
|
points apply:
|
|
|
|
(1) For purposes of MD5 hash computation, each integer field and
|
|
input length field SHALL be formatted into four octets, using
|
|
little-endian octet ordering.
|
|
|
|
(2) All input length fields within gss_buffer_desc elements of a
|
|
gss_channel_bindings_struct even those which are zero-valued,
|
|
SHALL be included in the hash calculation. The value elements of
|
|
gss_buffer_desc elements SHALL be dereferenced, and the resulting
|
|
data SHALL be included within the hash computation, only for the
|
|
case of gss_buffer_desc elements having non-zero length
|
|
specifiers.
|
|
|
|
|
|
|
|
Zhu, et al. Standards Track [Page 8]
|
|
|
|
RFC 4121 Kerberos Version 5 GSS-API July 2005
|
|
|
|
|
|
(3) If the caller passes the value GSS_C_NO_BINDINGS instead of a
|
|
valid channel binding structure, the Bnd field SHALL be set to 16
|
|
zero-valued octets.
|
|
|
|
If the caller to GSS_Accept_sec_context [RFC2743] passes in
|
|
GSS_C_NO_CHANNEL_BINDINGS [RFC2744] as the channel bindings, then the
|
|
acceptor MAY ignore any channel bindings supplied by the initiator,
|
|
returning success even if the initiator did pass in channel bindings.
|
|
|
|
If the application supplies, in the channel bindings, a buffer with a
|
|
length field larger than 4294967295 (2^32 - 1), the implementation of
|
|
this mechanism MAY choose to reject the channel bindings altogether,
|
|
using major status GSS_S_BAD_BINDINGS [RFC2743]. In any case, the
|
|
size of channel-binding data buffers that can be used (interoperable,
|
|
without extensions) with this specification is limited to 4294967295
|
|
octets.
|
|
|
|
4.2. Per-Message Tokens
|
|
|
|
Two classes of tokens are defined in this section: (1) "MIC" tokens,
|
|
emitted by calls to GSS_GetMIC() and consumed by calls to
|
|
GSS_VerifyMIC(), and (2) "Wrap" tokens, emitted by calls to
|
|
GSS_Wrap() and consumed by calls to GSS_Unwrap().
|
|
|
|
These new per-message tokens do not include the generic GSS-API token
|
|
framing used by the context establishment tokens. These new tokens
|
|
are designed to be used with newer crypto systems that can have
|
|
variable-size checksums.
|
|
|
|
4.2.1. Sequence Number
|
|
|
|
To distinguish intentionally-repeated messages from maliciously-
|
|
replayed ones, per-message tokens contain a sequence number field,
|
|
which is a 64 bit integer expressed in big-endian order. After
|
|
sending a GSS_GetMIC() or GSS_Wrap() token, the sender's sequence
|
|
numbers SHALL be incremented by one.
|
|
|
|
4.2.2. Flags Field
|
|
|
|
The "Flags" field is a one-octet integer used to indicate a set of
|
|
attributes for the protected message. For example, one flag is
|
|
allocated as the direction-indicator, thus preventing the acceptance
|
|
of the same message sent back in the reverse direction by an
|
|
adversary.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Standards Track [Page 9]
|
|
|
|
RFC 4121 Kerberos Version 5 GSS-API July 2005
|
|
|
|
|
|
The meanings of bits in this field (the least significant bit is bit
|
|
0) are as follows:
|
|
|
|
Bit Name Description
|
|
--------------------------------------------------------------
|
|
0 SentByAcceptor When set, this flag indicates the sender
|
|
is the context acceptor. When not set,
|
|
it indicates the sender is the context
|
|
initiator.
|
|
1 Sealed When set in Wrap tokens, this flag
|
|
indicates confidentiality is provided
|
|
for. It SHALL NOT be set in MIC tokens.
|
|
2 AcceptorSubkey A subkey asserted by the context acceptor
|
|
is used to protect the message.
|
|
|
|
The rest of available bits are reserved for future use and MUST be
|
|
cleared. The receiver MUST ignore unknown flags.
|
|
|
|
4.2.3. EC Field
|
|
|
|
The "EC" (Extra Count) field is a two-octet integer field expressed
|
|
in big-endian order.
|
|
|
|
In Wrap tokens with confidentiality, the EC field SHALL be used to
|
|
encode the number of octets in the filler, as described in section
|
|
4.2.4.
|
|
|
|
In Wrap tokens without confidentiality, the EC field SHALL be used to
|
|
encode the number of octets in the trailing checksum, as described in
|
|
section 4.2.4.
|
|
|
|
4.2.4. Encryption and Checksum Operations
|
|
|
|
The encryption algorithms defined by the crypto profiles provide for
|
|
integrity protection [RFC3961]. Therefore, no separate checksum is
|
|
needed.
|
|
|
|
The result of decryption can be longer than the original plaintext
|
|
[RFC3961] and the extra trailing octets are called "crypto-system
|
|
residue" in this document. However, given the size of any plaintext
|
|
data, one can always find a (possibly larger) size, such that when
|
|
padding the to-be-encrypted text to that size, there will be no
|
|
crypto-system residue added [RFC3961].
|
|
|
|
In Wrap tokens that provide for confidentiality, the first 16 octets
|
|
of the Wrap token (the "header", as defined in section 4.2.6), SHALL
|
|
be appended to the plaintext data before encryption. Filler octets
|
|
MAY be inserted between the plaintext data and the "header." The
|
|
|
|
|
|
|
|
Zhu, et al. Standards Track [Page 10]
|
|
|
|
RFC 4121 Kerberos Version 5 GSS-API July 2005
|
|
|
|
|
|
values and size of the filler octets are chosen by implementations,
|
|
such that there SHALL be no crypto-system residue present after the
|
|
decryption. The resulting Wrap token is {"header" |
|
|
encrypt(plaintext-data | filler | "header")}, where encrypt() is the
|
|
encryption operation (which provides for integrity protection)
|
|
defined in the crypto profile [RFC3961], and the RRC field (as
|
|
defined in section 4.2.5) in the to-be-encrypted header contains the
|
|
hex value 00 00.
|
|
|
|
In Wrap tokens that do not provide for confidentiality, the checksum
|
|
SHALL be calculated first over the to-be-signed plaintext data, and
|
|
then over the first 16 octets of the Wrap token (the "header", as
|
|
defined in section 4.2.6). Both the EC field and the RRC field in
|
|
the token header SHALL be filled with zeroes for the purpose of
|
|
calculating the checksum. The resulting Wrap token is {"header" |
|
|
plaintext-data | get_mic(plaintext-data | "header")}, where get_mic()
|
|
is the checksum operation for the required checksum mechanism of the
|
|
chosen encryption mechanism defined in the crypto profile [RFC3961].
|
|
|
|
The parameters for the key and the cipher-state in the encrypt() and
|
|
get_mic() operations have been omitted for brevity.
|
|
|
|
For MIC tokens, the checksum SHALL be calculated as follows: the
|
|
checksum operation is calculated first over the to-be-signed
|
|
plaintext data, and then over the first 16 octets of the MIC token,
|
|
where the checksum mechanism is the required checksum mechanism of
|
|
the chosen encryption mechanism defined in the crypto profile
|
|
[RFC3961].
|
|
|
|
The resulting Wrap and MIC tokens bind the data to the token header,
|
|
including the sequence number and the direction indicator.
|
|
|
|
4.2.5. RRC Field
|
|
|
|
The "RRC" (Right Rotation Count) field in Wrap tokens is added to
|
|
allow the data to be encrypted in-place by existing SSPI (Security
|
|
Service Provider Interface) [SSPI] applications that do not provide
|
|
an additional buffer for the trailer (the cipher text after the in-
|
|
place-encrypted data) in addition to the buffer for the header (the
|
|
cipher text before the in-place-encrypted data). Excluding the first
|
|
16 octets of the token header, the resulting Wrap token in the
|
|
previous section is rotated to the right by "RRC" octets. The net
|
|
result is that "RRC" octets of trailing octets are moved toward the
|
|
header.
|
|
|
|
Consider the following as an example of this rotation operation:
|
|
Assume that the RRC value is 3 and the token before the rotation is
|
|
{"header" | aa | bb | cc | dd | ee | ff | gg | hh}. The token after
|
|
|
|
|
|
|
|
Zhu, et al. Standards Track [Page 11]
|
|
|
|
RFC 4121 Kerberos Version 5 GSS-API July 2005
|
|
|
|
|
|
rotation would be {"header" | ff | gg | hh | aa | bb | cc | dd | ee
|
|
}, where {aa | bb | cc |...| hh} would be used to indicate the octet
|
|
sequence.
|
|
|
|
The RRC field is expressed as a two-octet integer in big-endian
|
|
order.
|
|
|
|
The rotation count value is chosen by the sender based on
|
|
implementation details. The receiver MUST be able to interpret all
|
|
possible rotation count values, including rotation counts greater
|
|
than the length of the token.
|
|
|
|
4.2.6. Message Layouts
|
|
|
|
Per-message tokens start with a two-octet token identifier (TOK_ID)
|
|
field, expressed in big-endian order. These tokens are defined
|
|
separately in the following sub-sections.
|
|
|
|
4.2.6.1. MIC Tokens
|
|
|
|
Use of the GSS_GetMIC() call yields a token (referred as the MIC
|
|
token in this document), separate from the user data being protected,
|
|
which can be used to verify the integrity of that data as received.
|
|
The token has the following format:
|
|
|
|
Octet no Name Description
|
|
--------------------------------------------------------------
|
|
0..1 TOK_ID Identification field. Tokens emitted by
|
|
GSS_GetMIC() contain the hex value 04 04
|
|
expressed in big-endian order in this
|
|
field.
|
|
2 Flags Attributes field, as described in section
|
|
4.2.2.
|
|
3..7 Filler Contains five octets of hex value FF.
|
|
8..15 SND_SEQ Sequence number field in clear text,
|
|
expressed in big-endian order.
|
|
16..last SGN_CKSUM Checksum of the "to-be-signed" data and
|
|
octet 0..15, as described in section 4.2.4.
|
|
|
|
The Filler field is included in the checksum calculation for
|
|
simplicity.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Standards Track [Page 12]
|
|
|
|
RFC 4121 Kerberos Version 5 GSS-API July 2005
|
|
|
|
|
|
4.2.6.2. Wrap Tokens
|
|
|
|
Use of the GSS_Wrap() call yields a token (referred as the Wrap token
|
|
in this document), which consists of a descriptive header, followed
|
|
by a body portion that contains either the input user data in
|
|
plaintext concatenated with the checksum, or the input user data
|
|
encrypted. The GSS_Wrap() token SHALL have the following format:
|
|
|
|
Octet no Name Description
|
|
--------------------------------------------------------------
|
|
0..1 TOK_ID Identification field. Tokens emitted by
|
|
GSS_Wrap() contain the hex value 05 04
|
|
expressed in big-endian order in this
|
|
field.
|
|
2 Flags Attributes field, as described in section
|
|
4.2.2.
|
|
3 Filler Contains the hex value FF.
|
|
4..5 EC Contains the "extra count" field, in big-
|
|
endian order as described in section 4.2.3.
|
|
6..7 RRC Contains the "right rotation count" in big-
|
|
endian order, as described in section
|
|
4.2.5.
|
|
8..15 SND_SEQ Sequence number field in clear text,
|
|
expressed in big-endian order.
|
|
16..last Data Encrypted data for Wrap tokens with
|
|
confidentiality, or plaintext data followed
|
|
by the checksum for Wrap tokens without
|
|
confidentiality, as described in section
|
|
4.2.4.
|
|
|
|
4.3. Context Deletion Tokens
|
|
|
|
Context deletion tokens are empty in this mechanism. Both peers to a
|
|
security context invoke GSS_Delete_sec_context() [RFC2743]
|
|
independently, passing a null output_context_token buffer to indicate
|
|
that no context_token is required. Implementations of
|
|
GSS_Delete_sec_context() should delete relevant locally-stored
|
|
context information.
|
|
|
|
4.4. Token Identifier Assignment Considerations
|
|
|
|
Token identifiers (TOK_ID) from 0x60 0x00 through 0x60 0xFF inclusive
|
|
are reserved and SHALL NOT be assigned. Thus, by examining the first
|
|
two octets of a token, one can tell unambiguously if it is wrapped
|
|
with the generic GSS-API token framing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Standards Track [Page 13]
|
|
|
|
RFC 4121 Kerberos Version 5 GSS-API July 2005
|
|
|
|
|
|
5. Parameter Definitions
|
|
|
|
This section defines parameter values used by the Kerberos V5 GSS-API
|
|
mechanism. It defines interface elements that support portability,
|
|
and assumes use of C language bindings per [RFC2744].
|
|
|
|
5.1. Minor Status Codes
|
|
|
|
This section recommends common symbolic names for minor_status values
|
|
to be returned by the Kerberos V5 GSS-API mechanism. Use of these
|
|
definitions will enable independent implementers to enhance
|
|
application portability across different implementations of the
|
|
mechanism defined in this specification. (In all cases,
|
|
implementations of GSS_Display_status() will enable callers to
|
|
convert minor_status indicators to text representations.) Each
|
|
implementation should make available, through include files or other
|
|
means, a facility to translate these symbolic names into the concrete
|
|
values that a particular GSS-API implementation uses to represent the
|
|
minor_status values specified in this section.
|
|
|
|
This list may grow over time and the need for additional minor_status
|
|
codes, specific to particular implementations, may arise. However,
|
|
it is recommended that implementations should return a minor_status
|
|
value as defined on a mechanism-wide basis within this section when
|
|
that code accurately represents reportable status rather than using a
|
|
separate, implementation-defined code.
|
|
|
|
5.1.1. Non-Kerberos-specific Codes
|
|
|
|
GSS_KRB5_S_G_BAD_SERVICE_NAME
|
|
/* "No @ in SERVICE-NAME name string" */
|
|
GSS_KRB5_S_G_BAD_STRING_UID
|
|
/* "STRING-UID-NAME contains nondigits" */
|
|
GSS_KRB5_S_G_NOUSER
|
|
/* "UID does not resolve to username" */
|
|
GSS_KRB5_S_G_VALIDATE_FAILED
|
|
/* "Validation error" */
|
|
GSS_KRB5_S_G_BUFFER_ALLOC
|
|
/* "Couldn't allocate gss_buffer_t data" */
|
|
GSS_KRB5_S_G_BAD_MSG_CTX
|
|
/* "Message context invalid" */
|
|
GSS_KRB5_S_G_WRONG_SIZE
|
|
/* "Buffer is the wrong size" */
|
|
GSS_KRB5_S_G_BAD_USAGE
|
|
/* "Credential usage type is unknown" */
|
|
GSS_KRB5_S_G_UNKNOWN_QOP
|
|
/* "Unknown quality of protection specified" */
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Standards Track [Page 14]
|
|
|
|
RFC 4121 Kerberos Version 5 GSS-API July 2005
|
|
|
|
|
|
5.1.2. Kerberos-specific Codes
|
|
|
|
GSS_KRB5_S_KG_CCACHE_NOMATCH
|
|
/* "Client principal in credentials does not match
|
|
specified name" */
|
|
GSS_KRB5_S_KG_KEYTAB_NOMATCH
|
|
/* "No key available for specified service
|
|
principal" */
|
|
GSS_KRB5_S_KG_TGT_MISSING
|
|
/* "No Kerberos ticket-granting ticket available" */
|
|
GSS_KRB5_S_KG_NO_SUBKEY
|
|
/* "Authenticator has no subkey" */
|
|
GSS_KRB5_S_KG_CONTEXT_ESTABLISHED
|
|
/* "Context is already fully established" */
|
|
GSS_KRB5_S_KG_BAD_SIGN_TYPE
|
|
/* "Unknown signature type in token" */
|
|
GSS_KRB5_S_KG_BAD_LENGTH
|
|
/* "Invalid field length in token" */
|
|
GSS_KRB5_S_KG_CTX_INCOMPLETE
|
|
/* "Attempt to use incomplete security context" */
|
|
|
|
5.2. Buffer Sizes
|
|
|
|
All implementations of this specification MUST be capable of
|
|
accepting buffers of at least 16K octets as input to GSS_GetMIC(),
|
|
GSS_VerifyMIC(), and GSS_Wrap(). They MUST also be capable of
|
|
accepting the output_token generated by GSS_Wrap() for a 16K octet
|
|
input buffer as input to GSS_Unwrap(). Implementations SHOULD
|
|
support 64K octet input buffers, and MAY support even larger input
|
|
buffer sizes.
|
|
|
|
6. Backwards Compatibility Considerations
|
|
|
|
The new token formats defined in this document will only be
|
|
recognized by new implementations. To address this, implementations
|
|
can always use the explicit sign or seal algorithm in [RFC1964] when
|
|
the key type corresponds to not "newer" enctypes. As an alternative,
|
|
one might retry sending the message with the sign or seal algorithm
|
|
explicitly defined as in [RFC1964]. However, this would require
|
|
either the use of a mechanism such as [RFC2478] to securely negotiate
|
|
the method, or the use of an out-of-band mechanism to choose the
|
|
appropriate mechanism. For this reason, it is RECOMMENDED that the
|
|
new token formats defined in this document SHOULD be used only if
|
|
both peers are known to support the new mechanism during context
|
|
negotiation because of, for example, the use of "new" enctypes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Standards Track [Page 15]
|
|
|
|
RFC 4121 Kerberos Version 5 GSS-API July 2005
|
|
|
|
|
|
GSS_Unwrap() or GSS_VerifyMIC() can process a message token as
|
|
follows: it can look at the first octet of the token header, and if
|
|
it is 0x60, then the token must carry the generic GSS-API pseudo
|
|
ASN.1 framing. Otherwise, the first two octets of the token contain
|
|
the TOK_ID that uniquely identify the token message format.
|
|
|
|
7. Security Considerations
|
|
|
|
Channel bindings are validated by the acceptor. The acceptor can
|
|
ignore the channel bindings restriction supplied by the initiator and
|
|
carried in the authenticator checksum, if (1) channel bindings are
|
|
not used by GSS_Accept_sec_context [RFC2743], and (2) the acceptor
|
|
does not prove to the initiator that it has the same channel bindings
|
|
as the initiator (even if the client requested mutual
|
|
authentication). This limitation should be considered by designers
|
|
of applications that would use channel bindings, whether to limit the
|
|
use of GSS-API contexts to nodes with specific network addresses, to
|
|
authenticate other established, secure channels using Kerberos
|
|
Version 5, or for any other purpose.
|
|
|
|
Session key types are selected by the KDC. Under the current
|
|
mechanism, no negotiation of algorithm types occurs, so server-side
|
|
(acceptor) implementations cannot request that clients not use
|
|
algorithm types not understood by the server. However,
|
|
administrators can control what enctypes can be used for session keys
|
|
for this mechanism by controlling the set of the ticket session key
|
|
enctypes which the KDC is willing to use in tickets for a given
|
|
acceptor principal. Therefore, the KDC could be given the task of
|
|
limiting session keys for a given service to types actually supported
|
|
by the Kerberos and GSSAPI software on the server. This has a
|
|
drawback for cases in which a service principal name is used for both
|
|
GSSAPI-based and non-GSSAPI-based communication (most notably the
|
|
"host" service key), if the GSSAPI implementation does not understand
|
|
(for example) AES [RFC3962], but the Kerberos implementation does.
|
|
This means that AES session keys cannot be issued for that service
|
|
principal, which keeps the protection of non-GSSAPI services weaker
|
|
than necessary. KDC administrators desiring to limit the session key
|
|
types to support interoperability with such GSSAPI implementations
|
|
should carefully weigh the reduction in protection offered by such
|
|
mechanisms against the benefits of interoperability.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Standards Track [Page 16]
|
|
|
|
RFC 4121 Kerberos Version 5 GSS-API July 2005
|
|
|
|
|
|
8. Acknowledgements
|
|
|
|
Ken Raeburn and Nicolas Williams corrected many of our errors in the
|
|
use of generic profiles and were instrumental in the creation of this
|
|
document.
|
|
|
|
The text for security considerations was contributed by Nicolas
|
|
Williams and Ken Raeburn.
|
|
|
|
Sam Hartman and Ken Raeburn suggested the "floating trailer" idea,
|
|
namely the encoding of the RRC field.
|
|
|
|
Sam Hartman and Nicolas Williams recommended the replacing our
|
|
earlier key derivation function for directional keys with different
|
|
key usage numbers for each direction as well as retaining the
|
|
directional bit for maximum compatibility.
|
|
|
|
Paul Leach provided numerous suggestions and comments.
|
|
|
|
Scott Field, Richard Ward, Dan Simon, Kevin Damour, and Simon
|
|
Josefsson also provided valuable inputs on this document.
|
|
|
|
Jeffrey Hutzelman provided comments and clarifications for the text
|
|
related to the channel bindings.
|
|
|
|
Jeffrey Hutzelman and Russ Housley suggested many editorial changes.
|
|
|
|
Luke Howard provided implementations of this document for the Heimdal
|
|
code base, and helped inter-operability testing with the Microsoft
|
|
code base, together with Love Hornquist Astrand. These experiments
|
|
formed the basis of this document.
|
|
|
|
Martin Rex provided suggestions of TOK_ID assignment recommendations,
|
|
thus the token tagging in this document is unambiguous if the token
|
|
is wrapped with the pseudo ASN.1 header.
|
|
|
|
John Linn wrote the original Kerberos Version 5 mechanism
|
|
specification [RFC1964], of which some text has been retained.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Standards Track [Page 17]
|
|
|
|
RFC 4121 Kerberos Version 5 GSS-API July 2005
|
|
|
|
|
|
9. References
|
|
|
|
9.1. Normative References
|
|
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|
|
|
[RFC2743] Linn, J., "Generic Security Service Application Program
|
|
Interface Version 2, Update 1", RFC 2743, January 2000.
|
|
|
|
[RFC2744] Wray, J., "Generic Security Service API Version 2:
|
|
C-bindings", RFC 2744, January 2000.
|
|
|
|
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
|
|
1964, June 1996.
|
|
|
|
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
|
|
Kerberos 5", RFC 3961, February 2005.
|
|
|
|
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
|
|
Kerberos Network Authentication Service (V5)", RFC 4120,
|
|
July 2005.
|
|
|
|
9.2. Informative References
|
|
|
|
[SSPI] Leach, P., "Security Service Provider Interface",
|
|
Microsoft Developer Network (MSDN), April 2003.
|
|
|
|
[RFC3962] Raeburn, K., "Advanced Encryption Standard (AES)
|
|
Encryption for Kerberos 5", RFC 3962, February 2005.
|
|
|
|
[RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
|
|
Negotiation Mechanism", RFC 2478, December 1998.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Standards Track [Page 18]
|
|
|
|
RFC 4121 Kerberos Version 5 GSS-API July 2005
|
|
|
|
|
|
Authors' Addresses
|
|
|
|
Larry Zhu
|
|
One Microsoft Way
|
|
Redmond, WA 98052 - USA
|
|
|
|
EMail: LZhu@microsoft.com
|
|
|
|
|
|
Karthik Jaganathan
|
|
One Microsoft Way
|
|
Redmond, WA 98052 - USA
|
|
|
|
EMail: karthikj@microsoft.com
|
|
|
|
|
|
Sam Hartman
|
|
Massachusetts Institute of Technology
|
|
77 Massachusetts Avenue
|
|
Cambridge, MA 02139 - USA
|
|
|
|
EMail: hartmans-ietf@mit.edu
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Standards Track [Page 19]
|
|
|
|
RFC 4121 Kerberos Version 5 GSS-API July 2005
|
|
|
|
|
|
Full Copyright Statement
|
|
|
|
Copyright (C) The Internet Society (2005).
|
|
|
|
This document is subject to the rights, licenses and restrictions
|
|
contained in BCP 78, and except as set forth therein, the authors
|
|
retain all their rights.
|
|
|
|
This document and the information contained herein are provided on an
|
|
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
|
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
|
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
|
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
|
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
|
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|
|
|
Intellectual Property
|
|
|
|
The IETF takes no position regarding the validity or scope of any
|
|
Intellectual Property Rights or other rights that might be claimed to
|
|
pertain to the implementation or use of the technology described in
|
|
this document or the extent to which any license under such rights
|
|
might or might not be available; nor does it represent that it has
|
|
made any independent effort to identify any such rights. Information
|
|
on the procedures with respect to rights in RFC documents can be
|
|
found in BCP 78 and BCP 79.
|
|
|
|
Copies of IPR disclosures made to the IETF Secretariat and any
|
|
assurances of licenses to be made available, or the result of an
|
|
attempt made to obtain a general license or permission for the use of
|
|
such proprietary rights by implementers or users of this
|
|
specification can be obtained from the IETF on-line IPR repository at
|
|
http://www.ietf.org/ipr.
|
|
|
|
The IETF invites any interested party to bring to its attention any
|
|
copyrights, patents or patent applications, or other proprietary
|
|
rights that may cover technology that may be required to implement
|
|
this standard. Please address the information to the IETF at ietf-
|
|
ipr@ietf.org.
|
|
|
|
Acknowledgement
|
|
|
|
Funding for the RFC Editor function is currently provided by the
|
|
Internet Society.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Standards Track [Page 20]
|
|
|