summaryrefslogtreecommitdiffstats
path: root/crypto/heimdal/doc/standardisation/rfc1964.txt
diff options
context:
space:
mode:
authornectar <nectar@FreeBSD.org>2005-02-24 22:14:04 +0000
committernectar <nectar@FreeBSD.org>2005-02-24 22:14:04 +0000
commit412870c33635bdaae3fb6a6c2d59a85c65b85b2f (patch)
treeb14fa2308f0b719da9f5477f0b8d446c5572dc9b /crypto/heimdal/doc/standardisation/rfc1964.txt
parentbfc5316dea97d244a21b45ed0dce56f39074ba1b (diff)
downloadFreeBSD-src-412870c33635bdaae3fb6a6c2d59a85c65b85b2f.zip
FreeBSD-src-412870c33635bdaae3fb6a6c2d59a85c65b85b2f.tar.gz
Clean up the Heimdal vendor branch by removing files not included in
any import for several years. If memory serves, this was Suggested by: ru an awfully long time ago-- sorry for the delay!
Diffstat (limited to 'crypto/heimdal/doc/standardisation/rfc1964.txt')
-rw-r--r--crypto/heimdal/doc/standardisation/rfc1964.txt1123
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]
-
OpenPOWER on IntegriCloud