diff options
Diffstat (limited to 'crypto/heimdal/doc/standardisation/rfc1964.txt')
| -rw-r--r-- | crypto/heimdal/doc/standardisation/rfc1964.txt | 1123 |
1 files changed, 0 insertions, 1123 deletions
diff --git a/crypto/heimdal/doc/standardisation/rfc1964.txt b/crypto/heimdal/doc/standardisation/rfc1964.txt deleted file mode 100644 index f2960b9..0000000 --- a/crypto/heimdal/doc/standardisation/rfc1964.txt +++ /dev/null @@ -1,1123 +0,0 @@ - - - - - - -Network Working Group J. Linn -Request for Comments: 1964 OpenVision Technologies -Category: Standards Track June 1996 - - - The Kerberos Version 5 GSS-API Mechanism - -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. - -ABSTRACT - - This specification defines protocols, procedures, and conventions to - be employed by peers implementing the Generic Security Service - Application Program Interface (as specified in RFCs 1508 and 1509) - when using Kerberos Version 5 technology (as specified in RFC 1510). - -ACKNOWLEDGMENTS - - Much of the material in this memo is based on working documents - drafted by John Wray of Digital Equipment Corporation and on - discussions, implementation activities, and interoperability testing - involving Marc Horowitz, Ted Ts'o, and John Wray. Particular thanks - are due to each of these individuals for their contributions towards - development and availability of GSS-API support within the Kerberos - Version 5 code base. - -1. Token Formats - - This section discusses protocol-visible characteristics of the GSS- - API mechanism to be implemented atop Kerberos V5 security technology - per RFC-1508 and RFC-1510; it defines elements of protocol for - interoperability and is independent of language bindings per RFC- - 1509. - - Tokens transferred between GSS-API peers (for security context - management and per-message protection purposes) are defined. The - data elements exchanged between a GSS-API endpoint implementation and - the Kerberos KDC are not specific to GSS-API usage and are therefore - defined within RFC-1510 rather than within this specification. - - - - - - -Linn Standards Track [Page 1] - -RFC 1964 Kerberos Version 5 GSS-API June 1996 - - - To support ongoing experimentation, testing, and evolution of the - specification, the Kerberos V5 GSS-API mechanism as defined in this - and any successor memos will be identified with the following Object - Identifier, as defined in RFC-1510, until the specification is - advanced to the level of Proposed Standard RFC: - - {iso(1), org(3), dod(5), internet(1), security(5), kerberosv5(2)} - - Upon advancement to the level of Proposed Standard RFC, the Kerberos - V5 GSS-API mechanism will be identified by an Object Identifier - having the 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 - will be enclosed within framing as follows: - - 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 will consist 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. - - The above 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 to the initial - token in a context establishment sequence. While not required by - RFC-1508, this enables implementations to perform enhanced error- - checking. The innerContextToken field of context establishment tokens - for the Kerberos V5 GSS-API mechanism will contain a Kerberos message - (KRB_AP_REQ, KRB_AP_REP or KRB_ERROR), preceded by a 2-byte TOK_ID - field containing 01 00 for KRB_AP_REQ messages, 02 00 for KRB_AP_REP - messages and 03 00 for KRB_ERROR messages. - - - - - - -Linn Standards Track [Page 2] - -RFC 1964 Kerberos Version 5 GSS-API June 1996 - - -1.1.1. Initial Token - - Relevant KRB_AP_REQ syntax (from RFC-1510) is as follows: - - 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, - - - -Linn Standards Track [Page 3] - -RFC 1964 Kerberos Version 5 GSS-API June 1996 - - - subkey[6] EncryptionKey OPTIONAL, - seq-number[7] INTEGER OPTIONAL, - authorization-data[8] AuthorizationData OPTIONAL - } - - For purposes of this specification, the authenticator shall include - the optional sequence number, and the checksum field shall be used to - convey channel binding, service flags, and optional delegation - information. The checksum will have a type of 0x8003 (a value being - registered within the Kerberos protocol specification), and a value - field of at least 24 bytes in length. The length of the value field - is extended beyond 24 bytes if and only if an optional facility to - carry a Kerberos-defined KRB_CRED message for delegation purposes is - supported by an implementation and active on a context. When - delegation is active, a TGT with its FORWARDABLE flag set will be - transferred within the KRB_CRED message. - - The checksum value field's format is as follows: - - 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] - - In computing the contents of the "Bnd" field, the following detailed - points apply: - - (1) Each integer field shall be formatted into four bytes, using - little-endian byte ordering, for purposes of MD5 hash - computation. - - - -Linn Standards Track [Page 4] - -RFC 1964 Kerberos Version 5 GSS-API June 1996 - - - (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 bindings structure, the Bnd field shall be set - to 16 zero-valued bytes. - - In the initial Kerberos V5 GSS-API mechanism token (KRB_AP_REQ token) - 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 the initiator's corresponding request flag to - GSS_Init_sec_context() and 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, for which no corresponding - context-level input indicator flags to GSS_Init_sec_context() exist, - shall each be set to indicate whether their respective per-message - protection services are available for use on the context being - established. - - When input source address channel binding values are provided by a - caller (i.e., unless the input argument is GSS_C_NO_BINDINGS or the - source address specifier value within the input structure is - GSS_C_NULL_ADDRTYPE), and the corresponding token received from the - context's peer bears address restrictions, it is recommended that an - implementation of the Kerberos V5 GSS-API mechanism should check that - the source address as provided by the caller matches that in the - received token, and should return the GSS_S_BAD_BINDINGS major_status - value if a mismatch is detected. 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. - -1.1.2. Response Tokens - - A context establishment sequence based on the Kerberos V5 mechanism - will perform one-way authentication (without confirmation or any - return token from target to initiator in response to the initiator's - KRB_AP_REQ) if the mutual_req bit is not set in the application's - call to GSS_Init_sec_context(). Applications requiring confirmation - that their authentication was successful should request mutual - authentication, resulting in a "mutual-required" indication within - KRB_AP_REQ APoptions and the setting of the mutual_req bit in the - - - -Linn Standards Track [Page 5] - -RFC 1964 Kerberos Version 5 GSS-API June 1996 - - - flags field of the authenticator checksum. In response to such a - request, the context target will reply to the initiator with a token - containing either a KRB_AP_REP or KRB_ERROR, completing the mutual - context establishment exchange. - - Relevant KRB_AP_REP syntax is as follows: - - 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. - - The syntax of KRB_ERROR is as follows: - - 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 - } - - Values to be transferred in the error-code field of a KRB-ERROR - message are defined in [RFC-1510], not in this specification. - - - - - - - - -Linn Standards Track [Page 6] - -RFC 1964 Kerberos Version 5 GSS-API June 1996 - - -1.2. Per-Message and Context Deletion Tokens - - Three classes of tokens are defined in this section: "MIC" tokens, - emitted by calls to GSS_GetMIC() (formerly GSS_Sign()) and consumed - by calls to GSS_VerifyMIC() (formerly GSS_Verify()), "Wrap" tokens, - emitted by calls to GSS_Wrap() (formerly GSS_Seal()) and consumed by - calls to GSS_Unwrap() (formerly GSS_Unseal()), and context deletion - tokens, emitted by calls to GSS_Delete_sec_context() and consumed by - calls to GSS_Process_context_token(). Note: References to GSS-API - per-message routines in the remainder of this specification will be - based on those routines' newer recommended names rather than those - names' predecessors. - - Several variants of cryptographic keys are used in generation and - processing of per-message tokens: - - (1) context key: uses Kerberos session key (or subkey, if - present in authenticator emitted by context initiator) directly - - (2) confidentiality key: forms variant of context key by - exclusive-OR with the hexadecimal constant f0f0f0f0f0f0f0f0. - - (3) 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 - -Use of the GSS_GetMIC() call yields a token, 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: - - 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. - - - - - -Linn Standards Track [Page 7] - -RFC 1964 Kerberos Version 5 GSS-API June 1996 - - - 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 - - Checksum calculation procedure (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; use of 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 accomodate 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 - - Sequence number field: The 8 byte plaintext sequence number field is - formed from the sender's four-byte sequence number as follows. If - the four bytes of the sender's sequence number are named s0, s1, s2 - - - -Linn Standards Track [Page 8] - -RFC 1964 Kerberos Version 5 GSS-API June 1996 - - - 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), where 'di' is the direction-indicator (Hex 0 - sender is the - context initiator, Hex FF - 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. - - The receiver of the token will first verify the SGN_CKSUM field. If - 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 provides - redundancy so that the receiver may 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. - - The sequence number provides a basis for detection of 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. - - Provision of 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 - - Use of the GSS_Wrap() call yields a token which encapsulates the - input user data (optionally encrypted) along with associated - integrity check quantities. The token emitted by GSS_Wrap() consists - of an integrity header whose format is identical to that emitted by - GSS_GetMIC() (except that the TOK_ID field contains the value 02 01), - followed by a body portion that contains either the plaintext data - - - -Linn Standards Track [Page 9] - -RFC 1964 Kerberos Version 5 GSS-API June 1996 - - - (if SEAL_ALG = ff ff) or encrypted data for any other supported value - of SEAL_ALG. Currently, only SEAL_ALG = 00 00 is supported, and - means that DES-CBC encryption is being used to protect the data. - - The GSS_Wrap() token has the following 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 data - - GSS-API tokens must be encapsulated within the higher-level protocol - by the application; no embedded length field is necessary. - -1.2.2.1. Checksum - - Checksum calculation procedure (common to all algorithms): Checksums - are calculated over the plaintext padded data field, logically - prepended by the first 8 bytes of the plaintext packet header. The - resulting signature binds the data to the packet type, protocol - version, and signature algorithm identifier fields. - - DES MAC MD5 algorithm: The checksum is formed by computing an MD5 - hash over the plaintext padded 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 pre-pended 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. - - - -Linn Standards Track [Page 10] - -RFC 1964 Kerberos Version 5 GSS-API June 1996 - - - DES-MAC algorithm: A standard 64-bit DES-CBC MAC is computed on the - plaintext padded data per [FIPS-PUB-113], employing the context key - and a zero IV. The plaintext padded data is already assured to be an - integral multiple of 8 bytes; no additional padding is required or - applied in order to accomplish MAC calculation. The result is an 8- - byte value, which is stored in the SGN_CKSUM field. Support for this - lgorithm may not be present in all implementations. - -1.2.2.2. Sequence Number - - Sequence number field: The 8 byte plaintext sequence number field is - formed from the sender's four-byte sequence number as follows. 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), where 'di' is the direction-indicator (Hex 0 - sender is the - context initiator, Hex FF - 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 SEAL_CKSUM field. - - After sending a GSS_GetMIC() or GSS_Wrap() token, the sender's - sequence numbers are incremented by one. - -1.2.2.3. Padding - - Data padding: Before encryption and/or signature calculation, - plaintext data is padded to the next highest multiple of 8 bytes, by - appending between 1 and 8 bytes, the value of each such byte being - the total number of pad bytes. For example, given data of length 20 - bytes, four pad bytes will be appended, and each byte will contain - 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 used 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: - - - - -Linn Standards Track [Page 11] - -RFC 1964 Kerberos Version 5 GSS-API June 1996 - - - 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 will be calculated as for tokens emitted by - GSS_GetMIC(). The SGN_CKSUM will be calculated as for tokens emitted - by GSS_GetMIC(), except that the user-data component of the "to-be- - signed" data will be a zero-length string. - -2. Name Types and Object Identifiers - - This section discusses the name types which may be passed as input to - the Kerberos V5 GSS-API mechanism's GSS_Import_name() call, and their - associated identifier values. It defines interface elements in - support of portability, and assumes use of C language bindings per - RFC-1509. In addition to specifying OID values for name type - identifiers, symbolic names are included and recommended to GSS-API - implementors in the interests of convenience to callers. It is - understood that not all implementations of the Kerberos V5 GSS-API - mechanism need support all name types in this list, and that - additional name forms will likely be added to this list over time. - Further, the definitions of some or all name types may later migrate - to other, mechanism-independent, specifications. The occurrence of a - name type in this specification is specifically not intended to - suggest that the type may be supported only by an implementation of - the Kerberos V5 mechanism. In particular, the occurrence of the - string "_KRB5_" in the symbolic name strings constitutes a means to - unambiguously register the name strings, avoiding collision with - other documents; it is not meant to limit the name types' usage or - applicability. - - For purposes of clarification to GSS-API implementors, this section's - discussion of some name forms describes means through which those - forms can be supported with existing Kerberos technology. These - discussions are not intended to preclude alternative implementation - strategies for support of the name forms within Kerberos mechanisms - or mechanisms based on other technologies. To enhance application - - - -Linn Standards Track [Page 12] - -RFC 1964 Kerberos Version 5 GSS-API June 1996 - - - portability, implementors of mechanisms are encouraged to support - name forms as defined in this section, even if their mechanisms are - independent of Kerberos V5. - -2.1. Mandatory Name Forms - - This section discusses name forms which are to be supported by all - conformant implementations of the Kerberos V5 GSS-API mechanism. - -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 included within this name representation are as follows, - proceeding 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. - - - - - - -Linn Standards Track [Page 13] - -RFC 1964 Kerberos Version 5 GSS-API June 1996 - - - (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 retains the - Object Identifier and symbolic name assignments previously made at - the Kerberos V5 GSS-API mechanism level, and adopts the definition as - 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. This name form is constructed using two elements, - "service" and "hostname", as follows: - - service@hostname - - When 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 which 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" defaulted 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 will be required for use in conjunction 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 - - - -Linn Standards Track [Page 14] - -RFC 1964 Kerberos Version 5 GSS-API June 1996 - - - GSS-API Version 2. - - This name type represents a self-describing object, whose framing - structure will be defined at the mechanism-independent level for - GSS-API Version 2. When generated by the Kerberos V5 mechanism, 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 structure as defined for the - Kerberos Principal Name Form. - - In order to achieve a distinguished encoding for comparison purposes, - the following additional constraints are imposed 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 accomodate cases (1) and (2). - -2.2. Optional Name Forms - - This section discusses additional name forms which may optionally be - supported by implementations of the Kerberos V5 GSS-API mechanism. - It is recognized that some of the name forms cited here are derived - from UNIX(tm) operating system platforms; some listed forms may be - irrelevant to non-UNIX platforms, and definition of additional forms - corresponding to such platforms may also be appropriate. It is also - recognized that OS-specific functions outside GSS-API are likely to - exist in order to perform translations among these forms, and that - GSS-API implementations supporting these forms may themselves be - layered atop such OS-specific functions. Inclusion of this support - within GSS-API implementations is intended as a convenience to - 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. - - - -Linn Standards Track [Page 15] - -RFC 1964 Kerberos Version 5 GSS-API June 1996 - - - Its interpretation is OS-specific. This name form is constructed as: - - username - - Assuming 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 - postfixing 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. This name type is similar to the - Machine UID Form, except that the buffer contains 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; the pair of a TGT and its corresponding - session key forms a credential which 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. - - - - -Linn Standards Track [Page 16] - -RFC 1964 Kerberos Version 5 GSS-API June 1996 - - - The encryption key used by the Kerberos server 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. In addition to 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 is a local matter how the - Kerberos V5 mechanism implementation finds the appropriate Kerberos - V5 credentials cache or key table. - - However, when the Kerberos V5 mechanism attempts to obtain initiating - credentials for a service principal which are not 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 in support of portability, - and 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. Use of these - definitions will enable independent implementors 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 which a particular GSS-API implementation uses to represent - the minor_status values specified in this section. - - It is 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 as defined on a - mechanism-wide basis within this section when that code is accurately - representative of reportable status rather than using a separate, - implementation-defined code. - - - -Linn Standards Track [Page 17] - -RFC 1964 Kerberos Version 5 GSS-API June 1996 - - -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 to be used - with the Kerberos V5 GSS-API mechanism as input to GSS_Wrap() and - GSS_GetMIC() routines in order to select among alternate integrity - and confidentiality algorithms. Additional QOP values may be added in - future versions of this specification. Non-overlapping bit positions - are and will be employed in order that both integrity and - - - -Linn Standards Track [Page 18] - -RFC 1964 Kerberos Version 5 GSS-API June 1996 - - - 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 are used to select - 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, therefore, the bit positions containing those - values should be cleared before being returned by implementations of - GSS_GetMIC() and GSS_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. - - - - - - - - - - -Linn Standards Track [Page 19] - -RFC 1964 Kerberos Version 5 GSS-API June 1996 - - -5. Security Considerations - - Security issues are discussed throughout this memo. - -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 - - John Linn - OpenVision Technologies - One Main St. - Cambridge, MA 02142 USA - - Phone: +1 617.374.2245 - EMail: John.Linn@ov.com - - - - - - - - - - - - - - - - - - - - -Linn Standards Track [Page 20] - |
