draft-ietf-kitten-gss-loop-01.txt   draft-ietf-kitten-gss-loop-02.txt 
Network Working Group B. Kaduk Network Working Group B. Kaduk
Internet-Draft MIT Internet-Draft MIT
Intended status: Informational November 19, 2014 Intended status: Informational December 8, 2014
Expires: May 23, 2015 Expires: June 11, 2015
Structure of the GSS Negotiation Loop Structure of the GSS Negotiation Loop
draft-ietf-kitten-gss-loop-01 draft-ietf-kitten-gss-loop-02
Abstract Abstract
This document specifies the generic structure of the negotiation loop This document specifies the generic structure of the negotiation loop
to establish a GSS security context between initiator and acceptor. to establish a GSS security context between initiator and acceptor.
The control flow of the loop is indicated for both parties, including The control flow of the loop is indicated for both parties, including
error conditions, and indications are given for where application- error conditions, and indications are given for where application-
specific behavior must be specified. specific behavior must be specified.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on May 23, 2015. This Internet-Draft will expire on June 11, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 16 skipping to change at page 3, line 16
which is useful for applications but is not mandated by [RFC2743]. which is useful for applications but is not mandated by [RFC2743].
2. Application Protocol Requirements 2. Application Protocol Requirements
Part of the purpose of this document is to guide the development of Part of the purpose of this document is to guide the development of
new application protocols using the GSS-API, as well as the new application protocols using the GSS-API, as well as the
development of new application software using such protocols. The development of new application software using such protocols. The
following list is features which are necessary or useful in such an following list is features which are necessary or useful in such an
application protocol: application protocol:
A way to frame and identify the initial context negotiation tokens o A way to frame and identify security context negotiation tokens in
in the loop. the loop.
A way to frame and identify subsequent context-level tokens (e.g., o Error tokens should generally also get special framing, as the
error tokens) after a GSS_S_COMPLETE return. recipient may have no other way to distinguish unexpected error
context tokens from per-message tokens.
Failing that, a way to indicate error status from one peer to the o Failing that, a way to indicate error status from one peer to the
other, possibly accompanied by a descriptive string. other, possibly accompanied by a descriptive string.
A protocol may use the negotiated GSS security context for per- o A protocol may use the negotiated GSS security context for per-
message operations; in such cases, the protocol will need a way to message operations; in such cases, the protocol will need a way to
frame and identify those per-message tokens and the nature of frame and identify those per-message tokens and the nature of
their contents. For example, a protocol message may be their contents. For example, a protocol message may be
accompanied by the output of GSS_GetMIC() over that message; the accompanied by the output of GSS_GetMIC() over that message; the
protocol must identify the location and size of that MIC token, protocol must identify the location and size of that MIC token,
and indicate that it is a MIC token and what cleartext it and indicate that it is a MIC token and what cleartext it
corresponds to. corresponds to.
The application (not the protocol) should provide for o Applications are responsible for authorization of the
authorization checks in the acceptor. The GSS-API authenticates authenticated peer principal names which are supplied by the GSS-
the initiator, but does not make any claim about whether the API. Such names are mechanism-specific, and may come from a
initiator is authorized for any given operation. In particular, different portion of a federated identity scheme. Application
the initiator may be from a different portion of a federated protocols may need to supply additional information to support the
identity scheme. authorization of access to a given resource, such as the SSHv2
"username" parameter.
3. Loop Structure 3. Loop Structure
The loop is begun by the appropriately named initiator, which calls The loop is begun by the appropriately named initiator, which calls
GSS_Init_sec_context() with an empty (zero-length) input_token and a GSS_Init_sec_context() with an empty (zero-length) input_token and a
fixed set of input flags containing the desired attributes for the fixed set of input flags containing the desired attributes for the
security context. The initiator should not change any of the input security context. The initiator should not change any of the input
parameters to GSS_Init_sec_context() between calls to it during the parameters to GSS_Init_sec_context() between calls to it during the
loop, with the exception of the input_token parameter, which will loop, with the exception of the input_token parameter, which will
contain a message from the acceptor after the initial call, and the contain a message from the acceptor after the initial call, and the
skipping to change at page 6, line 4 skipping to change at page 6, line 4
indicate such errors. For example, if the acceptor is a stateless or indicate such errors. For example, if the acceptor is a stateless or
near-stateless UDP server, there is probably no need for the near-stateless UDP server, there is probably no need for the
initiator to explicitly indicate its failure to the acceptor. initiator to explicitly indicate its failure to the acceptor.
Conditions such as this can be treated in individual application Conditions such as this can be treated in individual application
protocol specifications. protocol specifications.
If a regular security context output_token is produced by the call to If a regular security context output_token is produced by the call to
GSS_Init_sec_context(), the initiator must transmit this token to the GSS_Init_sec_context(), the initiator must transmit this token to the
acceptor over the application's communication channel. If the call acceptor over the application's communication channel. If the call
to GSS_Init_sec_context() returns an error token as output_token, it to GSS_Init_sec_context() returns an error token as output_token, it
is recommended that the intiator transmit this token to the acceptor is recommended that the initiator transmit this token to the acceptor
over the application's communication channel. over the application's communication channel.
3.4. Acceptor Sanity Checking 3.4. Acceptor Sanity Checking
The acceptor's half of the negotiation loop is triggered by the The acceptor's half of the negotiation loop is triggered by the
receipt of a context token from the initiator. Before calling receipt of a context token from the initiator. Before calling
GSS_Accept_sec_context(), the acceptor may find it useful to perform GSS_Accept_sec_context(), the acceptor may find it useful to perform
some sanity checks on the state of the negotiation loop. some sanity checks on the state of the negotiation loop.
If the acceptor receives a context token but was not expecting such a If the acceptor receives a context token but was not expecting such a
skipping to change at page 9, line 27 skipping to change at page 9, line 27
mutual_state, replay_det_state, sequence_state, anon_state, mutual_state, replay_det_state, sequence_state, anon_state,
trans_state, conf_avail, and integ_avail, and any additional flags trans_state, conf_avail, and integ_avail, and any additional flags
added by extensions to the GSS-API. The acceptor must verify that added by extensions to the GSS-API. The acceptor must verify that
any flags necessary for the application protocol are set. If a any flags necessary for the application protocol are set. If a
necessary flag is not set, the acceptor must destroy the security necessary flag is not set, the acceptor must destroy the security
context and not use the security context for application traffic. context and not use the security context for application traffic.
4.1. Authorization Checks 4.1. Authorization Checks
The acceptor receives as one of the outputs of The acceptor receives as one of the outputs of
GSS_Accpet_sec_context() the name of the initiator which has GSS_Accept_sec_context() the name of the initiator which has
authenticated during the security context negotiation. Applications authenticated during the security context negotiation. Applications
need to implement authorization checks on this received name need to implement authorization checks on this received name
('client_name' in the sample code) before providing access to ('client_name' in the sample code) before providing access to
restricted resources. In particular, security context negotiation restricted resources. In particular, security context negotiation
can be successful when the client is anonymous or is from a different can be successful when the client is anonymous or is from a different
identity realm than the acceptor, depending on the details of the identity realm than the acceptor, depending on the details of the
mechanism used by the GSS-API to establish the security context. mechanism used by the GSS-API to establish the security context.
Acceptor applications can check which target name was used by the Acceptor applications can check which target name was used by the
initiator, but the details are out of scope for this document. See initiator, but the details are out of scope for this document. See
[RFC2743] sections 2.2.6 and 1.1.5. Additional information can be [RFC2743] sections 2.2.6 and 1.1.5. Additional information can be
skipping to change at page 10, line 5 skipping to change at page 10, line 5
For mechanism/flag combinations that require multiple token For mechanism/flag combinations that require multiple token
exchanges, the GSS-API specification [RFC2743] provides a exchanges, the GSS-API specification [RFC2743] provides a
prot_ready_state output value from GSS_Init_sec_context() and prot_ready_state output value from GSS_Init_sec_context() and
GSS_Accept_sec_context(), which indicates when per-message operations GSS_Accept_sec_context(), which indicates when per-message operations
are available. However, many mechanism implementations do not are available. However, many mechanism implementations do not
provide this functionality, and the analysis of the security provide this functionality, and the analysis of the security
consequences of its use is rather complicated, so it is not expected consequences of its use is rather complicated, so it is not expected
to be useful in most application protocols. to be useful in most application protocols.
In particular, mutual authentication (if requested) is not guaranteed In particular, mutual authentication, replay protection, and other
until GSS_S_COMPLETE is returned. That is, an attacker could cause services (if requested) are services which will be active when
messages to be protected to the attacker instead of the actual GSS_S_COMPLETE is returned, but which are not necessarily active
target, followed by a context establishment failure. Accordingly, before the security context is fully established.
application protocols should not put sensitive information into
messages sent during security context establishment.
4.3. Additional Context Tokens 4.3. Additional Context Tokens
Under some conditions, a context token will be received by a party to Under some conditions, a context token will be received by a party to
a security context negotiation after that party has completed the a security context negotiation after that party has completed the
negotiation (i.e., after GSS_Init_sec_context() or negotiation (i.e., after GSS_Init_sec_context() or
GSS_Accept_sec_context() has returned GSS_S_COMPLETE). Such tokens GSS_Accept_sec_context() has returned GSS_S_COMPLETE). Such tokens
must be passed to GSS_Process_context_token() for processing. It may must be passed to GSS_Process_context_token() for processing. It may
not always be necessary for a mechanism implementation to generate an not always be necessary for a mechanism implementation to generate an
error token on the intiator side, or for an initiator application to error token on the initiator side, or for an initiator application to
transmit that token to the acceptor, but such decisions are out of transmit that token to the acceptor; such decisions are out of scope
scope for this document. Both peers should always be prepared to for this document. Both peers should always be prepared to process
process such tokens, and application protocols should provide means such tokens, and application protocols should provide means by which
by which they can be transmitted. they can be transmitted.
Such tokens can be security context deletion tokens, emitted when the Such tokens can be security context deletion tokens, emitted when the
remote party called GSS_Delete_sec_context() with a non-null remote party called GSS_Delete_sec_context() with a non-null
output_context_token parameter, or error tokens, emitted when the output_context_token parameter, or error tokens, emitted when the
remote party experiences an error processing the last token in a remote party experiences an error processing the last token in a
security context negotiation exchange. Errors experienced when security context negotiation exchange. Errors experienced when
processing tokens earlier in the negotiation would be transmitted as processing tokens earlier in the negotiation would be transmitted as
normal security context tokens and processed by normal security context tokens and processed by
GSS_Init_sec_context() or GSS_Accept_sec_context(), as appropriate. GSS_Init_sec_context() or GSS_Accept_sec_context(), as appropriate.
With the GSS-API version 2, it is not recommended to use security With the GSS-API version 2, it is not recommended to use security
context deletion tokens, so error tokens are expected to be the most context deletion tokens, so error tokens are expected to be the most
common form of additional context token, for new application common form of additional context token for new application
protocols. protocols.
GSS_Process_context_token() may indicate an error in its major_status GSS_Process_context_token() may indicate an error in its major_status
field if an error is encountered locally during token processing, or field if an error is encountered locally during token processing, or
to indicate that an error was encountered on the peer and conveyed in to indicate that an error was encountered on the peer and conveyed in
an error token. Regardless of the major_status output of an error token. [RFC2743E4151] Regardless of the major_status output
GSS_Process_context_token(), GSS_Inquire_context() should be used of GSS_Process_context_token(), GSS_Inquire_context() should be used
after processing the extra token, to query the status of the security after processing the extra token, to query the status of the security
context and whether it can supply the features necessary for the context and whether it can supply the features necessary for the
application protocol. application protocol.
At present, all tokens which should be handled by At present, all tokens which should be handled by
GSS_Process_context_token() will lead to the security context being GSS_Process_context_token() will lead to the security context being
effectively unusable. Future extensions to the GSS-API may allow for effectively unusable. Future extensions to the GSS-API may allow for
applications to continue to function after a call to applications to continue to function after a call to
GSS_Process_context_token(), and it is expected that the outputs of GSS_Process_context_token(), and it is expected that the outputs of
GSS_Inquire_context() will indicate whether it is safe to do so. GSS_Inquire_context() will indicate whether it is safe to do so.
skipping to change at page 15, line 19 skipping to change at page 15, line 15
ret = receive_token(readfd, &input_token); ret = receive_token(readfd, &input_token);
if (ret != 0) if (ret != 0)
goto cleanup; goto cleanup;
} else if (major == GSS_S_COMPLETE) { } else if (major == GSS_S_COMPLETE) {
initiator_established = 1; initiator_established = 1;
} else { } else {
/* This situation is forbidden by RFC 2743. Bail out. */ /* This situation is forbidden by RFC 2743. Bail out. */
warnx("major not complete or continue but not error\n"); warnx("major not complete or continue but not error\n");
goto cleanup; goto cleanup;
} }
} /* while(!initiator_established) */ } /* while (!initiator_established) */
if ((ret_flags & req_flags) != req_flags) { if ((ret_flags & req_flags) != req_flags) {
warnx("Negotiated context does not support requested flags\n"); warnx("Negotiated context does not support requested flags\n");
goto cleanup; goto cleanup;
} }
printf("Initiator's context negotiation successful\n"); printf("Initiator's context negotiation successful\n");
cleanup: cleanup:
/* We are required to release storage for nonzero-length output /* We are required to release storage for nonzero-length output
* tokens. gss_release_buffer() zeros the length, so we are * tokens. gss_release_buffer() zeros the length, so we are
* will not attempt to release the same buffer twice. */ * will not attempt to release the same buffer twice. */
if (output_token.length > 0) if (output_token.length > 0)
skipping to change at page 15, line 43 skipping to change at page 15, line 39
(void)gss_release_name(&minor, &target_name); (void)gss_release_name(&minor, &target_name);
} }
/* /*
* Perform authorization checks on the initiator's GSS name object. * Perform authorization checks on the initiator's GSS name object.
* *
* Returns 0 on success (the initiator is authorized) and nonzero * Returns 0 on success (the initiator is authorized) and nonzero
* when the initiator is not authorized. * when the initiator is not authorized.
*/ */
static int static int
check_authz(gss_name_t *client_name) check_authz(gss_name_t client_name)
{ {
/* /*
* Supply authorization checking code here. * Supply authorization checking code here.
* *
* Options include bitwise comparison of the exported name against * Options include bitwise comparison of the exported name against
* a local database, and introspection against name attributes. * a local database, and introspection against name attributes.
*/ */
return 0; return 0;
} }
static void static void
do_acceptor(int readfd, int writefd) do_acceptor(int readfd, int writefd)
{ {
int acceptor_established = 0, ret; int acceptor_established = 0, ret;
gss_ctx_id_t ctx = GSS_C_NO_CONTEXT; gss_ctx_id_t ctx = GSS_C_NO_CONTEXT;
OM_uint32 major, minor, ret_flags; OM_uint32 major, minor, ret_flags;
gss_buffer_desc input_token = GSS_C_EMPTY_BUFFER; gss_buffer_desc input_token = GSS_C_EMPTY_BUFFER;
gss_buffer_desc output_token = GSS_C_EMPTY_BUFFER; gss_buffer_desc output_token = GSS_C_EMPTY_BUFFER;
skipping to change at page 16, line 19 skipping to change at page 16, line 14
{ {
int acceptor_established = 0, ret; int acceptor_established = 0, ret;
gss_ctx_id_t ctx = GSS_C_NO_CONTEXT; gss_ctx_id_t ctx = GSS_C_NO_CONTEXT;
OM_uint32 major, minor, ret_flags; OM_uint32 major, minor, ret_flags;
gss_buffer_desc input_token = GSS_C_EMPTY_BUFFER; gss_buffer_desc input_token = GSS_C_EMPTY_BUFFER;
gss_buffer_desc output_token = GSS_C_EMPTY_BUFFER; gss_buffer_desc output_token = GSS_C_EMPTY_BUFFER;
gss_name_t client_name; gss_name_t client_name;
major = GSS_S_CONTINUE_NEEDED; major = GSS_S_CONTINUE_NEEDED;
while(!acceptor_established) { while (!acceptor_established) {
if (major & GSS_S_CONTINUE_NEEDED) { if (major & GSS_S_CONTINUE_NEEDED) {
ret = receive_token(readfd, &input_token); ret = receive_token(readfd, &input_token);
if (ret != 0) if (ret != 0)
goto cleanup; goto cleanup;
} else if (major == GSS_S_COMPLETE) { } else if (major == GSS_S_COMPLETE) {
acceptor_established = 1; acceptor_established = 1;
break; break;
} else { } else {
/* This situation is forbidden by RFC 2743. Bail out. */ /* This situation is forbidden by RFC 2743. Bail out. */
warnx("major not complete or continue but not error\n"); warnx("major not complete or continue but not error\n");
skipping to change at page 17, line 19 skipping to change at page 17, line 15
* error tokens. */ * error tokens. */
if (GSS_ERROR(major)) { if (GSS_ERROR(major)) {
warnx("gss_accept_sec_context() error major 0x%x\n", major); warnx("gss_accept_sec_context() error major 0x%x\n", major);
goto cleanup; goto cleanup;
} }
/* Free the output token's storage; we don't need it anymore. /* Free the output token's storage; we don't need it anymore.
* gss_release_buffer() is safe to call on the output buffer * gss_release_buffer() is safe to call on the output buffer
* from gss_accept_sec_context(), even if there is no storage * from gss_accept_sec_context(), even if there is no storage
* associated with that buffer. */ * associated with that buffer. */
(void)gss_release_buffer(&minor, &output_token); (void)gss_release_buffer(&minor, &output_token);
} /* while(!acceptor_established) */ } /* while (!acceptor_established) */
if (!(ret_flags & GSS_C_INTEG_FLAG)) { if (!(ret_flags & GSS_C_INTEG_FLAG)) {
warnx("Negotiated context does not support integrity\n"); warnx("Negotiated context does not support integrity\n");
goto cleanup; goto cleanup;
} }
printf("Acceptor's context negotiation successful\n"); printf("Acceptor's context negotiation successful\n");
ret = check_authz(&client_name); ret = check_authz(client_name);
if (ret != 0) if (ret != 0)
printf("Client is not authorized; rejecting access\n"); printf("Client is not authorized; rejecting access\n");
cleanup: cleanup:
release_buffer(&input_token); release_buffer(&input_token);
/* We are required to release storage for nonzero-length output /* We are required to release storage for nonzero-length output
* tokens. gss_release_buffer() zeros the length, so we are * tokens. gss_release_buffer() zeros the length, so we are
* will not attempt to release the same buffer twice. */ * will not attempt to release the same buffer twice. */
if (output_token.length > 0) if (output_token.length > 0)
(void)gss_release_buffer(&minor, &output_token); (void)gss_release_buffer(&minor, &output_token);
/* Do not request a context deletion token, pass NULL. */ /* Do not request a context deletion token, pass NULL. */
skipping to change at page 18, line 20 skipping to change at page 18, line 14
6. Security Considerations 6. Security Considerations
This document provides a (reasonably) concise description and example This document provides a (reasonably) concise description and example
for correct construction of the GSS-API security context negotiation for correct construction of the GSS-API security context negotiation
loop. Since everything relating to the construction and use of a GSS loop. Since everything relating to the construction and use of a GSS
security context is security-related, there are security-relevant security context is security-related, there are security-relevant
considerations throughout the document. It is useful to call out a considerations throughout the document. It is useful to call out a
few things in this section, though. few things in this section, though.
The GSS-API uses a request-and-check model for features. An The GSS-API uses a request-and-check model for features. An
application using the GSS-API requests that certain features application using the GSS-API requests certain features
(confidentiality protection for messages, or anonymity), but such a (confidentiality protection for messages, or anonymity), but such a
request does not require the GSS implementation to provide that request does not require the GSS implementation to provide that
feature. The application must check the returned flags to verify feature. The application must check the returned flags to verify
whether a requested feature is present; if the feature was non- whether a requested feature is present; if the feature was non-
optional for the application, the application must generate an error. optional for the application, the application must generate an error.
Phrased differently, the GSS-API will not generate an error if it is Phrased differently, the GSS-API will not generate an error if it is
unable to satisfy the features requested by the application. unable to satisfy the features requested by the application.
In many cases it is convenient for GSS acceptors to accept security In many cases it is convenient for GSS acceptors to accept security
context using multiple acceptor names (such as by using the default contexts using multiple acceptor names (such as by using the default
credential set, as happens when GSS_C_NO_CREDENTIAL is passed to credential set, as happens when GSS_C_NO_CREDENTIAL is passed to
GSS_Accept_sec_context()). This allows acceptors to use any GSS_Accept_sec_context()). This allows acceptors to use any
credentials to which it has access for accepting security contexts, credentials to which it has access for accepting security contexts,
which may not be the desired behavior for a given application. (For which may not be the desired behavior for a given application. (For
example, sshd may only wish to accept only using GSS_C_NT_HOSTBASED example, sshd may only wish to accept only using GSS_C_NT_HOSTBASED
credentials of the form host@<hostname>, and not nfs@<hostname>.) credentials of the form host@<hostname>, and not nfs@<hostname>.)
Acceptor applications can check which target name was used by the Acceptor applications can check which target name was used by the
initiator, but the details are out of scope for this document. See initiator, but the details are out of scope for this document. See
[RFC2743] sections 2.2.6 and 1.1.5. [RFC2743] sections 2.2.6 and 1.1.5.
The C sample code uses the macro GSS_ERROR() to assess the return The C sample code uses the macro GSS_ERROR() to assess the return
value of gss_init_sec_context() and gss_accept_sec_context(). This value of gss_init_sec_context() and gss_accept_sec_context(). This
is done to indicate where checks are needed in writing code for other is done to indicate where checks are needed in writing code for other
languages and what the nature of those checks might be. The C code languages and what the nature of those checks might be. The C code
could be made simpler by omitting that macro. Use of the GSS_ERROR() could be made simpler by omitting that macro. In applications
macro on the results of GSS-API per-message operations has resulted
in security vulnerabilities in existing software! In applications
expecting to receive protected octet streams, this macro should not expecting to receive protected octet streams, this macro should not
be used on the result of per-message operations, as it omits checking be used on the result of per-message operations, as it omits checking
for supplementary status values such as GSS_S_DUPLICATE_TOKEN, for supplementary status values such as GSS_S_DUPLICATE_TOKEN,
GSS_S_OLD_TOKEN, etc.. GSS_S_OLD_TOKEN, etc.. Use of the GSS_ERROR() macro on the results
of GSS-API per-message operations has resulted in security
vulnerabilities in existing software!
The security considerations from RFCs 2743 and 2744 remain applicable
to consumers of this document.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] 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.
[RFC2744] Wray, J., "Generic Security Service API Version 2 : [RFC2744] Wray, J., "Generic Security Service API Version 2 :
C-bindings", RFC 2744, January 2000. C-bindings", RFC 2744, January 2000.
skipping to change at page 19, line 48 skipping to change at page 19, line 48
4752, November 2006. 4752, November 2006.
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997. Specification", RFC 2203, September 1997.
[RFC6680] Williams, N., Johansson, L., Hartman, S., and S. [RFC6680] Williams, N., Johansson, L., Hartman, S., and S.
Josefsson, "Generic Security Service Application Josefsson, "Generic Security Service Application
Programming Interface (GSS-API) Naming Extensions", RFC Programming Interface (GSS-API) Naming Extensions", RFC
6680, August 2012. 6680, August 2012.
[RFC2743E4151]
Williams, N., "RFC 2743 Errata 4151", November 2014.
Appendix A. Acknowledgements Appendix A. Acknowledgements
Thanks to Nico Williams and Jeff Hutzleman for prompting me to write Thanks to Nico Williams and Jeff Hutzleman for prompting me to write
this document. this document.
Author's Address Author's Address
Benjamin Kaduk Benjamin Kaduk
MIT Kerberos Consortium MIT Kerberos Consortium
 End of changes. 25 change blocks. 
44 lines changed or deleted 49 lines changed or added

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