oysteikt/heimdal
0
0
Fork 0
Code Issues 5 Pull Requests Releases Activity
Files
b6b6ef861a838e3109b5193cfd3a24a99afd75ff
heimdal/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-01.txt
Love Hörnquist Åstrand d305925af4 x 
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@12708 ec53bebd-3082-4978-b11e-865c3cabbd6b
2003-08-30 14:34:17 +00:00

816 lines
35 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<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
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
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
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
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
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
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
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
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
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
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
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
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
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
Reference in New Issue View Git Blame Copy Permalink