--- /dev/null
+
+
+<Kerberos Working Group> Larry Zhu
+Internet Draft Karthik Jaganathan
+Updates: 1964 Microsoft
+Category: Standards Track Sam Hartman
+draft-ietf-krb-wg-gssapi-cfx-01.txt MIT
+ August 29, 2003
+ Expires: February 29, 2004
+
+ The Kerberos Version 5 GSS-API Mechanism: Version 2
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of [RFC-2026].
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts. Internet-Drafts are draft documents valid for a maximum of
+ six months and may be updated, replaced, or obsoleted by other
+ documents at any time. It is inappropriate to use Internet- Drafts
+ as reference material or to cite them other than as "work in
+ progress."
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+
+1. Abstract
+
+ [RFC-1964] defines protocols, procedures, and conventions to be
+ employed by peers implementing the Generic Security Service
+ Application Program Interface (as specified in [RFC-2743]) when
+ using the Kerberos Version 5 mechanism (as specified in [KRBCLAR]).
+
+ This memo obsoletes [RFC-1964] and proposes changes in response to
+ recent developments such as the introduction of Kerberos crypto
+ framework. It is intended that this memo or a subsequent version
+ will become the Kerberos Version 5 GSS-API mechanism specification
+ on the standards track.
+
+2. Conventions used in this document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC-2119].
+
+3. Introduction
+
+ [KCRYPTO] defines a generic framework for describing encryption and
+ checksum types to be used with the Kerberos protocol and associated
+ protocols.
+
+
+Zhu Standards Trace - February 16, 2003 1 \f
+ Kerberos Version 5 GSS-API August 2003
+
+
+ [RFC-1964] describes the GSSAPI mechanism for Kerberos V5. It
+ defines the format of context initiation, per-message and context
+ deletion tokens and uses algorithm identifiers for each cryptosystem
+ in per message and context deletion tokens.
+
+ The approach taken in this document obviates the need for algorithm
+ identifiers. This is accomplished by using the same encryption and
+ checksum algorithms specified by the crypto profile [KCRYPTO] for
+ the session key or subkey that is created during context
+ negotiation. Message layouts of the per-message and context
+ deletion tokens are therefore revised to remove algorithm indicators
+ and also to add extra information to support the generic crypto
+ framework [KCRYPTO].
+
+ Tokens transferred between GSS-API peers for security context
+ initiation are also described in this document. 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 [KRBCLAR] rather than within this specification.
+
+ The new token formats specified in this memo MUST be used with all
+ "newer" encryption types [KRBCLAR] and MAY be used with "older"
+ encryption types, provided that the initiator and acceptor know,
+ from the context establishment, that they can both process these new
+ token formats.
+
+ "Newer" encryption types are those which have been specified along
+ with or since the new Kerberos cryptosystem specification [KCRYPTO]
+ [KRBCLAR].
+
+ Note that in this document, "AES" is used for brevity to refer
+ loosely to either aes128-cts-hmac-sha1-96 or aes256-cts-hmac-sha1-96
+ as defined in [AES-KRB5]. AES is used as an example of the new
+ method defined in this document.
+
+4. Key Derivation for Per-Message and Context Deletion Tokens
+
+ To limit the exposure of a given key, [KCRYPTO] adopted "one-way"
+ "entropy-preserving" derived keys, for different purposes or key
+ usages, from a base key or protocol key. This document defines four
+ key usage values below for signing and sealing messages:
+
+ Name value
+ -------------------------------------
+ KG-USAGE-ACCEPTOR-SEAL 22
+ KG-USAGE-ACCEPTOR-SIGN 23
+ KG-USAGE-INITIATOR-SEAL 24
+ KG-USAGE-INITIATOR-SIGN 25
+
+ When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is
+ used as the usage number in the key derivation function for deriving
+ keys to be used in MIC and context deletion tokens, and KG-USAGE-
+ ACCEPTOR-SEAL is used for Wrap tokens; similarly when the sender is
+ the context initiator, KG-USAGE-INITIATOR-SIGN is used as the usage
+
+Zhu Standards Track - February 16, 2004 2 \f
+ Kerberos Version 5 GSS-API August 2003
+
+
+ number in the key derivation function for MIC and context deletion
+ tokens, KG-USAGE-INITIATOR-SEAL is used for Wrap Tokens. Even if
+ the Wrap token does not provide for confidentiality the same usage
+ values specified above are used.
+
+5. Quality of Protection
+
+ The GSSAPI specification [RFC-2743] provides for Quality of
+ Protection (QOP) values that can be used by the application to
+ request a certain type of encryption or signing. A zero QOP value
+ is used to indicate the "default" protection; applications which use
+ the default QOP are not guaranteed to be portable across
+ implementations or even inter-operate with different deployment
+ configurations of the same implementation. Using an algorithm that
+ is different from the one for which the key is defined may not be
+ appropriate. Therefore, when the new method in this document is
+ used, the QOP value is ignored.
+
+ The encryption and checksum algorithms in per-message and context
+ deletion tokens are now implicitly defined by the algorithms
+ associated with the session key or subkey. Algorithms identifiers
+ as described in [RFC-1964] are therefore no longer needed and
+ removed from the new token headers.
+
+6. Token Framing
+
+ Per [RFC-2743], all tokens emitted by the Kerberos V5 GSS-API
+ mechanism will have the framing shown below:
+
+ GSS-API DEFINITIONS ::=
+
+ BEGIN
+
+ MechType ::= OBJECT IDENTIFIER
+ -- representing Kerberos V5 mechanism
+
+ GSSAPI-Token ::=
+ -- option indication (delegation, etc.) indicated within
+ -- mechanism-specific token
+ [APPLICATION 0] IMPLICIT SEQUENCE {
+ thisMech MechType,
+ innerToken ANY DEFINED BY thisMech
+ -- contents mechanism-specific
+ -- ASN.1 structure not required
+ }
+ END
+
+ The innerToken field always starts with a two byte token-identifier
+ (TOK_ID). Here are the TOK_ID values:
+
+ Token TOK_ID Value in hex
+ -------------------------------------------
+ KRB_AP_REQUEST 01 00
+ KRB_AP_REQPLY 02 00
+
+Zhu Standards Track - February 16, 2004 3 \f
+ Kerberos Version 5 GSS-API August 2003
+
+
+ KRB_ERROR 03 00
+ [RFC-1964] MIC 01 01
+ [RFC-1964] Wrap 01 02
+ [RFC-1964] context deletion 02 01
+ MIC 04 04
+ Wrap 04 05
+ context deletion 05 04
+
+
+7. Context Initialization Tokens
+
+ For context initialization tokens, the body for the innerToken field
+ contains a Kerberos V5 message (KRB_AP_REQUEST, KRB_AP_REPLY, or
+ KRB_ERROR) as defined in [KRBCLAR].
+
+7.1. Authenticator Checksum
+
+ The authenticator in the KRB_AP_REQ message MUST include the
+ optional sequence number and the checksum field. The checksum field
+ is used to convey service flags, channel binding, and optional
+ delegation information. It MUST have a type of 0x8003. The length
+ of the checksum MUST be 24 bytes when delegation is not used. When
+ delegation is used, a TGT with its FORWARDABLE flag set will be
+ transferred within the KRB_CRED [KRBCLAR] message.
+
+ The format of the authenticator checksum field 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,
+ as defined next. 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]
+
+ [we need to get input on how to allow additional data for
+ extensions. Nicolas will post some text for this. If that is the
+ case, do we need to change the checksum type?]
+
+7.1.1. Flags Field
+
+ The checksum flags are used to convey service options or extension
+ negotiation information. The bits in the Flags field are allocated
+ as follows (Most significant bit is bit 0):
+
+Zhu Standards Track - February 16, 2004 4 \f
+ Kerberos Version 5 GSS-API August 2003
+
+
+ Bit Name Description
+ ----------------------------------------------------
+ 0..11 Mandatory Critical extension flags
+ 12..15 Optional Non-critical extension flags
+ 16..31 Standard Context establishment flags
+
+ An extension or context establishment flag can either be critical or
+ non-critical. When the context initiator desires a particular
+ extension or context establishment flag (either critical or non-
+ critical) it sets the appropriate checksum flag. The context
+ acceptor MUST ignore unsupported non-critical extensions or flags in
+ the initiator's context token (i.e., acceptors MUST NOT return an
+ error just because there were unsupported non-critical extensions or
+ flags in the initiator's token). The acceptor MUST return
+ GSS_S_UNAVAILABLE [RFC-2743] if there are unsupported critical
+ extensions or flags in the initiator's context token.
+
+ The following context establishment flags are defined in [RFC-2744]
+
+ Flag Name Value
+ ---------------------------------
+ GSS_C_DELEG_FLAG 1
+ GSS_C_MUTUAL_FLAG 2
+ GSS_C_REPLAY_FLAG 4
+ GSS_C_SEQUENCE_FLAG 8
+ GSS_C_CONF_FLAG 16
+ GSS_C_INTEG_FLAG 32
+ GSS_C_ANON_FLAG 64
+
+ Context establishment flags are exposed to the calling application.
+ If the calling application desires a particular service option then
+ it requests that option via GSS_Init_sec_context(). An
+ implementation that supports a particular extension SHOULD then set
+ the appropriate flag in the checksum Flags field.
+
+ All existing context establishment flags are non-critical, and it is
+ possible that a new context establishment flag can be added as a
+ critical flag.
+
+7.1.2. Channel Binding Information
+
+ 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.
+
+ (2) All input length fields within gss_buffer_desc [RFC-2744]
+ elements of a gss_channel_bindings_struct [RFC-2744], even those
+ which are zero-valued, shall be included in the hash calculation;
+ the value elements of gss_buffer_desc elements shall be
+ dereferenced, and the resulting data shall be included within the
+ hash computation, only for the case of gss_buffer_desc elements
+ having non-zero length specifiers.
+
+Zhu Standards Track - February 16, 2004 5 \f
+ Kerberos Version 5 GSS-API August 2003
+
+
+
+ (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.
+
+ [Nicolas suggested that the only change that might be needed here
+ was the use of SHA1 instead of MD5]
+
+8. Per-Message and Context Deletion Tokens
+
+ The new per-message and context deletion token formats defined in
+ this document are designed to accommodate the requirements of newer
+ crypto systems. The token layouts have also been designed to
+ facilitate scatter-gather and in-place encryption without incurring
+ significant performance penalties for implementations that do not
+ allow for either scatter-gather or in-place encryption.
+
+ The design along with the rationale behind it is discussed in detail
+ in the following sections.
+
+8.1. Sequence Number and Direction Indicator
+
+ The sequence number for any per-message or context deletion token is
+ a 64 bit integer (expressed in big endian order). One separate flag
+ is used as the direction-indicator as described in section 8.2.
+ Both the sequence number and the direction-indicator are protected
+ by the encryption and checksum procedures as specified in section
+ 8.4.
+
+8.2. Flags Field
+
+ The Flags field is a one-byte bit vector used to indicate a set of
+ attributes. The meanings of the flags are:
+
+ Bit Name Description
+ ---------------------------------------------------------------
+ 0 SentByAcceptor When set, this flag indicates the sender
+ is the context acceptor. When not set,
+ it indicates the sender is the context
+ initiator.
+ 1 Sealed When set in Wrap tokens, this flag
+ indicates confidentiality is provided
+ for. It MUST not be set in MIC and
+ context deletion tokens.
+
+ The rest of available bits are reserved for future use.
+
+8.3. EC Field
+
+ The EC (Extra Count) field is a two-byte integer field expressed in
+ big endian order.
+
+
+
+Zhu Standards Track - February 16, 2004 6 \f
+ Kerberos Version 5 GSS-API August 2003
+
+
+ In Wrap tokens with confidentiality, the EC field is used to encode
+ the size (in bytes) of the random filler, as described in section
+ 8.4.
+
+ In Wrap tokens without confidentiality, the EC field is used to
+ encode the size (in bytes) of the trailing checksum, as described in
+ section 8.4.
+
+ When AES is used, the EC field contains the hex value 00 0C in Wrap
+ tokens without confidentiality, and 00 00 in Wrap tokens with
+ confidentiality.
+
+8.4. Encryption and Checksum Operations
+
+ The encryption algorithms defined by the crypto profiles provide for
+ integrity protection. Therefore no separate checksum is needed.
+
+ The result of decryption can be longer than the original plaintext
+ [KCRYPTO] and the extra trailing bytes are called "crypto-system
+ garbage". However, given the size of any plaintext data, one can
+ always find the next (possibly larger) size so that, when padding
+ the to-be-encrypted text to that size, there will be no crypto-
+ system garbage added [KCRYPTO].
+
+ In Wrap tokens that provide for confidentiality, the "header" (the
+ first 16 bytes of the Wrap token) is appended to the plaintext data
+ before encryption. Random filler is inserted between the plaintext-
+ data and the "header", and there SHALL NOT be crypto-system garbage
+ added by the decryption operation. The resulting Wrap token is
+ {"header" | encrypt(plaintext-data | random-filler | "header")},
+ where encrypt() is the encryption operation (which provides for
+ integrity protection) defined in the crypto profile [KCRYPTO].
+
+ [A note from the design team (Sam, Nicolas, Ken, JK and Larry):
+ constraints need to be added to kcrypto to keep the header at the
+ end of the decrypted data. Without these constraints, we might have
+ the header pre-pended to the front of the data and encode an 8 byte
+ length for the plaintext data, which is less efficient.
+
+ Constraints to be added: Given the length of any plaintext data,
+ there should always exist the next (possibly larger) size for which,
+ when padding the to-be-encrypted data to that size, there will be no
+ cryptosystem garbage added, and the number of bytes needed to pad to
+ the next size is no larger than 64K. This is a small addition to
+ kcrypto and we will bring it up at the IETF last call for kcrypto]
+
+ In Wrap tokens that do not provide for confidentiality, the checksum
+ is calculated over the plaintext data concatenated with the token
+ header (the first 16 bytes of the Wrap token). The resulting Wrap
+ token is {"header" | plaintext-data | get_mic(plaintext-data |
+ "header")}, where get_mic() is the checksum operation defined in
+ the crypto profile [KCRYPTO].
+
+
+Zhu Standards Track - February 16, 2004 7 \f
+ Kerberos Version 5 GSS-API August 2003
+
+
+ The parameters for the key and the cipher-state in the encrypt() and
+ get_mic() operations have been omitted for brevity.
+
+ The resulting Wrap tokens bind the data to the token header,
+ including the sequence number and the directional indicator.
+
+ [With AEAD, Wrap tokens with confidentiality do not need to encrypt
+ the header and the overhead can be reduced slightly]
+
+ For MIC tokens, the checksum is first calculated over the token
+ header (the first 16 bytes of the MIC token) and then the to-be-
+ signed plaintext data.
+
+ For context deletion tokens, the checksum is calculated over the
+ token header (the first 16 bytes of the context deletion token).
+
+ When AES is used, the checksum algorithm is HMAC_SHA1_96 and the
+ checksum size is 12 bytes. Data is pre-pended with a 16 byte
+ confounder before encryption, and no padding is needed.
+
+8.5. RRC Field
+
+ The RRC (Right Rotation Count) field in Wrap tokens is added to
+ allow the data to be encrypted in-place by existing [SSPI]
+ applications that do not provide an additional buffer for the
+ trailer (the cipher text after the in-place-encrypted data) in
+ addition to the buffer for the header (the cipher text before the
+ in-place-encrypted data). The resulting Wrap token in the previous
+ section, excluding the first 16 bytes of the token header, is
+ rotated to the right by "RRC" bytes. The net result is that "RRC"
+ bytes of trailing octets are moved toward the header. Consider the
+ following as an example of this rotation operation: Assume that the
+ RRC value is 3 and the token before the rotation is {"header" | aa |
+ bb | cc | dd | ee | ff | gg | hh}, the token after rotation would be
+ {"header" | ff | gg | hh | aa | bb | cc | dd | ee }, where {aa | bb
+ | cc |...| hh} is used to indicate the byte sequence.
+
+ The RRC field is expressed as a two-byte integer in big endian
+ order.
+
+ The rotation count value is chosen by the sender based on
+ implementation details, and the receiver MUST be able to interpret
+ all possible rotation count values.
+
+8.6. Message Layout for Per-message and Context Deletion Tokens
+
+ The new message layouts are as follows.
+
+ MIC Token:
+
+ Byte no Name Description
+ 0..1 TOK_ID Identification field.
+ Tokens emitted by GSS_GetMIC()
+ contain the hex value 04 04 in
+
+Zhu Standards Track - February 16, 2004 8 \f
+ Kerberos Version 5 GSS-API August 2003
+
+
+ this field.
+ 2 Flags Attributes field, as described in
+ Section 8.2.
+ 3..7 Filler Contains 5 bytes of hex value FF.
+ 8..15 SND_SEQ Sequence number field in
+ cleartext, in big endian order.
+ 16..last SGN_CKSUM Checksum of byte 0..15 and the
+ "to-be-signed" data, where the
+ checksum algorithm is defined by
+ the crypto profile for the
+ session key or subkey.
+
+
+ The Filler field is included in the checksum calculation for
+ simplicity. This is common to both MIC and context deletion token
+ checksum calculations.
+
+ Wrap Token:
+
+ Byte no Name Description
+ 0..1 TOK_ID Identification field.
+ Tokens emitted by GSS_Wrap()
+ contain the hex value 05 04
+ in this field.
+ 2 Flags Attributes field, as described in
+ Section 8.2.
+ 3 Filler Contains the hex value FF.
+ 4..5 EC Contains the "extra count" field,
+ in big endian order as described in
+ section 8.3.
+ 6..7 RRC Contains the "right rotation
+ count" in big endian order, as
+ described in section 8.5.
+ 8..15 SND_SEQ Sequence number field in
+ cleartext, in big endian order.
+ 16..last Data Encrypted data or (plaintext data +
+ checksum), as described in section
+ 8.4, where the encryption or
+ checksum algorithm is defined by
+ the crypto profile for the session
+ key or subkey.
+
+
+ Context Deletion Token:
+
+ Byte no Name Description
+ 0..1 TOK_ID Identification field.
+ Tokens emitted by
+ GSS_Delete_sec_context() contain
+ the hex value 04 05 in this
+ field.
+ 2 Flags Attributes field, as described in
+ Section 8.2.
+
+Zhu Standards Track - February 16, 2004 9 \f
+ Kerberos Version 5 GSS-API August 2003
+
+
+ 3..7 Filler Contains 5 bytes of hex value FF.
+ 8..15 SND_SEQ Sequence number field in
+ cleartext, in big endian order.
+ 16..N SGN_CKSUM Checksum of byte 0..15, where the
+ checksum algorithm is defined by
+ the crypto profile for the
+ session key or subkey.
+
+
+9. 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-2744].
+
+9.1. Minor Status Codes
+
+ This section recommends common symbolic names for minor_status
+ values to be returned by the Kerberos V5 GSS-API mechanism. Use of
+ these definitions will enable independent implementers to enhance
+ application portability across different implementations of the
+ mechanism defined in this specification. (In all cases,
+ implementations of GSS_Display_status() will enable callers to
+ convert minor_status indicators to text representations.) Each
+ implementation should make available, through include files or other
+ means, a facility to translate these symbolic names into the
+ concrete values 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.
+
+9.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
+
+Zhu Standards Track - February 16, 2004 10 \f
+ Kerberos Version 5 GSS-API August 2003
+
+
+ /* "Credential usage type is unknown" */
+ GSS_KRB5_S_G_UNKNOWN_QOP
+ /* "Unknown quality of protection specified" */
+
+9.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" */
+
+9.2. Buffer Sizes
+
+ All implementations of this specification shall be capable of
+ accepting buffers of at least 16K bytes 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 16K byte input buffer
+ as input to GSS_Unwrap(). Support for larger buffer sizes is
+ optional but recommended.
+
+10. Backwards Compatibility Considerations
+
+ The new token formats defined in this document will only be
+ recognized by new implementations. To address this, implementations
+ can always use the explicit sign or seal algorithm in [GSSAPI-KRB5]
+ when the key type corresponds to "older" algorithms. An alternative
+ approach might be to retry sending the message with the sign or seal
+ algorithm explicitly defined as in [GSSAPI-KRB5]. However this
+ would require the use of a mechanism such as [RFC-2478] to securely
+ negotiate the algorithm or the use out of band mechanism to choose
+ appropriate algorithms. For this reason, it is RECOMMENDED that the
+ new token formats defined in this document can be used only if both
+ peers are known during context negotiation to support the new
+ mechanism (either because of the use of "new" enctypes or because of
+ the use of Kerberos V extensions).
+
+11. Security Considerations
+
+ It is possible that the KDC returns a session-key type that is not
+ supported by the GSSAPI implementation (either on the client and the
+ server). In this case the implementation MUST not try to use the key
+
+Zhu Standards Track - February 16, 2004 11 \f
+ Kerberos Version 5 GSS-API August 2003
+
+
+ with a supported cryptosystem. This will ensure that no security
+ weaknesses arise due to the use of an inappropriate key with an
+ encryption algorithm.
+
+ In addition the security problem described in [3DES] arising from
+ the use of a service implementation with a GSSAPI mechanism
+ supporting only DES and a Kerberos mechanism supporting both DES and
+ Triple DES is actually a more generic one. It arises whenever the
+ GSSAPI implementation does not support a stronger cryptosystem
+ supported by the Kerberos mechanism. KDC administrators desiring to
+ limit the session key types to support interoperability with such
+ GSSAPI implementations should carefully weigh the reduction in
+ protection offered by such mechanisms against the benefits of
+ interoperability.
+
+
+12. Acknowledgments
+
+ The authors wish to acknowledge the contributions from the following
+ individuals:
+
+ Ken Raeburn and Nicolas Willams corrected many of our errors in the
+ use of generic profiles and were instrumental in the creation of this
+ draft.
+
+ Sam Hartman and Ken Raeburn suggested the "floating trailer" idea.
+
+ Sam Hartman and Nicolas Williams recommended the replacing our
+ earlier key derivation function for directional keys with different
+ key usage numbers for each direction as well as retaining the
+ directional bit for maximum compatibility.
+
+ Paul Leach provided numerous suggestions and comments.
+
+ Scott Field, Richard Ward, Dan Simon also provided valuable inputs on
+ this draft.
+
+13. References
+
+13.1. Normative References
+
+ [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision
+ 3", BCP 9, RFC 2026, October 1996.
+
+ [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [AES] National Institute of Standards and Technology, U.S.
+ Department of Commerce, "Advanced Encryption Standard", Federal
+ Information Processing Standards Publication 197, Washington, DC,
+ November 2001.
+
+
+
+Zhu Standards Track - February 16, 2004 12 \f
+ Kerberos Version 5 GSS-API August 2003
+
+
+ [AES-KRB5] Raeburn, K., "AES Encryption for Kerberos 5", draft-
+ raeburn-krb-rijndael-krb-05.txt, June 2003. Work in progress.
+
+ [3DES] Raeburn, K., "Triple-DES Support for the Kerberos 5 GSSAPI
+ Mechanism", draft-raeburn-gssapi-krb5-3des-XX.txt in the MIT
+ distribution, June 2000.
+
+ [RFC-2743] Linn, J., "Generic Security Service Application Program
+ Interface Version 2, Update 1", RFC 2743, January 2000.
+
+ [RFC-2744] Wray, J., "Generic Security Service API Version 2 : C-
+ bindings", RFC 2744, January 2000.
+
+ [RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+ RFC 1964, June 1996.
+
+ [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for
+ Kerberos 5", draft-ietf-krb-wg-crypto-05.txt, June, 2003. Work in
+ progress.
+
+ [KRBCLAR] Neuman, C., Kohl, J., Ts'o T., Yu T., Hartman, S.,
+ Raeburn, K., "The Kerveros Network Authentication Service (V5)",
+ draft-ietf-krb-wg-kerberos-clarifications-04.txt, February 2002.
+ Work in progress.
+
+ [RFC-2478] Baize, E., Pinkas D., "The Simple and Protected GSS-API
+ Negotiation Mechanism.", RFC 2478, December 1998.
+
+13.2. Informative References
+
+ [SSPI] Leach, P., Security Service Provider Interface, MSDN, April
+ 2003
+
+14. Author's Address
+
+ Larry Zhu
+ One Microsoft Way
+ Redmond, WA 98052 - USA
+ EMail: LZhu@microsoft.com
+
+ Karthik Jaganathan
+ One Microsoft Way
+ Redmond, WA 98052 - USA
+ EMail: karthikj@microsoft.com
+
+ Sam Hartman
+ Massachusetts Institute of Technology
+ 77 Massachusetts Avenue
+ Cambridge, MA 02139 - USA
+ Email: hartmans@MIT.EDU
+
+
+Zhu Standards Track - February 16, 2004 13 \f
+ Kerberos Version 5 GSS-API August 2003
+
+
+
+Full Copyright Statement
+
+ "Copyright (C) The Internet Society (date). All Rights Reserved.
+
+ This document and translations of it may be copied and
+ furnished to others, and derivative works that comment on or
+ otherwise explain it or assist in its implementation may be
+ prepared, copied, published and distributed, in whole or in
+ part, without restriction of any kind, provided that the above
+ copyright notice and this paragraph are included on all such
+ copies and derivative works. However, this document itself may
+ not be modified in any way, such as by removing the copyright
+ notice or references to the Internet Society or other Internet
+ organizations, except as needed for the purpose of developing
+ Internet standards in which case the procedures for copyrights
+ defined in the Internet Standards process must be followed, or
+ as required to translate it into languages other than English.
+
+ The limited permissions granted above are perpetual and will
+ not be revoked by the Internet Society or its successors or
+ assigns.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu Standards Track - February 16, 2004 14 \f
\ No newline at end of file
git.samba.org / samba.git / blobdiff