RFC 4121
The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2
RFC 4121: The Kerberos Version 5 GSS-API Mechanism: Version 2 🎀
okay bestie, this is the spec 💖 It's RFC 4121, a Standards Track doc from the Network Working Group, dated July 2005. The authors are L. Zhu and K. Jaganathan (both at Microsoft) and S. Hartman (at MIT) 👑. It updates RFC 1964, which is the original Kerberos GSS-API mechanism, and the title block doesn't list anything it obsoletes 🦋.
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 ....................................18Status of This Memo 📜
This one's an Internet standards track protocol for the Internet community 🌸. It asks for discussion and suggestions for improvements. For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) 🔍. And the good news: distribution of this memo is unlimited 💜.
Copyright Notice ©️
Copyright (C) The Internet Society (2005). 🌈
Abstract 🦋
This document is all about the rules, procedures, and conventions that peers use when they implement the Generic Security Service Application Program Interface (GSS-API) with the Kerberos Version 5 mechanism ✨.
RFC 1964 gets an update here, with incremental changes 🔥. Why? Because of newer stuff like the Kerberos cryptosystem framework 💅. These changes make it possible to add new cryptosystems by defining new per-message tokens, along with their encryption and checksum algorithms, all built on the cryptosystem profiles 🍓.
1. Introduction ✨
Okay so, [RFC3961] is the one that sets up a generic framework for describing encryption and checksum types used with Kerberos and its related protocols 🧚.
[RFC1964] is where the GSS-API mechanism for Kerberos Version 5 lives 🌸. It defines the format of context establishment tokens, per-message tokens, and context deletion tokens. It also uses algorithm identifiers for each cryptosystem in the per-message and context deletion tokens 💀.
The big move in this doc is getting rid of algorithm identifiers entirely 💅. How? The per-message tokens use the same encryption algorithm that the crypto profile [RFC3961] specifies for the session key or subkey made during context negotiation, plus its required checksum algorithm 🦋. So the message layouts of the per-message tokens get revised to drop the algorithm indicators and add some extra info to support the generic crypto framework [RFC3961] 🎀.
Tokens that go back and forth between GSS-API peers during security context establishment are described here too 🫶. The data the GSS-API endpoint swaps with the Kerberos Key Distribution Center (KDC) [RFC4120] isn't specific to GSS-API, so it's defined in [RFC4120] instead of this spec 🔥.
Here's the important bit: the new token formats in this document MUST be used with all "newer" encryption types [RFC4120]. They MAY also be used with encryption types that aren't "newer", but only if the initiator and acceptor know from context establishment that they can both process these new token formats 👑.
"Newer" encryption types are the ones specified along with or after the new Kerberos cryptosystem specification [RFC3961], as defined in section 3.1.3 of [RFC4120] 🌈. Here's the list of not-newer encryption types from [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 23Conventions 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 read as described in [RFC2119] 💖.
Quick vocab check: "little-endian order" is shorthand for the least-significant-octet-first encoding, and "big-endian order" is the most-significant-octet-first encoding 🧠.
2. Key Derivation for Per-Message Tokens 🔑
Okay so, to limit how much any single key gets exposed, [RFC3961] went with "one-way" "entropy-preserving" derived keys 🦋. You make them from a base key or protocol key, for different purposes or key usages ✨.
This doc defines four key usage values, and they're used to derive a specific key for signing and sealing messages from the session key or subkey [RFC4120] that was created during context establishment 💅:
Name Value
-------------------------------------
KG-USAGE-ACCEPTOR-SEAL 22
KG-USAGE-ACCEPTOR-SIGN 23
KG-USAGE-INITIATOR-SEAL 24
KG-USAGE-INITIATOR-SIGN 25So when the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is the usage number in the key derivation function for deriving keys for 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) 🌸. When the sender is the context initiator, it flips: KG-USAGE-INITIATOR-SIGN goes to MIC tokens and KG-USAGE-INITIATOR-SEAL goes to Wrap tokens 💜. And even if the Wrap token doesn't provide confidentiality, the same usage values still apply 🫶.
Now for the handshake drama 🍿. During context initiation and acceptance, the acceptor MAY assert a subkey in the AP-REP message. If the acceptor asserts a subkey, that subkey becomes the base key, 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, that subkey is the base key. And if the initiator doesn't assert a subkey either, the base key is the session key in the service ticket 👑.
3. Quality of Protection 🛡️
The GSS-API specification [RFC2743] gives apps Quality of Protection (QOP) values, so they can ask for a certain type of encryption or signing 💅. A zero QOP value means "default" protection 🌈. Here's the tea: apps that don't use the default QOP aren't guaranteed to be portable across implementations, or even to interoperate with different deployment configs of the same implementation 😭. Using a different algorithm than the one the key is defined for may not be appropriate either 🙈. So when the new method in this document is used, the QOP value gets ignored ✨.
The encryption and checksum algorithms in per-message tokens are now implicitly defined by the algorithms tied to the session key or subkey 🦋. That means algorithm identifiers, which [RFC1964] describes, are no longer needed, so they're removed from the new token headers 🎀.
4. Definitions and Token Formats 🧚
This section is where the terms and definitions live, plus the descriptions of tokens that are specific to the Kerberos Version 5 GSS-API mechanism 💖.
4.1. Context Establishment Tokens 🤝
All context establishment tokens that the Kerberos Version 5 GSS-API mechanism emits SHALL have the framing described in section 3.1 of [RFC2743] 🌸. Here's how that looks in pseudo-ASN.1:
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
}
ENDThe innerToken field starts with a two-octet token-identifier (TOK_ID) in big-endian order, and then comes a Kerberos message 🍓. These are the TOK_ID values for the context establishment tokens ✨:
Token TOK_ID Value in Hex
-----------------------------------------
KRB_AP_REQ 01 00
KRB_AP_REP 02 00
KRB_ERROR 03 00The Kerberos messages KRB_AP_REQUEST, KRB_AP_REPLY, and KRB_ERROR are defined in [RFC4120] 🦋.
Now the part you absolutely need to know 🚨: if an unknown token identifier (TOK_ID) shows up 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 ✨
okay bestie, the authenticator in the KRB_AP_REQ message MUST include the optional sequence number and the checksum field 💅 The checksum field is where we stash service flags, channel bindings, and optional delegation info, so it's basically the main character of this whole thing 🎀
The checksum type MUST be 0x8003 🔥. When delegation is used, a ticket-granting ticket gets 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 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) are there so future extensions can slot into 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 32Context establishment flags are exposed to the calling application 👑. If the calling application wants a particular service option, 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 🍓.
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 meant to identify the particular communications channel that the GSS-API security context establishment tokens are intended for 🌸. That limits how far 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.
(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 🙅♀️. They're designed to work with newer crypto systems that can have variable-size checksums 🧁.
4.2.1. Sequence Number 🔢
To tell intentionally-repeated messages apart from maliciously-replayed ones, per-message tokens contain a sequence number field 🕰️. It's 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, which stops an adversary from getting a message accepted when it's sent back in the reverse direction 🙃.
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 ✨
okay so the encryption algorithms in the crypto profiles already give you integrity protection 🔐 [RFC3961]. Which means no separate checksum is needed, bestie 💅
the decryption result can come out longer than the original plaintext [RFC3961], and those extra trailing octets are called "crypto-system residue" in this doc 🙈. ngl it's giving math brain, but here's the trick: for any plaintext size, you can always find a (possibly bigger) size where padding the text up to it means no crypto-system residue gets 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 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, so don't stress about them here 🧚
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. main character energy, fr fr 👑
4.2.5. RRC Field
the "RRC" (Right Rotation Count) field in Wrap tokens exists so the data can be encrypted in-place by existing SSPI (Security Service Provider Interface) [SSPI] applications 🫶. Those apps don't give you an extra buffer for the trailer (the cipher text after the in-place-encrypted data) on top of 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 from the previous section gets rotated to the right by "RRC" octets. The net result is that "RRC" octets of trailing octets get moved toward the header 🔄
here's an example of the rotation, iykyk 🍓 Assume the RRC value is 3 and the token before the rotation is {"header" | aa | bb | cc | dd | ee | ff | gg | hh}. The token after rotation would be {"header" | ff | gg | hh | aa | bb | cc | dd | ee }, where {aa | bb | cc |...| hh} is used to indicate the octet sequence.
the RRC field is 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 to as the MIC token in this document), separate from the user data being protected. You can use it 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 🙈
4.2.6.2. Wrap Tokens
use of the GSS_Wrap() call yields a token (referred to as the Wrap token in this document). It's got a descriptive header, followed by a body portion that holds 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 ✨
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. Using these definitions will enable independent implementers to level up 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 extra minor_status codes, specific to particular implementations, may show up. 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" */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 🎀
okay so bestie, the new token formats in this document are only going to be recognized by new implementations 😭 old ones just won't get them. The fix is that implementations can always use the explicit sign or seal algorithm in [RFC1964] when the key type is not a "newer" enctype 🫶 🌸
There's another option too: you could retry sending the message with the sign or seal algorithm explicitly defined as in [RFC1964]. BUT ngl that means you need either a mechanism like [RFC2478] to securely negotiate the method, or some out-of-band mechanism to pick the right one 💀 That's why 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. Main character energy for real ✨
Now, how GSS_Unwrap() or GSS_VerifyMIC() can process a message token: they can look at the first octet of the token header 👀 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 💀
okay this section is serious, so listen up 🫶
Channel bindings are validated by the acceptor. The acceptor can ignore the channel bindings restriction that the initiator supplied 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 they're limiting GSS-API contexts to nodes with specific network addresses, authenticating other established, secure channels using Kerberos Version 5, or doing anything else with them.
Session key types are selected by the KDC 👑 Under the current mechanism, no negotiation of algorithm types happens, so server-side (acceptor) implementations cannot ask clients to avoid algorithm types the server doesn't understand 😤 HOWEVER, administrators can control which enctypes are usable for session keys by controlling the set of ticket session key enctypes the KDC is willing to use in tickets for a given acceptor principal. So the KDC could be given the job of limiting session keys for a given service to types actually supported by the Kerberos and GSSAPI software on the server.
The catch is this: it's a drawback when 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 doesn't understand, for example, AES [RFC3962], but the Kerberos implementation does. Then AES session keys can't be issued for that service principal, which keeps the protection of non-GSSAPI services weaker than necessary 💔 KDC admins who want to limit session key types for interoperability with such GSSAPI implementations should carefully weigh the reduction in protection those mechanisms offer against the benefits of interoperability 🧚
8. Acknowledgements 🫶
Ken Raeburn and Nicolas Williams caught many of our mistakes in using generic profiles and were instrumental in creating 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, which is the encoding of the RRC field ✨
Sam Hartman and Nicolas Williams recommended replacing our earlier key derivation function for directional keys with different key usage numbers for each direction, while also 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 input on this document 🌸
Jeffrey Hutzelman provided comments and clarifications for the text related to channel bindings 🎀
Jeffrey Hutzelman and Russ Housley suggested many editorial changes ✏️
Luke Howard implemented this document for the Heimdal code base and helped with interoperability testing against the Microsoft code base, together with Love Hornquist Astrand. These experiments formed the basis of this document 🧁
Martin Rex suggested TOK_ID assignment recommendations, so the token tagging in this document is unambiguous when the token is wrapped with the pseudo ASN.1 header 🍓
John Linn wrote the original Kerberos Version 5 mechanism specification [RFC1964], and some of that text has been kept here 🌟
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.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.eduFull Copyright Statement ⚖️
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions in BCP 78, and except as set forth there, the authors keep all their rights 💜
The document and the information in it are provided "AS IS". 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. That includes, but isn't limited to, any warranty that using the information won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose 🙈
Intellectual Property 🧠
The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to implementing or using the technology described in this document, or on whether any license under such rights might or might not be available. It also doesn't say it has made any independent effort to find such rights. Info on the procedures for rights in RFC documents is 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 to get a general license or permission to use such proprietary rights by implementers or users of this specification, can be found in the IETF online 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 required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 📬
Acknowledgement 🌷
Funding for the RFC Editor function is currently provided by the Internet Society. 💖
📦 where this page comes from
- ietf: rfc4121 2005-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms