< draft-ietf-cat-sasl-gssapi-00.txt   draft-ietf-cat-sasl-gssapi-01.txt >
Network Working Group J. Myers Network Working Group J. Myers
Internet Draft March, 1999 Internet Draft Netscape Communications
Document: draft-ietf-cat-sasl-gssapi-00.txt Document: draft-ietf-cat-sasl-gssapi-01.txt May 2000
SASL GSSAPI mechanisms SASL GSSAPI mechanisms
Status of this Memo Status of this Memo
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
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.
This document is an Internet-Draft and is in full conformance with A revised version of this draft document will be submitted to the RFC
all provisions of Section 10 of RFC2026.
A revised version of this draft document will be submitted to the RFC
editor as a Proposed Standard for the Internet Community. Discussion editor as a Proposed Standard for the Internet Community. Discussion
and suggestions for improvement are requested. and suggestions for improvement are requested.
Internet DRAFT SASL March 23, 1999 Internet DRAFT SASL May 23, 2000
1. Abstract 1. Abstract
The Simple Authentication and Security Layer [SASL] is a method for The Simple Authentication and Security Layer [SASL] is a method for
adding authentication support to connection-based protocols. This adding authentication support to connection-based protocols. This
document describes the method for using the Generic Security Service document describes the method for using the Generic Security Service
Application Program Interface [GSSAPI] in the Simple Authentication Application Program Interface [GSSAPI] in the Simple Authentication
and Security Layer [SASL]. and Security Layer [SASL].
This document amends section 7.2 of RFC 2222 [SASL], the definition This document amends section 7.2 of RFC 2222 [SASL], the definition
skipping to change at page 2, line ? skipping to change at page 2, line ?
[TODO: No examples included. Needed?] [TODO: No examples included. Needed?]
Examples in this document are for the IMAP profile [IMAP4] of this Examples in this document are for the IMAP profile [IMAP4] of this
specification. The base64 encoding of challenges and responses, as specification. The base64 encoding of challenges and responses, as
well as the "+ " preceding the responses are part of the IMAP4 well as the "+ " preceding the responses are part of the IMAP4
profile, not part of the SASL specification itself. profile, not part of the SASL specification itself.
3. Introduction and Overview 3. Introduction and Overview
Each GSSAPI mechanism used within SASL MUST have a separate SASL Each and every GSSAPI mechanism used within SASL is implicitly
mechanism registered. The registration procedure for SASL mechanisms registered by this specification.
is defined in the base SASL specification [SASL].
For backwards compatibility with existing implementations of Kerberos For backwards compatibility with existing implementations of Kerberos
V5 under SASL, the SASL mechanism name for the Kerberos V5 GSSAPI V5 and SPNEGO under SASL, the SASL mechanism name for the Kerberos V5
mechanism is "GSSAPI". The SASL mechanism name for any other GSSAPI GSSAPI mechanism [GSSAPI-KERBEROS] is "GSSAPI" and the SASL mechanism
mechanism is the concatenation of "GSS-" and the [TODO] of the GSSAPI for the SPNEGO GSSAPI mechanism [SPNEGO] is "GSS-SPNEGO". The SASL
mechanism. mechanism name for any other GSSAPI mechanism is the concatenation of
"GSS-" and the Base32 encoding of the first ten bytes of the MD5 hash
SASL mechanism names starting with "GSS-" are reserved for SASL [MD5] of the ASN.1 DER encoding [ASN1] of the GSSAPI mechanism's OID.
Base32 encoding is described later in this document
Internet DRAFT SASL March 23, 1999 Internet DRAFT SASL May 23, 2000
SASL mechanism names starting with "GSS-" are reserved for SASL
mechanisms which conform to this document. mechanisms which conform to this document.
The specification of all SASL mechanisms conforming to this document The specification of all SASL mechanisms conforming to this document
is in the "Specification common to all GSSAPI mechanisms" section of is in the "Specification common to all GSSAPI mechanisms" section of
this document. this document.
The IESG is considered to be the owner of all SASL mechanisms which The IESG is considered to be the owner of all SASL mechanisms which
conform to this document. This does NOT imply that the IESG is conform to this document. This does NOT imply that the IESG is
considered to be the owner of the underlying GSSAPI mechanism. considered to be the owner of the underlying GSSAPI mechanism.
skipping to change at page 3, line 44 skipping to change at page 3, line 45
One reason a server or client might want to violate the above SHOULD One reason a server or client might want to violate the above SHOULD
directive is if it has a policy of only using mechanisms below a directive is if it has a policy of only using mechanisms below a
certain strength if their negotiation is protected. In such a case, certain strength if their negotiation is protected. In such a case,
it would only want to negotiate those weaker mechnisms through it would only want to negotiate those weaker mechnisms through
SPNEGO. In any case, there is no down-negotiation security SPNEGO. In any case, there is no down-negotiation security
consideration with using the strongest mechanism and set of options consideration with using the strongest mechanism and set of options
the implementation supports, so for interoperability that mechanism the implementation supports, so for interoperability that mechanism
and set of options MUST be negotiable without using the "GSS-SPNEGO" and set of options MUST be negotiable without using the "GSS-SPNEGO"
mechanism. mechanism.
5. Base32 encoding
The Base32 encoding is designed to represent arbitrary sequences of
octets in a form that needs to be case insensitive but need not be
humanly readable.
A 33-character subset of US-ASCII is used, enabling 5 bits to be
represented per printable character. (The extra 33rd character, "=",
is used to signify a special processing function.)
Internet DRAFT SASL May 23, 2000
The encoding process represents 40-bit groups of input bits as output
strings of 8 encoded characters. Proceeding from left to right, a
40-bit input group is formed by concatenating 5 8bit input groups.
These 40 bits are then treated as 8 concatenated 5-bit groups, each
of which is translated into a single digit in the base32 alphabet.
When encoding a bit stream via the base32 encoding, the bit stream
must be presumed to be ordered with the most-significant-bit first.
That is, the first bit in the stream will be the high-order bit in
the first 8bit byte, and the eighth bit will be the low-order bit in
the first 8bit byte, and so on.
Each 5-bit group is used as an index into an array of 32 printable
characters. The character referenced by the index is placed in the
output string. These characters, identified in Table 1, below, are
selected from US-ASCII digits and uppercase letters.
Table 1: The Base32 Alphabet
Value Encoding Value Encoding Value Encoding Value Encoding
0 A 9 J 18 S 27 3
1 B 10 K 19 T 28 4
2 C 11 L 20 U 29 5
3 D 12 M 21 V 30 6
4 E 13 N 22 W 31 7
5 F 14 O 23 X
6 G 15 P 24 Y (pad) =
7 H 16 Q 25 Z
8 I 17 R 26 2
Special processing is performed if fewer than 40 bits are available
at the end of the data being encoded. A full encoding quantum is
always completed at the end of a body. When fewer than 40 input bits
are available in an input group, zero bits are added (on the right)
to form an integral number of 5-bit groups. Padding at the end of
the data is performed using the "=" character. Since all base32
input is an integral number of octets, only the following cases can
arise: (1) the final quantum of encoding input is an integral
multiple of 40 bits; here, the final unit of encoded output will be
an integral multiple of 4 characters with no "=" padding, (2) the
final quantum of encoding input is exactly 8 bits; here, the final
unit of encoded output will be two characters followed by six "="
padding characters, (3) the final quantum of encoding input is
exactly 16 bits; here, the final unit of encoded output will be four
characters followed by four "=" padding characters, (4) the final
quantum of encoding input is exactly 24 bits; here, the final unit of
encoded output will be five characters followed by five"=" padding
characters, or (5) the final quantum of encoding input is exactly 32
bits; here, the final unit of encoded output will be seven characters
Internet DRAFT SASL May 23, 2000
followed by one "=" padding character.
Because it is used only for padding at the end of the data, the
occurrence of any "=" characters may be taken as evidence that the
end of the data has been reached (without truncation in transit). No
such assurance is possible, however, when the number of octets
transmitted was a multiple of three and no "=" characters are
present.
Any characters outside of the base32 alphabet are to be ignored in
base32-encoded data.
6. Specification common to all GSSAPI mechanisms 6. Specification common to all GSSAPI mechanisms
Each SASL mechanism which uses a GSSAPI mechanism uses the following Each SASL mechanism which uses a GSSAPI mechanism uses the following
specification. specification.
6.1. Client side of authentication protocol exchange 6.1. Client side of authentication protocol exchange
The client calls GSS_Init_sec_context, passing in The client calls GSS_Init_sec_context, passing in
input_context_handle of 0 (initially), mech_type of the GSSAPI input_context_handle of 0 (initially), mech_type of the GSSAPI
mechanism for which this SASL mechanism is registered, and targ_name mechanism for which this SASL mechanism is registered, and targ_name
equal to output_name from GSS_Import_Name called with input_name_type equal to output_name from GSS_Import_Name called with input_name_type
Internet DRAFT SASL March 23, 1999
of GSS_C_NT_HOSTBASED_SERVICE and input_name_string of of GSS_C_NT_HOSTBASED_SERVICE and input_name_string of
"service@hostname" where "service" is the service name specified in "service@hostname" where "service" is the service name specified in
the protocol's profile, and "hostname" is the fully qualified host the protocol's profile, and "hostname" is the fully qualified host
name of the server. The client then responds with the resulting name of the server. The client then responds with the resulting
output_token. If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, output_token. If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED,
then the client should expect the server to issue a token in a then the client should expect the server to issue a token in a
subsequent challenge. The client must pass the token to another call subsequent challenge. The client must pass the token to another call
to GSS_Init_sec_context, repeating the actions in this paragraph. to GSS_Init_sec_context, repeating the actions in this paragraph.
When GSS_Init_sec_context returns GSS_S_COMPLETE, the client takes When GSS_Init_sec_context returns GSS_S_COMPLETE, the client takes
skipping to change at page 4, line 29 skipping to change at page 5, line 52
output_token, otherwise the client responds with no data. The client output_token, otherwise the client responds with no data. The client
should then expect the server to issue a token in a subsequent should then expect the server to issue a token in a subsequent
challenge. The client passes this token to GSS_Unwrap and interprets challenge. The client passes this token to GSS_Unwrap and interprets
the first octet of resulting cleartext as a bit-mask specifying the the first octet of resulting cleartext as a bit-mask specifying the
security layers supported by the server and the second through fourth security layers supported by the server and the second through fourth
octets as the maximum size output_message to send to the server. The octets as the maximum size output_message to send to the server. The
client then constructs data, with the first octet containing the client then constructs data, with the first octet containing the
bit-mask specifying the selected security layer, the second through bit-mask specifying the selected security layer, the second through
fourth octets containing in network byte order the maximum size fourth octets containing in network byte order the maximum size
output_message the client is able to receive, and the remaining output_message the client is able to receive, and the remaining
octets containing the authorization identity. The client passes the octets containing the UTF-8 encoded [UTF8] authorization identity.
data to GSS_Wrap with conf_flag set to FALSE, and responds with the The client passes the data to GSS_Wrap with conf_flag set to FALSE,
generated output_message. The client can then consider the server and responds with the generated output_message. The client can then
authenticated.
Internet DRAFT SASL May 23, 2000
consider the server authenticated.
6.2. Server side of authentication protocol exchange 6.2. Server side of authentication protocol exchange
The server passes the initial client response to The server passes the initial client response to
GSS_Accept_sec_context as input_token, setting input_context_handle GSS_Accept_sec_context as input_token, setting input_context_handle
to 0 (initially). If GSS_Accept_sec_context returns to 0 (initially). If GSS_Accept_sec_context returns
GSS_S_CONTINUE_NEEDED, the server returns the generated output_token GSS_S_CONTINUE_NEEDED, the server returns the generated output_token
to the client in challenge and passes the resulting response to to the client in challenge and passes the resulting response to
another call to GSS_Accept_sec_context, repeating the actions in this another call to GSS_Accept_sec_context, repeating the actions in this
paragraph. paragraph.
When GSS_Accept_sec_context returns GSS_S_COMPLETE, the client takes When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server takes
the following actions: If the last call to GSS_Accept_sec_context the following actions: If the last call to GSS_Accept_sec_context
returned an output_token, the server returns it to the client in a returned an output_token, the server returns it to the client in a
challenge and expects a reply from the client with no data. Whether challenge and expects a reply from the client with no data. Whether
or not an output_token was returned (and after receipt of any or not an output_token was returned (and after receipt of any
response from the client to such an output_token), the server then response from the client to such an output_token), the server then
constructs 4 octets of data, with the first octet containing a bit- constructs 4 octets of data, with the first octet containing a bit-
mask specifying the security layers supported by the server and the mask specifying the security layers supported by the server and the
second through fourth octets containing in network byte order the second through fourth octets containing in network byte order the
maximum size output_token the server is able to receive. The server maximum size output_token the server is able to receive. The server
must then pass the plaintext to GSS_Wrap with conf_flag set to FALSE must then pass the plaintext to GSS_Wrap with conf_flag set to FALSE
Internet DRAFT SASL March 23, 1999
and issue the generated output_message to the client in a challenge. and issue the generated output_message to the client in a challenge.
The server must then pass the resulting response to GSS_Unwrap and The server must then pass the resulting response to GSS_Unwrap and
interpret the first octet of resulting cleartext as the bit-mask for interpret the first octet of resulting cleartext as the bit-mask for
the selected security layer, the second through fourth octets as the the selected security layer, the second through fourth octets as the
maximum size output_message to send to the client, and the remaining maximum size output_message to send to the client, and the remaining
octets as the authorization identity. The server must verify that octets as the authorization identity. The server must verify that
the src_name is authorized to authenticate as the authorization the src_name is authorized to authenticate as the authorization
identity. After these verifications, the authentication process is identity. After these verifications, the authentication process is
complete. complete.
skipping to change at page 5, line 29 skipping to change at page 7, line 5
The security layers and their corresponding bit-masks are as follows: The security layers and their corresponding bit-masks are as follows:
1 No security layer 1 No security layer
2 Integrity protection. 2 Integrity protection.
Sender calls GSS_Wrap with conf_flag set to FALSE Sender calls GSS_Wrap with conf_flag set to FALSE
4 Privacy protection. 4 Privacy protection.
Sender calls GSS_Wrap with conf_flag set to TRUE Sender calls GSS_Wrap with conf_flag set to TRUE
Other bit-masks may be defined in the future; bits which are not Other bit-masks may be defined in the future; bits which are not
understood must be negotiated off. understood must be negotiated off.
Internet DRAFT SASL May 23, 2000
7. IANA Considerations 7. IANA Considerations
The IANA is directed to modify the existing registration for "GSSAPI" The IANA is directed to modify the existing registration for "GSSAPI"
in the "sasl-mechanisms" so that this document is listed as the in the "sasl-mechanisms" so that this document is listed as the
published specification. Add the descriptive text "This mechanism is published specification. Add the descriptive text "This mechanism is
for the Kerberos V5 mechanism of GSSAPI. Other GSSAPI mechanisms use for the Kerberos V5 mechanism of GSSAPI. Other GSSAPI mechanisms use
other SASL mechanism names, as described in this mechanism's other SASL mechanism names, as described in this mechanism's
published specification." published specification."
The IANA is advised that SASL mechanism names starting with "GSS-" The IANA is advised that SASL mechanism names starting with "GSS-"
are reserved for SASL mechanisms which conform to this document. are reserved for SASL mechanisms which conform to this document.
Internet DRAFT SASL March 23, 1999 Internet DRAFT SASL May 23, 2000
8. References 8. References
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", [ASN1] ISO/IEC 8824, "Specification of Abstract Syntax Notation One
RFC 1730, University of Washington, December 1994. (ASN.1)"
[GSSAPI] Linn, J., "Generic Security Service Application Program [GSSAPI] Linn, J., "Generic Security Service Application Program
Interface, Version 2", RFC 2078, January 1997 Interface Version 2, Update 1", RFC 2743, January 2000
[GSSAPI-KERBEROS] Linn, J., "The Kerberos Version 5 GSS-API [GSSAPI-KERBEROS] Linn, J., "The Kerberos Version 5 GSS-API
Mechanism", RFC 1964, June 1996 Mechanism", RFC 1964, June 1996
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
RFC 1730, University of Washington, December 1994.
[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997 Requirement Levels", RFC 2119, March 1997
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997 RFC 2222, October 1997
[SPNEGO] Baize, E., Pinkas., D., "The Simple and Protected GSS-API [SPNEGO] Baize, E., Pinkas., D., "The Simple and Protected GSS-API
Negotiation Mechanism", RFC 2478, December 1998 Negotiation Mechanism", RFC 2478, December 1998
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998
9. Security Considerations 9. Security Considerations
Security issues are discussed throughout this memo. Security issues are discussed throughout this memo.
When a server or client supports multiple authentication mechanisms, When a server or client supports multiple authentication mechanisms,
each of which has a different security strength, it is possible for each of which has a different security strength, it is possible for
an active attacker to cause a party to use the least secure mechanism an active attacker to cause a party to use the least secure mechanism
supported. To protect against this sort of attack, a client or supported. To protect against this sort of attack, a client or
server which supports mechanisms of different strengths should have a server which supports mechanisms of different strengths should have a
configurable minimum strength that it will use. It is not sufficient configurable minimum strength that it will use. It is not sufficient
for this minimum strength check to only be on the server, since an for this minimum strength check to only be on the server, since an
active attacker can change which mechanisms the client sees as being active attacker can change which mechanisms the client sees as being
supported, causing the client to send authentication credentials for supported, causing the client to send authentication credentials for
its weakest supported mechanism. its weakest supported mechanism.
The client's selection of a SASL mechanism is done in the clear and The client's selection of a SASL mechanism is done in the clear and
may be modified by an active attacker. It is important for any new may be modified by an active attacker. It is important for any new
SASL mechanisms to be designed such that an active attacker cannot SASL mechanisms to be designed such that an active attacker cannot
obtain an authentication with weaker security properties by modifying obtain an authentication with weaker security properties by modifying
Internet DRAFT SASL May 23, 2000
the SASL mechanism name and/or the challenges and responses. the SASL mechanism name and/or the challenges and responses.
SPNEGO [SPNEGO] has protection against many of these down-negotiation SPNEGO [SPNEGO] has protection against many of these down-negotiation
attacks, SASL does not itself have such protection. The section attacks, SASL does not itself have such protection. The section
titled "SPNEGO" mentions considerations of choosing negotiation titled "SPNEGO" mentions considerations of choosing negotiation
through SASL versus SPNEGO. through SASL versus SPNEGO.
Additional security considerations are in the SASL [SASL] and GSSAPI Additional security considerations are in the SASL [SASL] and GSSAPI
[GSSAPI] specifications. [GSSAPI] specifications.
Internet DRAFT SASL March 23, 1999
10. Author's Address 10. Author's Address
John G. Myers John G. Myers
Netscape Communications Netscape Communications
501 E. Middlefield Road 501 E. Middlefield Road
Mail Stop MV-029 Mail Stop SCA 15:201
Mountain View, CA 94043-4042 Mountain View, CA 94043-4042
Email: jgmyers@netscape.com Email: jgmyers@netscape.com
Internet DRAFT SASL March 23, 1999 Internet DRAFT SASL May 23, 2000
Appendix A. Sample code
The following is an example program which converts mechanism OIDs (of
the form "1.3.6.1.5.5.1") to SASL mechanism names. This sample
program uses the reference MD5 implementation in [MD5].
#include <stdio.h>
#include "md5.h"
unsigned long parsenum(char **ptr)
{
unsigned long rval = 0;
while (**ptr >= '0' && **ptr <= '9') {
rval = rval * 10 + *(*ptr)++ - '0';
}
return rval;
}
void encode(unsigned long val, unsigned char **buf)
{
unsigned long tmpval;
int noctets = 1;
for (tmpval = val; tmpval >= 128; tmpval >>= 7) noctets++;
while (--noctets) {
*(*buf)++ = ((val >> (7 * noctets)) & 0x7f) | 0x80;
}
*(*buf)++ = val & 0x7f;
}
static char basis_32[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ234567";
void base32encode10(unsigned char *buf)
{
int len = 10;
while (len) {
putc(basis_32[buf[0] >> 3], stdout);
putc(basis_32[((buf[0] & 7) << 2) | (buf[1] >> 6)], stdout);
putc(basis_32[(buf[1] & 0x3f) >> 1], stdout);
putc(basis_32[((buf[1] & 1) << 4) | (buf[2] >> 4)], stdout);
putc(basis_32[((buf[2] & 0xf) << 1) | (buf[3] >> 7)], stdout);
putc(basis_32[(buf[3] & 0x7f) >> 2], stdout);
putc(basis_32[((buf[3] & 3) << 3) | (buf[4] >> 5)], stdout);
putc(basis_32[(buf[4] & 0x1f)], stdout);
len -= 5;
}
}
main(int argc, char **argv)
Internet DRAFT SASL May 23, 2000
{
char *oidstr;
unsigned long val1, val2;
unsigned char asn1buf[1024]; /* Had better be big enough */
unsigned char *asn1next = asn1buf;
unsigned char *asn1lennext;
unsigned char *p;
MD5_CTX md5ctx;
unsigned char md5buf[16];
if (argc != 2) {
fprintf(stderr, "usage: %s oid\n", argv[0]);
exit(1);
}
oidstr = argv[1];
val1 = parsenum(&oidstr);
if (*oidstr++ != '.') goto badoid;
val2 = parsenum(&oidstr);
if (*oidstr && *oidstr++ != '.') goto badoid;
*asn1next++ = val1 * 40 + val2;
while (*oidstr) {
val1 = parsenum(&oidstr);
if (*oidstr && *oidstr++ != '.') goto badoid;
encode(val1, &asn1next);
}
/* Now that we know the length of the OID, generate the tag
* and length
*/
asn1lennext = asn1next;
*asn1lennext++ = 6;
encode(asn1next - asn1buf, &asn1lennext);
printf("ASN.1 DER encoding: ");
for (p = asn1next; p < asn1lennext; p++) {
printf("%02x ", *p);
}
for (p = asn1buf; p < asn1next; p++) {
printf("%02x ", *p);
}
printf("\n");
MD5Init(&md5ctx);
MD5Update(&md5ctx, (unsigned char *)asn1next, asn1lennext - asn1next);
MD5Update(&md5ctx, (unsigned char *)asn1buf, asn1next - asn1buf);
Internet DRAFT SASL May 23, 2000
MD5Final(md5buf, &md5ctx);
printf("MD5 hash: ");
for (p = md5buf; p < md5buf + 16; p++) {
printf("%02x ", *p);
}
printf("\n");
printf("SASL mechanism name: GSS-");
base32encode10(md5buf);
printf("\n");
exit(0);
badoid:
fprintf(stderr, "incorrect oid syntax\n");
exit(1);
}
Internet DRAFT SASL May 23, 2000
Table of Contents Table of Contents
Status of this Memo ............................................... i Status of this Memo ............................................... i
1. Abstract .................................................... 2 1. Abstract .................................................... 2
2. Organization of this Document ............................... 2 2. Organization of this Document ............................... 2
2.1. How to Read This Document ................................... 2 2.1. How to Read This Document ................................... 2
2.2. Conventions Used in this Document ........................... 2 2.2. Conventions Used in this Document ........................... 2
2.3. Examples .................................................... 2 2.3. Examples .................................................... 2
3. Introduction and Overview ................................... 2 3. Introduction and Overview ................................... 2
4. SPNEGO ...................................................... 3 4. SPNEGO ...................................................... 3
6. Specification common to all GSSAPI mechanisms ............... 3 5. Base32 encoding ............................................. 3
6.1. Client side of authentication protocol exchange ............. 3 6. Specification common to all GSSAPI mechanisms ............... 5
6.2. Server side of authentication protocol exchange ............. 4 6.1. Client side of authentication protocol exchange ............. 5
6.3. Security layer .............................................. 5 6.2. Server side of authentication protocol exchange ............. 6
7. IANA Considerations ......................................... 5 6.3. Security layer .............................................. 6
8. References .................................................. 6 7. IANA Considerations ......................................... 7
9. Security Considerations ..................................... 6 8. References .................................................. 8
10. Author's Address ............................................ 7 9. Security Considerations ..................................... 8
10. Author's Address ............................................ 9
Appendix A. Sample code ........................................... 10
 End of changes. 25 change blocks. 
36 lines changed or deleted 243 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/