< draft-ietf-krb-wg-gssapi-cfx-06.txt   draft-ietf-krb-wg-gssapi-cfx-07.txt >
<Network Working Group> Larry Zhu <Network Working Group> Larry Zhu
Internet Draft Karthik Jaganathan Internet Draft Karthik Jaganathan
Updates: 1964 Microsoft Updates: 1964 Microsoft
Category: Standards Track Sam Hartman Category: Standards Track Sam Hartman
draft-ietf-krb-wg-gssapi-cfx-06.txt MIT draft-ietf-krb-wg-gssapi-cfx-07.txt MIT
February 16, 2004 March 9, 2004
Expires: August 16, 2004 Expires: September 9, 2004
The Kerberos Version 5 GSS-API Mechanism: Version 2 The Kerberos Version 5 GSS-API Mechanism: Version 2
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC-2026]. all provisions of Section 10 of [RFC-2026].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at line 38 skipping to change at line 38
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
The distribution of this memo is unlimited. It is filed as The distribution of this memo is unlimited. It is filed as
draft-ietf-krb-wg-gssapi-cfx-06.txt, and expires on August 10 draft-ietf-krb-wg-gssapi-cfx-07.txt, and expires on September 9
2004. Please send comments to: ietf-krb-wg@anl.gov. 2004. Please send comments to: ietf-krb-wg@anl.gov.
Abstract Abstract
This document defines protocols, procedures, and conventions to be This document defines protocols, procedures, and conventions to be
employed by peers implementing the Generic Security Service employed by peers implementing the Generic Security Service
Application Program Interface (GSS-API) when using the Kerberos Application Program Interface (GSS-API) when using the Kerberos
Version 5 mechanism. Version 5 mechanism.
RFC-1964 is updated and incremental changes are proposed in response RFC-1964 is updated and incremental changes are proposed in response
to recent developments such as the introduction of Kerberos to recent developments such as the introduction of Kerberos
cryptosystem framework. These changes support the inclusion of new cryptosystem framework. These changes support the inclusion of new
cryptosystems, by defining new per-message tokens along with their cryptosystems, by defining new per-message tokens along with their
encryption and checksum algorithms based on the cryptosystem encryption and checksum algorithms based on the cryptosystem
profiles. profiles.
Conventions used in this document Conventions used in this document
DRAFT Kerberos Version 5 GSS-API Expires August 2004 DRAFT Kerberos Version 5 GSS-API Expires September 2004
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-2119]. document are to be interpreted as described in [RFC-2119].
The term "little endian order" is used for brevity to refer to the The term "little endian order" is used for brevity to refer to the
least-significant-octet-first encoding, while the term "big endian least-significant-octet-first encoding, while the term "big endian
order" is for the most-significant-octet-first encoding. order" is for the most-significant-octet-first encoding.
Table of Contents Table of Contents
skipping to change at line 114 skipping to change at line 114
[RFC-1964] describes the GSS-API mechanism for Kerberos Version 5. [RFC-1964] describes the GSS-API mechanism for Kerberos Version 5.
It defines the format of context establishment, per-message and It defines the format of context establishment, per-message and
context deletion tokens and uses algorithm identifiers for each context deletion tokens and uses algorithm identifiers for each
cryptosystem in per message and context deletion tokens. cryptosystem in per message and context deletion tokens.
The approach taken in this document obviates the need for algorithm The approach taken in this document obviates the need for algorithm
identifiers. This is accomplished by using the same encryption identifiers. This is accomplished by using the same encryption
algorithm, specified by the crypto profile [KCRYPTO] for the session algorithm, specified by the crypto profile [KCRYPTO] for the session
key or subkey that is created during context negotiation, and its key or subkey that is created during context negotiation, and its
required checksum algorithm. Message layouts of the per-message required checksum algorithm. Message layouts of the per-message
DRAFT Kerberos Version 5 GSS-API Expires August 2004 DRAFT Kerberos Version 5 GSS-API Expires September 2004
tokens are therefore revised to remove algorithm indicators and also tokens are therefore revised to remove algorithm indicators and also
to add extra information to support the generic crypto framework to add extra information to support the generic crypto framework
[KCRYPTO]. [KCRYPTO].
Tokens transferred between GSS-API peers for security context Tokens transferred between GSS-API peers for security context
establishment are also described in this document. The data establishment are also described in this document. The data
elements exchanged between a GSS-API endpoint implementation and the elements exchanged between a GSS-API endpoint implementation and the
Kerberos Key Distribution Center (KDC) [KRBCLAR] are not specific to Kerberos Key Distribution Center (KDC) [KRBCLAR] are not specific to
GSS-API usage and are therefore defined within [KRBCLAR] rather than GSS-API usage and are therefore defined within [KRBCLAR] rather than
skipping to change at line 171 skipping to change at line 171
This document defines four key usage values below that are used to This document defines four key usage values below that are used to
derive a specific key for signing and sealing messages, from the derive a specific key for signing and sealing messages, from the
session key or subkey [KRBCLAR] created during the context session key or subkey [KRBCLAR] created during the context
establishment. establishment.
Name Value Name Value
------------------------------------- -------------------------------------
KG-USAGE-ACCEPTOR-SEAL 22 KG-USAGE-ACCEPTOR-SEAL 22
KG-USAGE-ACCEPTOR-SIGN 23 KG-USAGE-ACCEPTOR-SIGN 23
KG-USAGE-INITIATOR-SEAL 24 KG-USAGE-INITIATOR-SEAL 24
DRAFT Kerberos Version 5 GSS-API Expires August 2004 DRAFT Kerberos Version 5 GSS-API Expires September 2004
KG-USAGE-INITIATOR-SIGN 25 KG-USAGE-INITIATOR-SIGN 25
When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is
used as the usage number in the key derivation function for deriving used as the usage number in the key derivation function for deriving
keys to be used in MIC tokens (as defined in section 4.2.6.1), and keys to be used in MIC tokens (as defined in section 4.2.6.1), and
KG-USAGE-ACCEPTOR-SEAL is used for Wrap tokens(as defined in section KG-USAGE-ACCEPTOR-SEAL is used for Wrap tokens(as defined in section
4.2.6.2); similarly when the sender is the context initiator, KG- 4.2.6.2); similarly when the sender is the context initiator, KG-
USAGE-INITIATOR-SIGN is used as the usage number in the key USAGE-INITIATOR-SIGN is used as the usage number in the key
derivation function for MIC tokens, KG-USAGE-INITIATOR-SEAL is used derivation function for MIC tokens, KG-USAGE-INITIATOR-SEAL is used
skipping to change at line 228 skipping to change at line 228
GSS-API DEFINITIONS ::= GSS-API DEFINITIONS ::=
BEGIN BEGIN
MechType ::= OBJECT IDENTIFIER MechType ::= OBJECT IDENTIFIER
-- representing Kerberos V5 mechanism -- representing Kerberos V5 mechanism
GSSAPI-Token ::= GSSAPI-Token ::=
-- option indication (delegation, etc.) indicated within -- option indication (delegation, etc.) indicated within
DRAFT Kerberos Version 5 GSS-API Expires August 2004 DRAFT Kerberos Version 5 GSS-API Expires September 2004
-- mechanism-specific token -- mechanism-specific token
[APPLICATION 0] IMPLICIT SEQUENCE { [APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType, thisMech MechType,
innerToken ANY DEFINED BY thisMech innerToken ANY DEFINED BY thisMech
-- contents mechanism-specific -- contents mechanism-specific
-- ASN.1 structure not required -- ASN.1 structure not required
} }
END END
skipping to change at line 285 skipping to change at line 285
Octet Name Description Octet Name Description
----------------------------------------------------------------- -----------------------------------------------------------------
0..3 Lgth Number of octets in Bnd field; Represented 0..3 Lgth Number of octets in Bnd field; Represented
in little-endian order; Currently contains in little-endian order; Currently contains
hex value 10 00 00 00 (16). hex value 10 00 00 00 (16).
4..19 Bnd Channel binding information, as described in 4..19 Bnd Channel binding information, as described in
section 4.1.1.2. section 4.1.1.2.
20..23 Flags Four-octet context-establishment flags in 20..23 Flags Four-octet context-establishment flags in
little-endian order as described in section little-endian order as described in section
DRAFT Kerberos Version 5 GSS-API Expires August 2004 DRAFT Kerberos Version 5 GSS-API Expires September 2004
4.1.1.1. 4.1.1.1.
24..25 DlgOpt The delegation option identifier (=1) in 24..25 DlgOpt The delegation option identifier (=1) in
little-endian order [optional]. This field little-endian order [optional]. This field
and the next two fields are present if and and the next two fields are present if and
only if GSS_C_DELEG_FLAG is set as described only if GSS_C_DELEG_FLAG is set as described
in section 4.1.1.1. in section 4.1.1.1.
26..27 Dlgth The length of the Deleg field in little- 26..27 Dlgth The length of the Deleg field in little-
endian order [optional]. endian order [optional].
28..(n-1) Deleg A KRB_CRED message (n = Dlgth + 28) 28..(n-1) Deleg A KRB_CRED message (n = Dlgth + 28)
skipping to change at line 341 skipping to change at line 341
GSS_C_INTEG_FLAG 32 GSS_C_INTEG_FLAG 32
Context establishment flags are exposed to the calling application. Context establishment flags are exposed to the calling application.
If the calling application desires a particular service option then If the calling application desires a particular service option then
it requests that option via GSS_Init_sec_context() [RFC-2743]. If it requests that option via GSS_Init_sec_context() [RFC-2743]. If
the corresponding return state values [RFC-2743] indicate that any the corresponding return state values [RFC-2743] indicate that any
of above optional context level services will be active on the of above optional context level services will be active on the
context, the corresponding flag values in the table above MUST be context, the corresponding flag values in the table above MUST be
set in the checksum Flags field. set in the checksum Flags field.
DRAFT Kerberos Version 5 GSS-API Expires August 2004 DRAFT Kerberos Version 5 GSS-API Expires September 2004
Flag values 4096..524288 (2^12, 2^13, ..., 2^19) are reserved for Flag values 4096..524288 (2^12, 2^13, ..., 2^19) are reserved for
use with legacy vendor-specific extensions to this mechanism. use with legacy vendor-specific extensions to this mechanism.
All other flag values not specified herein are reserved for future All other flag values not specified herein are reserved for future
use. Future revisions of this mechanism may use these reserved use. Future revisions of this mechanism may use these reserved
flags and may rely on implementations of this version to not use flags and may rely on implementations of this version to not use
such flags in order to properly negotiate mechanism versions. such flags in order to properly negotiate mechanism versions.
Undefined flag values MUST be cleared by the sender, and unknown Undefined flag values MUST be cleared by the sender, and unknown
flags MUST be ignored by the receiver. flags MUST be ignored by the receiver.
skipping to change at line 398 skipping to change at line 398
gss_channel_bindings_struct even those which are zero-valued, SHALL gss_channel_bindings_struct even those which are zero-valued, SHALL
be included in the hash calculation; the value elements of be included in the hash calculation; the value elements of
gss_buffer_desc elements SHALL be dereferenced, and the resulting gss_buffer_desc elements SHALL be dereferenced, and the resulting
data SHALL be included within the hash computation, only for the data SHALL be included within the hash computation, only for the
case of gss_buffer_desc elements having non-zero length specifiers. 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 (3) If the caller passes the value GSS_C_NO_BINDINGS instead of a
valid channel binding structure, the Bnd field SHALL be set to 16 valid channel binding structure, the Bnd field SHALL be set to 16
zero-valued octets. zero-valued octets.
DRAFT Kerberos Version 5 GSS-API Expires August 2004 DRAFT Kerberos Version 5 GSS-API Expires September 2004
If the caller to GSS_Accept_sec_context [RFC-2743] passes in If the caller to GSS_Accept_sec_context [RFC-2743] passes in
GSS_C_NO_CHANNEL_BINDINGS [RFC-2744] as the channel bindings then GSS_C_NO_CHANNEL_BINDINGS [RFC-2744] as the channel bindings then
the acceptor MAY ignore any channel bindings supplied by the the acceptor MAY ignore any channel bindings supplied by the
initiator, returning success even if the initiator did pass in initiator, returning success even if the initiator did pass in
channel bindings. channel bindings.
If the application supply, in the channel bindings, a buffer with a If the application supply, in the channel bindings, a buffer with a
length field larger than 4294967295 (2^32 - 1), the implementation length field larger than 4294967295 (2^32 - 1), the implementation
of this mechanism MAY chose to reject the channel bindings of this mechanism MAY chose to reject the channel bindings
skipping to change at line 455 skipping to change at line 455
Bit Name Description Bit Name Description
--------------------------------------------------------------- ---------------------------------------------------------------
0 SentByAcceptor When set, this flag indicates the sender 0 SentByAcceptor When set, this flag indicates the sender
is the context acceptor. When not set, is the context acceptor. When not set,
it indicates the sender is the context it indicates the sender is the context
initiator. initiator.
1 Sealed When set in Wrap tokens, this flag 1 Sealed When set in Wrap tokens, this flag
indicates confidentiality is provided indicates confidentiality is provided
for. It SHALL NOT be set in MIC tokens. for. It SHALL NOT be set in MIC tokens.
2 AcceptorSubkey A subkey asserted by the context acceptor 2 AcceptorSubkey A subkey asserted by the context acceptor
DRAFT Kerberos Version 5 GSS-API Expires August 2004 DRAFT Kerberos Version 5 GSS-API Expires September 2004
is used to protect the message. is used to protect the message.
The rest of available bits are reserved for future use and MUST be The rest of available bits are reserved for future use and MUST be
cleared. The receiver MUST ignore unknown flags. cleared. The receiver MUST ignore unknown flags.
4.2.3. EC Field 4.2.3. EC Field
The "EC" (Extra Count) field is a two-octet integer field expressed The "EC" (Extra Count) field is a two-octet integer field expressed
in big endian order. in big endian order.
skipping to change at line 483 skipping to change at line 483
described in section 4.2.4. described in section 4.2.4.
4.2.4. Encryption and Checksum Operations 4.2.4. Encryption and Checksum Operations
The encryption algorithms defined by the crypto profiles provide for The encryption algorithms defined by the crypto profiles provide for
integrity protection [KCRYPTO]. Therefore no separate checksum is integrity protection [KCRYPTO]. Therefore no separate checksum is
needed. needed.
The result of decryption can be longer than the original plaintext The result of decryption can be longer than the original plaintext
[KCRYPTO] and the extra trailing octets are called "crypto-system [KCRYPTO] and the extra trailing octets are called "crypto-system
garbage" in this document. However, given the size of any plaintext residue" in this document. However, given the size of any plaintext
data, one can always find a (possibly larger) size so that, when data, one can always find a (possibly larger) size so that, when
padding the to-be-encrypted text to that size, there will be no padding the to-be-encrypted text to that size, there will be no
crypto-system garbage added [KCRYPTO]. crypto-system residue added [KCRYPTO].
In Wrap tokens that provide for confidentiality, the first 16 octets In Wrap tokens that provide for confidentiality, the first 16 octets
of the Wrap token (the "header", as defined in section 4.2.6), SHALL of the Wrap token (the "header", as defined in section 4.2.6), SHALL
be appended to the plaintext data before encryption. Filler octets be appended to the plaintext data before encryption. Filler octets
MAY be inserted between the plaintext data and the "header", and the MAY be inserted between the plaintext data and the "header", and the
values and size of the filler octets are chosen by implementations, values and size of the filler octets are chosen by implementations,
such that there SHALL be no crypto-system garbage present after the such that there SHALL be no crypto-system residue present after the
decryption. The resulting Wrap token is {"header" | decryption. The resulting Wrap token is {"header" |
encrypt(plaintext-data | filler | "header")}, where encrypt() is the encrypt(plaintext-data | filler | "header")}, where encrypt() is the
encryption operation (which provides for integrity protection) encryption operation (which provides for integrity protection)
defined in the crypto profile [KCRYPTO], and the RRC field (as defined in the crypto profile [KCRYPTO], and the RRC field (as
defined in section 4.2.5) in the to-be-encrypted header contain the defined in section 4.2.5) in the to-be-encrypted header contain the
hex value 00 00. hex value 00 00.
In Wrap tokens that do not provide for confidentiality, the checksum In Wrap tokens that do not provide for confidentiality, the checksum
SHALL be calculated first over the to-be-signed plaintext data, and SHALL be calculated first over the to-be-signed plaintext data, and
then the first 16 octets of the Wrap token (the "header", as defined then the first 16 octets of the Wrap token (the "header", as defined
in section 4.2.6). Both the EC field and the RRC field in the token in section 4.2.6). Both the EC field and the RRC field in the token
header SHALL be filled with zeroes for the purpose of calculating header SHALL be filled with zeroes for the purpose of calculating
the checksum. The resulting Wrap token is {"header" | plaintext- the checksum. The resulting Wrap token is {"header" | plaintext-
data | get_mic(plaintext-data | "header")}, where get_mic() is the data | get_mic(plaintext-data | "header")}, where get_mic() is the
checksum operation for the required checksum mechanism of the chosen checksum operation for the required checksum mechanism of the chosen
encryption mechanism defined in the crypto profile [KCRYPTO]. encryption mechanism defined in the crypto profile [KCRYPTO].
DRAFT Kerberos Version 5 GSS-API Expires August 2004 DRAFT Kerberos Version 5 GSS-API Expires September 2004
The parameters for the key and the cipher-state in the encrypt() and The parameters for the key and the cipher-state in the encrypt() and
get_mic() operations have been omitted for brevity. get_mic() operations have been omitted for brevity.
For MIC tokens, the checksum SHALL be calculated as follows: the For MIC tokens, the checksum SHALL be calculated as follows: the
checksum operation is calculated first over the to-be-signed checksum operation is calculated first over the to-be-signed
plaintext data, and then the first 16 octets of the MIC token, where plaintext data, and then the first 16 octets of the MIC token, where
the checksum mechanism is the required checksum mechanism of the the checksum mechanism is the required checksum mechanism of the
chosen encryption mechanism defined in the crypto profile [KCRYPTO]. chosen encryption mechanism defined in the crypto profile [KCRYPTO].
skipping to change at line 568 skipping to change at line 568
Use of the GSS_GetMIC() call yields a token (referred as the MIC Use of the GSS_GetMIC() call yields a token (referred as the MIC
token in this document), separate from the user token in this document), separate from the user
data being protected, which can be used to verify the integrity of data being protected, which can be used to verify the integrity of
that data as received. The token has the following format: that data as received. The token has the following format:
Octet no Name Description Octet no Name Description
----------------------------------------------------------------- -----------------------------------------------------------------
0..1 TOK_ID Identification field. Tokens emitted by 0..1 TOK_ID Identification field. Tokens emitted by
GSS_GetMIC() contain the hex value 04 04 GSS_GetMIC() contain the hex value 04 04
DRAFT Kerberos Version 5 GSS-API Expires August 2004 DRAFT Kerberos Version 5 GSS-API Expires September 2004
expressed in big endian order in this field. expressed in big endian order in this field.
2 Flags Attributes field, as described in section 2 Flags Attributes field, as described in section
4.2.2. 4.2.2.
3..7 Filler Contains five octets of hex value FF. 3..7 Filler Contains five octets of hex value FF.
8..15 SND_SEQ Sequence number field in clear text, 8..15 SND_SEQ Sequence number field in clear text,
expressed in big endian order. expressed in big endian order.
16..last SGN_CKSUM Checksum of the "to-be-signed" data and 16..last SGN_CKSUM Checksum of the "to-be-signed" data and
octet 0..15, as described in section 4.2.4. octet 0..15, as described in section 4.2.4.
skipping to change at line 626 skipping to change at line 626
GSS_Delete_sec_context() should delete relevant locally-stored GSS_Delete_sec_context() should delete relevant locally-stored
context information. context information.
4.4. Token Identifier Assignment Considerations 4.4. Token Identifier Assignment Considerations
Token identifiers (TOK_ID) from 0x60 0x00 through 0x60 0xFF Token identifiers (TOK_ID) from 0x60 0x00 through 0x60 0xFF
inclusive are reserved and SHALL NOT be assigned. Thus by examining inclusive are reserved and SHALL NOT be assigned. Thus by examining
the first two octets of a token, one can tell unambiguously if it is the first two octets of a token, one can tell unambiguously if it is
wrapped with the generic GSS-API token framing. wrapped with the generic GSS-API token framing.
DRAFT Kerberos Version 5 GSS-API Expires August 2004 DRAFT Kerberos Version 5 GSS-API Expires September 2004
5. Parameter Definitions 5. Parameter Definitions
This section defines parameter values used by the Kerberos V5 GSS- This section defines parameter values used by the Kerberos V5 GSS-
API mechanism. It defines interface elements in support of API mechanism. It defines interface elements in support of
portability, and assumes use of C language bindings per [RFC-2744]. portability, and assumes use of C language bindings per [RFC-2744].
5.1. Minor Status Codes 5.1. Minor Status Codes
This section recommends common symbolic names for minor_status This section recommends common symbolic names for minor_status
skipping to change at line 682 skipping to change at line 682
GSS_KRB5_S_G_BAD_USAGE GSS_KRB5_S_G_BAD_USAGE
/* "Credential usage type is unknown" */ /* "Credential usage type is unknown" */
GSS_KRB5_S_G_UNKNOWN_QOP GSS_KRB5_S_G_UNKNOWN_QOP
/* "Unknown quality of protection specified" */ /* "Unknown quality of protection specified" */
5.1.2. Kerberos-specific-codes 5.1.2. Kerberos-specific-codes
GSS_KRB5_S_KG_CCACHE_NOMATCH GSS_KRB5_S_KG_CCACHE_NOMATCH
/* "Client principal in credentials does not match /* "Client principal in credentials does not match
specified name" */ specified name" */
DRAFT Kerberos Version 5 GSS-API Expires August 2004 DRAFT Kerberos Version 5 GSS-API Expires September 2004
GSS_KRB5_S_KG_KEYTAB_NOMATCH GSS_KRB5_S_KG_KEYTAB_NOMATCH
/* "No key available for specified service principal" */ /* "No key available for specified service principal" */
GSS_KRB5_S_KG_TGT_MISSING GSS_KRB5_S_KG_TGT_MISSING
/* "No Kerberos ticket-granting ticket available" */ /* "No Kerberos ticket-granting ticket available" */
GSS_KRB5_S_KG_NO_SUBKEY GSS_KRB5_S_KG_NO_SUBKEY
/* "Authenticator has no subkey" */ /* "Authenticator has no subkey" */
GSS_KRB5_S_KG_CONTEXT_ESTABLISHED GSS_KRB5_S_KG_CONTEXT_ESTABLISHED
/* "Context is already fully established" */ /* "Context is already fully established" */
GSS_KRB5_S_KG_BAD_SIGN_TYPE GSS_KRB5_S_KG_BAD_SIGN_TYPE
skipping to change at line 739 skipping to change at line 739
7. Security Considerations 7. Security Considerations
Channel bindings are validated by the acceptor. The acceptor can Channel bindings are validated by the acceptor. The acceptor can
ignore the channel bindings restriction supplied by the initiator ignore the channel bindings restriction supplied by the initiator
and carried in the authenticator checksum, if channel bindings are and carried in the authenticator checksum, if channel bindings are
not used by GSS_Accept_sec_context [RFC-2743], and the acceptor does not used by GSS_Accept_sec_context [RFC-2743], and the acceptor does
not prove to the initiator that it has the same channel bindings as not prove to the initiator that it has the same channel bindings as
the initiator, even if the client requested mutual authentication. the initiator, even if the client requested mutual authentication.
This limitation should be taken into consideration by designers of This limitation should be taken into consideration by designers of
applications that would use channel bindings, whether to limit the applications that would use channel bindings, whether to limit the
DRAFT Kerberos Version 5 GSS-API Expires August 2004 DRAFT Kerberos Version 5 GSS-API Expires September 2004
use of GSS-API contexts to nodes with specific network addresses, to use of GSS-API contexts to nodes with specific network addresses, to
authenticate other established, secure channels using Kerberos authenticate other established, secure channels using Kerberos
Version 5, or for any other purpose. Version 5, or for any other purpose.
Session key types are selected by the KDC. Under the current Session key types are selected by the KDC. Under the current
mechanism, no negotiation of algorithm types occurs, so server-side mechanism, no negotiation of algorithm types occurs, so server-side
(acceptor) implementations cannot request that clients not use (acceptor) implementations cannot request that clients not use
algorithm types not understood by the server. However, algorithm types not understood by the server. However,
administrators can control what enctypes can be used for session administrators can control what enctypes can be used for session
skipping to change at line 794 skipping to change at line 794
Paul Leach provided numerous suggestions and comments. Paul Leach provided numerous suggestions and comments.
Scott Field, Richard Ward, Dan Simon, Kevin Damour, and Simon Scott Field, Richard Ward, Dan Simon, Kevin Damour, and Simon
Josefsson also provided valuable inputs on this document. Josefsson also provided valuable inputs on this document.
Jeffrey Hutzelman provided comments and clarifications for the text Jeffrey Hutzelman provided comments and clarifications for the text
related to the channel bindings. related to the channel bindings.
Jeffrey Hutzelman and Russ Housley suggested many editorial changes. Jeffrey Hutzelman and Russ Housley suggested many editorial changes.
DRAFT Kerberos Version 5 GSS-API Expires August 2004 DRAFT Kerberos Version 5 GSS-API Expires September 2004
Luke Howard provided implementations of this document for the Luke Howard provided implementations of this document for the
Heimdal code base, and helped inter-operability testing with the Heimdal code base, and helped inter-operability testing with the
Microsoft code base, together with Love Hornquist Astrand. These Microsoft code base, together with Love Hornquist Astrand. These
experiments formed the basis of this document. experiments formed the basis of this document.
Martin Rex provided suggestions of TOK_ID assignment recommendations Martin Rex provided suggestions of TOK_ID assignment recommendations
thus the token tagging in this document is unambiguous if the token thus the token tagging in this document is unambiguous if the token
is wrapped with the pseudo ASN.1 header. is wrapped with the pseudo ASN.1 header.
This document retains some of the text of RFC-1964 in relevant John Linn wrote the original Kerberos Version 5 mechanism
sections. specification [RFC-1964], of which some of the text has been retained
in this document.
9. Intellectual Property Statement 9. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
skipping to change at line 849 skipping to change at line 850
[RFC-2743] Linn, J., "Generic Security Service Application Program [RFC-2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC-2744] Wray, J., "Generic Security Service API Version 2: C- [RFC-2744] Wray, J., "Generic Security Service API Version 2: C-
bindings", RFC 2744, January 2000. bindings", RFC 2744, January 2000.
[RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", [RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June 1996. RFC 1964, June 1996.
DRAFT Kerberos Version 5 GSS-API Expires August 2004 DRAFT Kerberos Version 5 GSS-API Expires September 2004
[KCRYPTO] RFC-Editor: To be replaced by RFC number for draft-ietf- [KCRYPTO] RFC-Editor: To be replaced by RFC number for draft-ietf-
krb-wg-crypto. Work in Progress. krb-wg-crypto. Work in Progress.
[KRBCLAR] RFC-Editor: To be replaced by RFC number for draft-ietf- [KRBCLAR] RFC-Editor: To be replaced by RFC number for draft-ietf-
krb-wg-kerberos-clarifications. Work in Progress. krb-wg-kerberos-clarifications. Work in Progress.
10.2. Informative References 10.2. Informative References
[SSPI] Leach, P., "Security Service Provider Interface", Microsoft [SSPI] Leach, P., "Security Service Provider Interface", Microsoft
skipping to change at line 885 skipping to change at line 886
Karthik Jaganathan Karthik Jaganathan
One Microsoft Way One Microsoft Way
Redmond, WA 98052 - USA Redmond, WA 98052 - USA
EMail: karthikj@microsoft.com EMail: karthikj@microsoft.com
Sam Hartman Sam Hartman
Massachusetts Institute of Technology Massachusetts Institute of Technology
77 Massachusetts Avenue 77 Massachusetts Avenue
Cambridge, MA 02139 - USA Cambridge, MA 02139 - USA
Email: hartmans@MIT.EDU Email: hartmans@MIT.EDU
DRAFT Kerberos Version 5 GSS-API Expires August 2004 DRAFT Kerberos Version 5 GSS-API Expires September 2004
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (date). All Rights Reserved. Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
 End of changes. 22 change blocks. 
25 lines changed or deleted 26 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/