RFC 1964
The Kerberos Version 5 GSS-API Mechanism
RFC 1964: The Kerberos Version 5 GSS-API Mechanism 🎀
okay bestie, this is RFC 1964 and it's giving standards-track energy 💅 It's from the Network Working Group and filed as Request for Comments: 1964. The author is J. Linn of OpenVision Technologies, the category is Standards Track, and the date is June 1996 ✨
Status of this Memo 📜
okay so this doc specifies an Internet standards track protocol for the whole Internet community 🌐 and it literally asks for discussion and suggestions for improvements 💜 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 And distribution of this memo is unlimited, so share away 🦋
ABSTRACT 🌸
this spec is all about the protocols, procedures, and conventions that peers use when they implement the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) with Kerberos Version 5 tech (as specified in RFC 1510) 🔥
ACKNOWLEDGMENTS 🫶
a huge shoutout is owed here 💖 Much of the material in this memo comes from working documents drafted by John Wray of Digital Equipment Corporation, plus discussions, implementation work, and interoperability testing involving Marc Horowitz, Ted Ts'o, and John Wray. Each of these people gets major credit for helping build and share GSS-API support inside the Kerberos Version 5 code base 👑
1. Token Formats ✨
this section is the protocol-visible side of the GSS-API mechanism that sits on top of Kerberos V5 security tech, per RFC-1508 and RFC-1510 🎀 It defines the protocol elements needed for interoperability, and it's independent of language bindings per RFC-1509 💅
the tokens passed between GSS-API peers (for security context management and per-message protection) are defined here 🦋 The data elements exchanged between a GSS-API endpoint and the Kerberos KDC aren't specific to GSS-API, so they live in RFC-1510 instead of this spec 🧚
to support ongoing experimentation, testing, and evolution of the spec, the Kerberos V5 GSS-API mechanism (in this memo and any successor memos) is identified with the following Object Identifier, as defined in RFC-1510, until the spec is advanced to the level of Proposed Standard RFC 🌈
{iso(1), org(3), dod(5), internet(1), security(5), kerberosv5(2)}once it's advanced to Proposed Standard RFC, the Kerberos V5 GSS-API mechanism gets identified by an Object Identifier with this value 👑
{iso(1) member-body(2) United States(840) mit(113554) infosys(1)
gssapi(2) krb5(2)}1.1. Context Establishment Tokens 🫧
per RFC-1508, Appendix B, the initial context establishment token is enclosed in framing like this 🎀
InitialContextToken ::=
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType
-- MechType is OBJECT IDENTIFIER
-- representing "Kerberos V5"
innerContextToken ANY DEFINED BY thisMech
-- contents mechanism-specific;
-- ASN.1 usage within innerContextToken
-- is not required
}the innerContextToken of the initial context token consists of a Kerberos V5 KRB_AP_REQ message, preceded by a two-byte token-id (TOK_ID) field, which shall contain the value 01 00 💖
this GSS-API framing shall be applied to all tokens emitted by the Kerberos V5 GSS-API mechanism, including KRB_AP_REP, KRB_ERROR, context-deletion, and per-message tokens, not just the initial token in a context establishment sequence 🔥 It's not required by RFC-1508, but it enables implementations to do enhanced error-checking 🙈 So the innerContextToken field of context establishment tokens for the Kerberos V5 GSS-API mechanism will hold a Kerberos message (KRB_AP_REQ, KRB_AP_REP or KRB_ERROR), preceded by a 2-byte TOK_ID field. That field holds 01 00 for KRB_AP_REQ messages, 02 00 for KRB_AP_REP messages, and 03 00 for KRB_ERROR messages 🧚
1.1.1. Initial Token 🌸
the relevant KRB_AP_REQ syntax (from RFC-1510) looks like this 💜
AP-REQ ::= [APPLICATION 14] SEQUENCE {
pvno [0] INTEGER, -- indicates Version 5
msg-type [1] INTEGER, -- indicates KRB_AP_REQ
ap-options[2] APOptions,
ticket[3] Ticket,
authenticator[4] EncryptedData
}
APOptions ::= BIT STRING {
reserved (0),
use-session-key (1),
mutual-required (2)
}
Ticket ::= [APPLICATION 1] SEQUENCE {
tkt-vno [0] INTEGER, -- indicates Version 5
realm [1] Realm,
sname [2] PrincipalName,
enc-part [3] EncryptedData
}
-- Encrypted part of ticket
EncTicketPart ::= [APPLICATION 3] SEQUENCE {
flags[0] TicketFlags,
key[1] EncryptionKey,
crealm[2] Realm,
cname[3] PrincipalName,
transited[4] TransitedEncoding,
authtime[5] KerberosTime,
starttime[6] KerberosTime OPTIONAL,
endtime[7] KerberosTime,
renew-till[8] KerberosTime OPTIONAL,
caddr[9] HostAddresses OPTIONAL,
authorization-data[10] AuthorizationData OPTIONAL
}
-- Unencrypted authenticator
Authenticator ::= [APPLICATION 2] SEQUENCE {
authenticator-vno[0] INTEGER,
crealm[1] Realm,
cname[2] PrincipalName,
cksum[3] Checksum OPTIONAL,
cusec[4] INTEGER,
ctime[5] KerberosTime,
subkey[6] EncryptionKey OPTIONAL,
seq-number[7] INTEGER OPTIONAL,
authorization-data[8] AuthorizationData OPTIONAL
}for this spec, the authenticator shall include the optional sequence number 🦋 The checksum field shall be used to convey channel binding, service flags, and optional delegation information 💅 The checksum has a type of 0x8003 (a value registered within the Kerberos protocol spec), and its value field is at least 24 bytes long 🎀 The value field gets longer than 24 bytes if and only if an optional facility for carrying a Kerberos-defined KRB_CRED message for delegation is supported by an implementation and active on a context 👑 When delegation is active, a TGT with its FORWARDABLE flag set gets transferred inside the KRB_CRED message 🌈
the checksum value field's format goes like this 🫶
Byte Name Description
0..3 Lgth Number of bytes in Bnd field;
Currently contains hex 10 00 00 00
(16, represented in little-endian form)
4..19 Bnd 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.
20..23 Flags Bit vector of context-establishment flags,
with values consistent with RFC-1509, p. 41:
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
The resulting bit vector is encoded into bytes 20..23
in little-endian form.
24..25 DlgOpt The Delegation Option identifier (=1) [optional]
26..27 Dlgth The length of the Deleg field. [optional]
28..n Deleg A KRB_CRED message (n = Dlgth + 29) [optional]when working out the contents of the "Bnd" field, these detailed points apply 🧠
(1) each integer field gets formatted into four bytes, using little-endian byte ordering, for the MD5 hash computation 💖
(2) all input length fields within gss_buffer_desc elements of a gss_channel_bindings_struct shall be included in the hash calculation, even the zero-valued ones 🙈 The value elements of gss_buffer_desc elements shall be dereferenced, and their resulting data shall be included in the hash computation, but only for gss_buffer_desc elements that have non-zero length specifiers 🔥
(3) if the caller passes the value GSS_C_NO_BINDINGS instead of a valid channel bindings structure, the Bnd field shall be set to 16 zero-valued bytes 🌸
in the initial Kerberos V5 GSS-API mechanism token (the KRB_AP_REQ token) going from initiator to target, the GSS_C_DELEG_FLAG, GSS_C_MUTUAL_FLAG, GSS_C_REPLAY_FLAG, and GSS_C_SEQUENCE_FLAG values shall each be set as the logical AND of two things. The first is the initiator's corresponding request flag to GSS_Init_sec_context(). The second is a Boolean indicator of whether that optional service is available to GSS_Init_sec_context()'s caller 💅 GSS_C_CONF_FLAG and GSS_C_INTEG_FLAG don't have a matching context-level input indicator flag to GSS_Init_sec_context(), so each one shall be set to indicate whether its per-message protection service is available for use on the context being established ✨
when a caller provides input source address channel binding values (meaning the input argument isn't GSS_C_NO_BINDINGS, or the source address specifier value in the input structure isn't GSS_C_NULL_ADDRTYPE), and the token received from the context's peer has address restrictions, it is recommended that a Kerberos V5 GSS-API mechanism implementation check that the caller's source address matches the one in the received token 🎀 If a mismatch is detected, it should return the GSS_S_BAD_BINDINGS major_status value 🥺
Note: discussion is ongoing about the strength of recommendation to be made in this area, and on the circumstances under which such a recommendation should be applicable. Implementors are therefore advised that changes on this matter may be included in subsequent versions of this specification. 🙈
to be continued in part 2 🦋
1.1.2. Response Tokens 💖
Okay so a Kerberos V5 context establishment sequence does one-way authentication 🫠 (no confirmation, and no return token from target to initiator answering the initiator's KRB_AP_REQ) if the mutual_req bit is not set in the app's call to GSS_Init_sec_context().
If you need proof that your authentication actually worked, you should request mutual authentication 🫶 That gives you a "mutual-required" indication inside KRB_AP_REQ APoptions and sets the mutual_req bit in the flags field of the authenticator checksum. Then the context target replies with a token holding either a KRB_AP_REP or a KRB_ERROR, and that completes the mutual context establishment exchange ✨
Here's the KRB_AP_REP syntax you need to know 📜
AP-REP ::= [APPLICATION 15] SEQUENCE {
pvno [0] INTEGER, -- represents Kerberos V5
msg-type [1] INTEGER, -- represents KRB_AP_REP
enc-part [2] EncryptedData
}
EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
ctime [0] KerberosTime,
cusec [1] INTEGER,
subkey [2] EncryptionKey OPTIONAL,
seq-number [3] INTEGER OPTIONAL
}The optional seq-number element within the AP-REP's EncAPRepPart shall be included. No skipping it, bestie 🔥
And here's the KRB_ERROR syntax 🙈
KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
ctime[2] KerberosTime OPTIONAL,
cusec[3] INTEGER OPTIONAL,
stime[4] KerberosTime,
susec[5] INTEGER,
error-code[6] INTEGER,
crealm[7] Realm OPTIONAL,
cname[8] PrincipalName OPTIONAL,
realm[9] Realm, -- Correct realm
sname[10] PrincipalName, -- Correct name
e-text[11] GeneralString OPTIONAL,
e-data[12] OCTET STRING OPTIONAL
}The values that go in the error-code field of a KRB-ERROR message are defined in [RFC-1510], not in this specification. So the error codes live over there 📚
1.2. Per-Message and Context Deletion Tokens 🎀
There are three classes of tokens in this section, bestie 🦋 First, "MIC" tokens, emitted by GSS_GetMIC() (formerly GSS_Sign()) and consumed by GSS_VerifyMIC() (formerly GSS_Verify()). Second, "Wrap" tokens, emitted by GSS_Wrap() (formerly GSS_Seal()) and consumed by GSS_Unwrap() (formerly GSS_Unseal()). Third, context deletion tokens, emitted by GSS_Delete_sec_context() and consumed by GSS_Process_context_token().
Also, whenever the rest of this spec talks about GSS-API per-message routines, it's using their newer recommended names instead of the old ones 💅
Several variants of cryptographic keys get used when generating and processing per-message tokens:
- context key: uses Kerberos session key (or subkey, if present in authenticator emitted by context initiator) directly
- confidentiality key: forms variant of context key by exclusive-OR with the hexadecimal constant
f0f0f0f0f0f0f0f0. - MD2.5 seed key: forms variant of context key by reversing the bytes of the context key (i.e. if the original key is the 8-byte sequence
{aa, bb, cc, dd, ee, ff, gg, hh}, the seed key will be{hh, gg, ff, ee, dd, cc, bb, aa}).
1.2.1. Per-message Tokens - MIC 🌸
Using GSS_GetMIC() gives you a token that's separate from the user data being protected. You can use that token to verify the integrity of the data as it's received. The token has this format:
Byte no Name Description
0..1 TOK_ID Identification field.
Tokens emitted by GSS_GetMIC() contain
the hex value 01 01 in this field.
2..3 SGN_ALG Integrity algorithm indicator.
00 00 - DES MAC MD5
01 00 - MD2.5
02 00 - DES MAC
4..7 Filler Contains ff ff ff ff
8..15 SND_SEQ Sequence number field.
16..23 SGN_CKSUM Checksum of "to-be-signed data",
calculated according to algorithm
specified in SGN_ALG field.GSS-API tokens must be encapsulated within the higher-level protocol by the application; no embedded length field is necessary. ✨
1.2.1.1. Checksum 🧮
Here's the checksum calculation procedure, which is common to all algorithms: checksums are calculated over the data field, logically prepended by the first 8 bytes of the plaintext packet header. The resulting value binds the data to the packet type and signature algorithm identifier fields 🔗
DES MAC MD5 algorithm: the checksum is formed by computing an MD5 [RFC-1321] hash over the plaintext data, and then computing a DES-CBC MAC on the 16-byte MD5 result. A standard 64-bit DES-CBC MAC is computed per [FIPS-PUB-113], employing the context key and a zero IV. The 8-byte result is stored in the SGN_CKSUM field.
MD2.5 algorithm: the checksum is formed by first DES-CBC encrypting a 16-byte zero-block, using a zero IV and a key formed by reversing the bytes of the context key (i.e. if the original key is the 8-byte sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the checksum key will be {hh, gg, ff, ee, dd, cc, bb, aa}). The resulting 16-byte value is logically prepended to the to-be-signed data. A standard MD5 checksum is calculated over the combined data, and the first 8 bytes of the result are stored in the SGN_CKSUM field.
Note 1: we refer to this algorithm informally as "MD2.5" to connote the fact that it uses half of the 128 bits generated by MD5. Using only a subset of the MD5 bits is intended to protect against the prospect that data could be postfixed to an existing message with corresponding modifications being made to the checksum.
Note 2: This algorithm is fairly novel and has received more limited evaluation than that to which other integrity algorithms have been subjected. An initial, limited evaluation indicates that it may be significantly weaker than DES MAC MD5. 🙈
DES-MAC algorithm: a standard 64-bit DES-CBC MAC is computed on the plaintext data per [FIPS-PUB-113], employing the context key and a zero IV. Padding procedures to accommodate plaintext data lengths which may not be integral multiples of 8 bytes are defined in [FIPS-PUB-113]. The result is an 8-byte value, which is stored in the SGN_CKSUM field. Support for this algorithm may not be present in all implementations.
1.2.1.2. Sequence Number 🔢
The 8-byte plaintext sequence number field is built from the sender's four-byte sequence number. If the four bytes of the sender's sequence number are named s0, s1, s2 and s3 (from least to most significant), the plaintext sequence number field is the 8-byte sequence (s0, s1, s2, s3, di, di, di, di). Here, di is the direction-indicator (Hex 0 means the sender is the context initiator, Hex FF means the sender is the context acceptor). The field is then DES-CBC encrypted using the context key and an IV formed from the first 8 bytes of the previously calculated SGN_CKSUM field. After sending a GSS_GetMIC() or GSS_Wrap() token, the sender's sequence number is incremented by one.
When a token shows up, the receiver first verifies the SGN_CKSUM field. If that's valid, the sequence number field may be decrypted and compared to the expected sequence number. The repetition of the (effectively 1-bit) direction indicator within the sequence number field gives the receiver redundancy, so it can verify that the decryption succeeded 🕵️♀️
Since the checksum computation is used as an IV to the sequence number decryption, attempts to splice a checksum and sequence number from different messages will be detected. The direction indicator will detect packets that have been maliciously reflected. Iconic behaviour from the security team 👑
The sequence number is the basis for detecting replayed tokens. Replay detection can be performed using state information retained on received sequence numbers, interpreted in conjunction with the security context on which they arrive.
Providing per-message replay and out-of-sequence detection services is optional for implementations of the Kerberos V5 GSS-API mechanism. Further, it is recommended that implementations of the Kerberos V5 GSS-API mechanism which offer these services should honor a caller's request that the services be disabled on a context. Specifically, if replay_det_req_flag is input FALSE, replay_det_state should be returned FALSE, and the GSS_DUPLICATE_TOKEN and GSS_OLD_TOKEN stati should not be indicated as a result of duplicate detection when tokens are processed. If sequence_req_flag is input FALSE, sequence_state should be returned FALSE, and GSS_DUPLICATE_TOKEN, GSS_OLD_TOKEN, and GSS_UNSEQ_TOKEN stati should not be indicated as a result of out-of-sequence detection when tokens are processed 🎀
1.2.2. Per-message Tokens - Wrap 🎁
Using GSS_Wrap() gives you a token that wraps the input user data, optionally encrypted, along with associated integrity check quantities. The token emitted by GSS_Wrap() has an integrity header whose format is identical to the one emitted by GSS_GetMIC(), except that the TOK_ID field contains the value 02 01. After that comes a body portion, which holds either the plaintext data (if SEAL_ALG = ff ff) or encrypted data for any other supported value of SEAL_ALG. Right now, only SEAL_ALG = 00 00 is supported, and it means DES-CBC encryption is used to protect the data 🔐
The GSS_Wrap() token has this format:
Byte no Name Description
0..1 TOK_ID Identification field.
Tokens emitted by GSS_Wrap() contain
the hex value 02 01 in this field.
2..3 SGN_ALG Checksum algorithm indicator.
00 00 - DES MAC MD5
01 00 - MD2.5
02 00 - DES MAC
4..5 SEAL_ALG ff ff - none
00 00 - DES
6..7 Filler Contains ff ff
8..15 SND_SEQ Encrypted sequence number field.
16..23 SGN_CKSUM Checksum of plaintext padded data,
calculated according to algorithm
specified in SGN_ALG field.
24..last Data encrypted or plaintext padded dataGSS-API tokens must be encapsulated within the higher-level protocol by the application; no embedded length field is necessary. 💖
1.2.2.1. Checksum 💖
Okay, so the checksum procedure is the same for every algorithm 🧚. You calculate it over the plaintext padded data field, with the first 8 bytes of the plaintext packet header logically stuck on the front. The resulting signature binds your data to the packet type, protocol version, and signature algorithm identifier fields. That's main character binding energy 🔗✨
DES MAC MD5 algorithm 💅: First you MD5 hash the plaintext padded data, then you run a DES-CBC MAC over that 16-byte MD5 result. The MAC is a standard 64-bit DES-CBC MAC per [FIPS-PUB-113], using the context key and a zero IV. The 8-byte result goes into the SGN_CKSUM field.
MD2.5 algorithm 🌈: This one is a whole puzzle, bestie. First you DES-CBC encrypt a 16-byte zero-block, using a zero IV and a key made by reversing the bytes of the context key. For example, if the original key is the 8-byte sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the checksum key will be {hh, gg, ff, ee, dd, cc, bb, aa}. The resulting 16-byte value gets logically pre-pended to the "to-be-signed data". Then a standard MD5 checksum is calculated over the combined data, and the first 8 bytes of that result are stored in the SGN_CKSUM field 🫶
DES-MAC algorithm 🔥: A standard 64-bit DES-CBC MAC is computed on the plaintext padded data per [FIPS-PUB-113], using the context key and a zero IV. The plaintext padded data is already guaranteed to be an integral multiple of 8 bytes, so no additional padding is required or applied for the MAC calculation. The result is an 8-byte value, stored in the SGN_CKSUM field.
Heads up, bestie: support for this algorithm may not be present in all implementations 🙈
1.2.2.2. Sequence Number 🦋
The 8-byte plaintext sequence number field is built from the sender's four-byte sequence number. Name the four bytes s0, s1, s2 and s3 from least to most significant. The plaintext sequence number field is then the 8-byte sequence (s0, s1, s2, s3, di, di, di, di), where di is the direction-indicator. Hex 0 means the sender is the context initiator, and Hex FF means the sender is the context acceptor 🎀
Then the field gets DES-CBC encrypted, using the context key and an IV formed from the first 8 bytes of the SEAL_CKSUM field 🔐
After sending a GSS_GetMIC() or GSS_Wrap() token, the sender's sequence numbers go up by one ✨
1.2.2.3. Padding 🎀
Before encryption and/or signature calculation, the plaintext data gets padded up to the next highest multiple of 8 bytes. You append between 1 and 8 bytes, and the value of each byte is the total number of pad bytes. For example, 20 bytes of data gets four pad bytes, and each one contains the hex value 04 💖 An 8-byte random confounder is prepended to the data, and signatures are calculated over the resulting padded plaintext.
After padding, the data is encrypted according to the algorithm specified in the SEAL_ALG field. For SEAL_ALG=DES (the only non-null algorithm currently supported 👑), the data is encrypted using DES-CBC, with an IV of zero. The key is derived from the established context key by XOR-ing the context key with the hexadecimal constant f0f0f0f0f0f0f0f0 🌸
1.2.3. Context deletion token 🧚
The token emitted by GSS_Delete_sec_context() is based on the packet format for tokens emitted by GSS_GetMIC(). The context-deletion token has the following format, and it's giving clean table energy 📋
Byte no Name Description
0..1 TOK_ID Identification field.
Tokens emitted by
GSS_Delete_sec_context() contain
the hex value 01 02 in this field.
2..3 SGN_ALG Integrity algorithm indicator.
00 00 - DES MAC MD5
01 00 - MD2.5
02 00 - DES MAC
4..7 Filler Contains ff ff ff ff
8..15 SND_SEQ Sequence number field.
16..23 SGN_CKSUM Checksum of "to-be-signed data",
calculated according to algorithm
specified in SGN_ALG field.SGN_ALG and SND_SEQ get calculated just like they do for tokens emitted by GSS_GetMIC(). The SGN_CKSUM also gets calculated like it does for GSS_GetMIC() tokens, except that the user-data component of the "to-be-signed" data is a zero-length string 🙈
2. Name Types and Object Identifiers ✨
This section talks about the name types that can be passed as input to the Kerberos V5 GSS-API mechanism's GSS_Import_name() call, along with their associated identifier values. It defines interface elements to support portability, and it assumes C language bindings per RFC-1509. Along with OID values for the name type identifiers, it includes symbolic names, which are recommended to GSS-API implementors to make life easier for callers 💅 Not every Kerberos V5 GSS-API implementation has to support every name type in this list, and more name forms will likely get added over time. The definitions of some or all name types may also migrate later to other, mechanism-independent specifications. A name type showing up here is specifically not meant to suggest it can only be supported by the Kerberos V5 mechanism. The _KRB5_ string in the symbolic names is just a way to register them unambiguously and avoid collisions with other documents. It is not meant to limit the name types' usage or applicability 🌈
For clarification to GSS-API implementors, this section's discussion of some name forms describes ways those forms can be supported with existing Kerberos technology. These discussions are not meant to rule out alternative implementation strategies, whether inside Kerberos mechanisms or mechanisms based on other technologies. To enhance application portability, mechanism implementors are encouraged to support the name forms defined in this section, even if their mechanisms are independent of Kerberos V5 🫶
2.1. Mandatory Name Forms 🔥
These are the name forms that are to be supported by all conformant implementations of the Kerberos V5 GSS-API mechanism. No skipping, periodt 💅
2.1.1. Kerberos Principal Name Form 👑
This name form shall be represented by the Object Identifier {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) krb5(2) krb5_name(1)}. The recommended symbolic name for this type is GSS_KRB5_NT_PRINCIPAL_NAME.
This name type corresponds to the single-string representation of a Kerberos name. (Within the MIT Kerberos V5 implementation, such names are parseable with the krb5_parse_name() function.) The elements in this name representation go as follows, starting from the beginning of the string:
- (1) One or more principal name components. If more than one principal name component is included, the components are separated by
/. Arbitrary octets may be included within principal name components, with the following constraints and special considerations:- (1a) Any occurrence of the characters
@or/within a name component must be immediately preceded by the\quoting character, to prevent interpretation as a component or realm separator. - (1b) The ASCII newline, tab, backspace, and null characters may occur directly within the component, or may be represented, respectively, by
\n,\t,\b, or\0. - (1c) If the
\quoting character occurs outside the contexts described in (1a) and (1b) above, the following character is interpreted literally. As a special case, this allows the doubled representation\\to represent a single occurrence of the quoting character. - (1d) An occurrence of the
\quoting character as the last character of a component is illegal.
- (1a) Any occurrence of the characters
- (2) Optionally, a
@character, signifying that a realm name immediately follows. If no realm name element is included, the local realm name is assumed. The/,:, and null characters may not occur within a realm name. The@, newline, tab, and backspace characters may be included using the quoting conventions described in (1a), (1b), and (1c) above.
2.1.2. Host-Based Service Name Form 🦋
This name form has been incorporated at the mechanism-independent GSS-API level as of GSS-API, Version 2. This subsection keeps the Object Identifier and symbolic name assignments that were previously made at the Kerberos V5 GSS-API mechanism level, and adopts the definition as it was promoted to the mechanism-independent level 💜
This name form shall be represented by the Object Identifier {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) generic(1) service_name(4)}. The previously recommended symbolic name for this type is GSS_KRB5_NT_HOSTBASED_SERVICE_NAME. The currently preferred symbolic name for this type is GSS_C_NT_HOSTBASED_SERVICE.
This name type is used to represent services associated with host computers. The name form is constructed from two elements, "service" and "hostname", like this:
service@hostnameWhen a reference to a name of this type is resolved, the "hostname" is canonicalized by attempting a DNS lookup and using the fully-qualified domain name that is returned, or by using the "hostname" as provided if the DNS lookup fails. The canonicalization operation also maps the host's name into lower-case characters ✨
The "hostname" element may be omitted. If no "@" separator is included, the entire name is interpreted as the service specifier, with the "hostname" defaulting to the canonicalized name of the local host 🌸
Values for the "service" element will be registered with the IANA.
2.1.3. Exported Name Object Form for Kerberos V5 Mechanism ✨
Support for this name form is not REQUIRED for GSS-V1 implementations, but it will be REQUIRED for use with the GSS_Export_name() call planned for GSS-API Version 2. Use of this name form will be signified by a "GSS-API Exported Name Object" OID value, which will be defined at the mechanism-independent level for GSS-API Version 2. 💖
This name type represents a self-describing object, and its framing structure will be defined at the mechanism-independent level for GSS-API Version 2. 🦋 When the Kerberos V5 mechanism generates it, the Mechanism OID within the exportable name SHALL be that of the Kerberos V5 mechanism. The name component within the exportable name SHALL be a contiguous string with the structure defined for the Kerberos Principal Name Form. 🎀
To get a distinguished encoding for comparison purposes, the following extra constraints are placed on the export operation: 🔍
(1) all occurrences of the characters @, /, and \ within principal components or realm names SHALL be quoted with an immediately-preceding \.
(2) all occurrences of the null, backspace, tab, or newline characters within principal components or realm names will be represented, respectively, with \0, \b, \t, or \n.
(3) the \ quoting character SHALL NOT be emitted within an exported name except to accommodate cases (1) and (2). 🙅♀️
2.2. Optional Name Forms 🎀
This section discusses additional name forms that implementations of the Kerberos V5 GSS-API mechanism MAY optionally support. 🌸 It's giving "nice to know, not required" energy. Some of these forms come from UNIX(tm) operating system platforms, so some listed forms MAY be irrelevant to non-UNIX platforms, and defining extra forms for those platforms MAY also be appropriate. 🧚 It's also recognized that OS-specific functions outside GSS-API are likely to exist to translate among these forms, and that GSS-API implementations supporting these forms MAY themselves be layered on top of those OS-specific functions. Including this support inside GSS-API implementations is intended as a convenience for applications. 💅
2.2.1. User Name Form 🫶
This name form SHALL be represented by the Object Identifier {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) generic(1) user_name(1)}. The RECOMMENDED symbolic name for this type is GSS_KRB5_NT_USER_NAME.
This name type is used to indicate a named user on a local system. 🧸
Its interpretation is OS-specific. This name form is constructed as:
usernameAssuming that users' principal names are the same as their local operating system names, an implementation of GSS_Import_name() based on Kerberos V5 technology can process names of this form by appending an "@" sign and the name of the local realm. ✨
2.2.2. Machine UID Form 🔢
This name form SHALL be represented by the Object Identifier {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) generic(1) machine_uid_name(2)}. The RECOMMENDED symbolic name for this type is GSS_KRB5_NT_MACHINE_UID_NAME.
This name type is used to indicate a numeric user identifier corresponding to a user on a local system. Its interpretation is OS-specific. The gss_buffer_desc representing a name of this type SHOULD contain a locally-significant uid_t, represented in host byte order. The GSS_Import_name() operation resolves this uid into a username, which is then treated as the User Name Form. 🌈
2.2.3. String UID Form 🍓
This name form SHALL be represented by the Object Identifier {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) generic(1) string_uid_name(3)}. The RECOMMENDED symbolic name for this type is GSS_KRB5_NT_STRING_UID_NAME.
This name type is used to indicate a string of digits representing the numeric user identifier of a user on a local system. Its interpretation is OS-specific. It's pretty similar to the Machine UID Form, except that the buffer holds a string representing the uid_t. 💜
3. Credentials Management 🔑
The Kerberos V5 protocol uses different credentials (in the GSSAPI sense) for initiating and accepting security contexts. 🗝️ Normal clients receive a ticket-granting ticket (TGT) and an associated session key at "login" time, and that pair of a TGT and its session key forms a credential that is suitable for initiating security contexts. A ticket-granting ticket, its session key, and any other (ticket, key) pairs obtained through use of the ticket-granting-ticket are typically stored in a Kerberos V5 credentials cache, sometimes known as a ticket file. 🎟️
The encryption key the Kerberos server uses to seal tickets for a particular application service forms the credentials suitable for accepting security contexts. 🔐 These service keys are typically stored in a Kerberos V5 key table, or srvtab file. Besides their use as accepting credentials, these service keys MAY also be used to obtain initiating credentials for their service principal. 👑
The Kerberos V5 mechanism's credential handle MAY contain references to either or both types of credentials. It's a local matter how the Kerberos V5 mechanism implementation finds the right Kerberos V5 credentials cache or key table. 🧁
However, when the Kerberos V5 mechanism tries to obtain initiating credentials for a service principal that aren't available in a credentials cache, and the key for that service principal is available in a Kerberos V5 key table, the mechanism SHOULD use the service key to obtain initiating credentials for that service. 😭 This SHOULD be accomplished by requesting a ticket-granting-ticket from the Kerberos Key Distribution Center (KDC), and decrypting the KDC's reply using the service key. 🦋
4. Parameter Definitions 🧁
This section defines parameter values used by the Kerberos V5 GSS-API mechanism. ✨ It defines interface elements to support portability, and it assumes use of C language bindings per RFC-1509. 💅
4.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 implementors to make applications more portable across different implementations of the mechanism defined in this specification. (In all cases, implementations of GSS_Display_status() will let callers convert minor_status indicators to text representations.) Each implementation SHOULD make available, through include files or other means, a way 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. 🧩
It's recognized that this list MAY grow over time, and that the need for additional minor_status codes specific to particular implementations MAY arise. 🌱 It is RECOMMENDED, however, that implementations SHOULD return a minor_status value defined on a mechanism-wide basis within this section when that code accurately represents the reportable status, rather than using a separate, implementation-defined code. 🫶
4.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" */4.1.2. Kerberos-specific-codes 🌸
GSS_KRB5_S_KG_CCACHE_NOMATCH
/* "Principal in credential cache does not match desired name" */
GSS_KRB5_S_KG_KEYTAB_NOMATCH
/* "No principal in keytab matches desired name" */
GSS_KRB5_S_KG_TGT_MISSING
/* "Credential cache has no TGT" */
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" */4.2. Quality of Protection Values 🛡️
This section defines Quality of Protection (QOP) values for use with the Kerberos V5 GSS-API mechanism. You pass them as input to GSS_Wrap() and GSS_GetMIC() routines to pick between alternate integrity and confidentiality algorithms. 🔍 Additional QOP values MAY be added in future versions of this specification. The bit positions are non-overlapping, now and in the future, so that both integrity and confidentiality QOP MAY be selected within a single parameter, via inclusive-OR of the specified integrity and confidentiality values. 💖
4.2.1. Integrity Algorithms 🦋
The following Quality of Protection (QOP) values are currently defined for the Kerberos V5 GSS-API mechanism, and they're used to pick among alternate integrity checking algorithms. 🧠
GSS_KRB5_INTEG_C_QOP_MD5 (numeric value: 1)
/* Integrity using partial MD5 ("MD2.5") of plaintext */
GSS_KRB5_INTEG_C_QOP_DES_MD5 (numeric value: 2)
/* Integrity using DES MAC of MD5 of plaintext */
GSS_KRB5_INTEG_C_QOP_DES_MAC (numeric value: 3)
/* Integrity using DES MAC of plaintext */4.2.2. Confidentiality Algorithms 🔐
Only one confidentiality QOP value is currently defined for the Kerberos V5 GSS-API mechanism:
GSS_KRB5_CONF_C_QOP_DES (numeric value: 0)
/* Confidentiality with DES */Note: confidentiality QOP SHOULD be indicated only by GSS-API calls capable of providing confidentiality services. If non-zero confidentiality QOP values are defined in future to represent different algorithms, the bit positions containing those values SHOULD be cleared before being returned by implementations ofGSS_GetMIC()andGSS_VerifyMIC(). ⚠️
4.3. Buffer Sizes 📦
All implementations of this specification SHALL be capable of accepting buffers of at least 16 Kbytes as input to GSS_GetMIC(), GSS_VerifyMIC(), and GSS_Wrap(), and SHALL be capable of accepting the output_token generated by GSS_Wrap() for a 16 Kbyte input buffer as input to GSS_Unwrap(). Support for larger buffer sizes is OPTIONAL but RECOMMENDED. 🌈
5. Security Considerations 🔐
Security issues? 😭 They're discussed throughout this memo, bestie, so keep them in mind everywhere. 💀
6. References 📚
[RFC-1321]: Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. 🧾
[RFC-1508]: Linn, J., "Generic Security Service Application Program Interface", RFC 1508, September 1993. 🎀
[RFC-1509]: Wray, J., "Generic Security Service Application Program Interface: C-bindings", RFC 1509, September 1993. 🦋
[RFC-1510]: Kohl, J., and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. 🔑
[FIPS-PUB-113]: National Bureau of Standards, Federal Information Processing Standard 113, "Computer Data Authentication", May 1985. 💜
Author's Address 💌
okay so this is where John tells you how to reach him, bestie 🧚
John Linn
OpenVision Technologies
One Main St.
Cambridge, MA 02142 USA
Phone: +1 617.374.2245
EMail: John.Linn@ov.com📦 where this page comes from
- ietf: rfc1964 1996-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms