draft-ietf-kitten-gss-loop-04.txt   draft-ietf-kitten-gss-loop-05.txt 
Network Working Group B. Kaduk Network Working Group B. Kaduk
Internet-Draft MIT Internet-Draft MIT
Intended status: Informational January 4, 2015 Intended status: Informational February 19, 2015
Expires: July 8, 2015 Expires: August 23, 2015
Structure of the GSS Negotiation Loop Structure of the GSS Negotiation Loop
draft-ietf-kitten-gss-loop-04 draft-ietf-kitten-gss-loop-05
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 July 8, 2015. This Internet-Draft will expire on August 23, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 2, line 12 skipping to change at page 2, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Application Protocol Requirements . . . . . . . . . . . . . . 3 2. Application Protocol Requirements . . . . . . . . . . . . . . 3
3. Loop Structure . . . . . . . . . . . . . . . . . . . . . . . 4 3. Loop Structure . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Anonymous Initiators . . . . . . . . . . . . . . . . . . 4 3.1. Anonymous Initiators . . . . . . . . . . . . . . . . . . 4
3.2. GSS_Init_sec_context . . . . . . . . . . . . . . . . . . 5 3.2. GSS_Init_sec_context . . . . . . . . . . . . . . . . . . 5
3.3. Sending from Initiator to Acceptor . . . . . . . . . . . 5 3.3. Sending from Initiator to Acceptor . . . . . . . . . . . 6
3.4. Acceptor Sanity Checking . . . . . . . . . . . . . . . . 6 3.4. Acceptor Sanity Checking . . . . . . . . . . . . . . . . 6
3.5. GSS_Accept_sec_context . . . . . . . . . . . . . . . . . 7 3.5. GSS_Accept_sec_context . . . . . . . . . . . . . . . . . 7
3.6. Sending from Acceptor to Initiator . . . . . . . . . . . 8 3.6. Sending from Acceptor to Initiator . . . . . . . . . . . 8
3.7. Initiator input validation . . . . . . . . . . . . . . . 8 3.7. Initiator input validation . . . . . . . . . . . . . . . 8
3.8. Continue the Loop . . . . . . . . . . . . . . . . . . . . 9 3.8. Continue the Loop . . . . . . . . . . . . . . . . . . . . 9
4. After Security Context Negotiation . . . . . . . . . . . . . 9 4. After Security Context Negotiation . . . . . . . . . . . . . 9
4.1. Authorization Checks . . . . . . . . . . . . . . . . . . 10 4.1. Authorization Checks . . . . . . . . . . . . . . . . . . 10
4.2. Using Partially Complete Security Contexts . . . . . . . 10 4.2. Using Partially Complete Security Contexts . . . . . . . 10
4.3. Additional Context Tokens . . . . . . . . . . . . . . . . 10 4.3. Additional Context Tokens . . . . . . . . . . . . . . . . 10
5. Sample Code . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Sample Code . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. GSS Application Sample Code . . . . . . . . . . . . . . . 12 5.1. GSS Application Sample Code . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informational References . . . . . . . . . . . . . . . . 19 8.2. Informational References . . . . . . . . . . . . . . . . 20
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The Generic Security Service Application Program Interface version 2 The Generic Security Service Application Program Interface version 2
[RFC2743] provides a generic interface for security services, in the [RFC2743] provides a generic interface for security services, in the
form of an abstraction layer over the underlying security mechanisms form of an abstraction layer over the underlying security mechanisms
that an application may use. A GSS initiator and acceptor exchange that an application may use. A GSS initiator and acceptor exchange
messages, called tokens, until a security context is established. messages, called tokens, until a security context is established.
Such a security context allows for each party to authenticate the Such a security context allows for each party to authenticate the
other, the passing of confidential and/or integrity-protected other, the passing of confidential and/or integrity-protected
skipping to change at page 5, line 11 skipping to change at page 5, line 11
GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED), the initiator must verify GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED), the initiator must verify
that the output value of anon_state from GSS_Init_sec_context() is that the output value of anon_state from GSS_Init_sec_context() is
true before sending the security context token to the acceptor. true before sending the security context token to the acceptor.
Failing to perform this check could cause the initiator to lose Failing to perform this check could cause the initiator to lose
anonymity. anonymity.
3.2. GSS_Init_sec_context 3.2. GSS_Init_sec_context
The initiator calls GSS_Init_sec_context(), using the The initiator calls GSS_Init_sec_context(), using the
input_context_handle for the current proto-security-context and its input_context_handle for the current security context being
fixed set of input parameters, and the input_token received from the established and its fixed set of input parameters, and the
acceptor (if not the first iteration of the loop). The presence or input_token received from the acceptor (if this is not the first
absence of a nonempty output_token and the value of the major status iteration of the loop). The presence or absence of a nonempty
code are the indicators for how to proceed: output_token and the value of the major status code are the
indicators for how to proceed:
o If the major status code is GSS_S_COMPLETE and the output_token is o If the major status code is GSS_S_COMPLETE and the output_token is
empty, then the context negotiation is fully complete and ready empty, then the context negotiation is fully complete and ready
for use by the initiator with no further actions. for use by the initiator with no further actions.
o If the major status code is GSS_S_COMPLETE and the output_token is o If the major status code is GSS_S_COMPLETE and the output_token is
nonempty, then the initiator's portion of the security context nonempty, then the initiator's portion of the security context
negotiation is complete but the acceptor's is not. The initiator negotiation is complete but the acceptor's is not. The initiator
must send the output_token to the acceptor so that the acceptor must send the output_token to the acceptor so that the acceptor
can establish its half of the security context. can establish its half of the security context.
o If the major status code is GSS_S_CONTINUE_NEEDED and the o If the major status code is GSS_S_CONTINUE_NEEDED and the
output_token is nonempty, the context negotiation is incomplete. output_token is nonempty, the context negotiation is incomplete.
The initiator must send the output_token to the acceptor and await The initiator must send the output_token to the acceptor and await
another input_token from the acceptor. another input_token from the acceptor.
o If the major status code is GSS_S_CONTINUE_NEEDED and the o If the major status code is GSS_S_CONTINUE_NEEDED and the
output_token is empty, the mechanism has produced an output which output_token is empty, the mechanism has produced an output which
is not compliant with [RFC2743]. However, there are some known is not compliant with [RFC2743]. However, there are some known
implementations of certain mechanisms which do produce empty implementations of certain mechanisms such as NTLMSSP [NTLMSSP]
context negotiation tokens. For maximum interoperability, which do produce empty context negotiation tokens. For maximum
applications should be prepared to accept such tokens, and should interoperability, applications should be prepared to accept such
transmit them to the acceptor if they are generated. tokens, and should transmit them to the acceptor if they are
generated.
o If the major status code is any other value, the context o If the major status code is any other value, the context
negotiation has failed. If the output_token is nonempty, it is an negotiation has failed. If the output_token is nonempty, it is an
error token, and the initiator should send it to the acceptor. If error token, and the initiator should send it to the acceptor. If
the output_token is empty, then the initiator should indicate the the output_token is empty, then the initiator should indicate the
failure to the acceptor if an appropriate application-protocol failure to the acceptor if an appropriate application-protocol
channel to do so is available. channel to do so is available.
3.3. Sending from Initiator to Acceptor 3.3. Sending from Initiator to Acceptor
skipping to change at page 6, line 45 skipping to change at page 7, line 4
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
token (for example, if the acceptor's previous call to token (for example, if the acceptor's previous call to
GSS_Accept_sec_context() returned GSS_S_COMPLETE), this is probably GSS_Accept_sec_context() returned GSS_S_COMPLETE), this is probably
an error condition indicating that the initiator's state is invalid. an error condition indicating that the initiator's state is invalid.
See Section 4.3 for some exceptional cases. It is likely appropriate See Section 4.3 for some exceptional cases. It is likely appropriate
for the acceptor to report this error condition to the acceptor via for the acceptor to report this error condition to the initiator via
the application's communication channel. the application's communication channel.
If the acceptor is expecting a context token (e.g., if the previous If the acceptor is expecting a context token (e.g., if the previous
call to GSS_Accept_sec_context() returned GSS_S_CONTINUE_NEEDED), but call to GSS_Accept_sec_context() returned GSS_S_CONTINUE_NEEDED), but
does not receive such a token within a reasonable amount of time does not receive such a token within a reasonable amount of time
after transmitting the previous output_token to the initiator, the after transmitting the previous output_token to the initiator, the
acceptor should assume that the initiator's state is invalid (time acceptor should assume that the initiator's state is invalid (time
out) and fail the GSS negotiation. Again, it is likely appropriate out) and fail the GSS negotiation. Again, it is likely appropriate
for the acceptor to report this error condition to the initiator via for the acceptor to report this error condition to the initiator via
the application's communication channel. the application's communication channel.
skipping to change at page 7, line 24 skipping to change at page 7, line 31
always be given as the output_context_handle from the previous call always be given as the output_context_handle from the previous call
to GSS_Accept_sec_context() in a given negotiation loop, or to GSS_Accept_sec_context() in a given negotiation loop, or
GSS_C_NO_CONTEXT on the first call, but the acceptor_cred_handle and GSS_C_NO_CONTEXT on the first call, but the acceptor_cred_handle and
chan_bindings arguments should remain fixed over the course of a chan_bindings arguments should remain fixed over the course of a
given GSS negotiation loop. [RFC2743] only requires that the given GSS negotiation loop. [RFC2743] only requires that the
acceptor_cred_handle remain fixed throughout the loop, but the acceptor_cred_handle remain fixed throughout the loop, but the
chan_bindings argument should also remain fixed for reliable chan_bindings argument should also remain fixed for reliable
operation. operation.
The GSS acceptor calls GSS_Accept_sec_context(), using the The GSS acceptor calls GSS_Accept_sec_context(), using the
input_context_handle for the current proto-security-context and the input_context_handle for the current security context being
input_token received from the initiator. The presence or absence of established and the input_token received from the initiator. The
a nonempty output_token and the value of the major status code are presence or absence of a nonempty output_token and the value of the
the indicators for how to proceed: major status code are the indicators for how to proceed:
o If the major status code is GSS_S_COMPLETE and the output_token is o If the major status code is GSS_S_COMPLETE and the output_token is
empty, then the context negotiation is fully complete and ready empty, then the context negotiation is fully complete and ready
for use by the acceptor with no further actions. for use by the acceptor with no further actions.
o If the major status code is GSS_S_COMPLETE and the output_token is o If the major status code is GSS_S_COMPLETE and the output_token is
nonempty, then the acceptor's portion of the security context nonempty, then the acceptor's portion of the security context
negotiation is complete but the initiator's is not. The acceptor negotiation is complete but the initiator's is not. The acceptor
must send the output_token to the initiator so that the initiator must send the output_token to the initiator so that the initiator
can establish its half of the security context. can establish its half of the security context.
o If the major status code is GSS_S_CONTINUE_NEEDED and the o If the major status code is GSS_S_CONTINUE_NEEDED and the
output_token is nonempty, the context negotiation is incomplete. output_token is nonempty, the context negotiation is incomplete.
The acceptor must send the output_token to the initiator and await The acceptor must send the output_token to the initiator and await
another input_token from the initiator. another input_token from the initiator.
o If the major status code is GSS_S_CONTINUE_NEEDED and the o If the major status code is GSS_S_CONTINUE_NEEDED and the
output_token is empty, the mechanism has produced an output which output_token is empty, the mechanism has produced an output which
is not compliant with [RFC2743]. However, there are some known is not compliant with [RFC2743]. However, there are some known
implementations of certain mechanisms which do produce empty implementations of certain mechanisms such as NTLMSSP [NTLMSSP]
context negotiation tokens. For maximum interoperability, which do produce empty context negotiation tokens. For maximum
applications should be prepared to accept such tokens, and should interoperability, applications should be prepared to accept such
transmit them to the initiator if they are generated. tokens, and should transmit them to the initiator if they are
generated.
o If the major status code is any other value, the context o If the major status code is any other value, the context
negotiation has failed. If the output_token is nonempty, it is an negotiation has failed. If the output_token is nonempty, it is an
error token, and the acceptor should send it to the initiator. If error token, and the acceptor should send it to the initiator. If
the output_token is empty, then the acceptor should indicate the the output_token is empty, then the acceptor should indicate the
failure to the initiator if an appropriate application-protocol failure to the initiator if an appropriate application-protocol
channel to do so is available. channel to do so is available.
3.6. Sending from Acceptor to Initiator 3.6. Sending from Acceptor to Initiator
skipping to change at page 13, line 18 skipping to change at page 13, line 24
buf->length = 0; buf->length = 0;
} }
/* /*
* Helper to send a token on the specified fd. * Helper to send a token on the specified fd.
* *
* If errors are encountered, this routine must not directly cause * If errors are encountered, this routine must not directly cause
* termination of the process, because compliant GSS applications * termination of the process, because compliant GSS applications
* must release resources allocated by the GSS library before * must release resources allocated by the GSS library before
* exiting. * exiting.
*
* Returns 0 on success, non-zero on failure.
*/ */
static int static int
send_token(int fd, gss_buffer_t token) send_token(int fd, gss_buffer_t token)
{ {
/* /*
* Supply token framing and transmission code here. * Supply token framing and transmission code here.
* *
* It is advisable for the application protocol to specify the * It is advisable for the application protocol to specify the
* length of the token being transmitted, unless the underlying * length of the token being transmitted, unless the underlying
* transit does so implicitly. * transit does so implicitly.
skipping to change at page 13, line 43 skipping to change at page 13, line 51
return 1; return 1;
} }
/* /*
* Helper to receive a token on the specified fd. * Helper to receive a token on the specified fd.
* *
* If errors are encountered, this routine must not directly cause * If errors are encountered, this routine must not directly cause
* termination of the process, because compliant GSS applications * termination of the process, because compliant GSS applications
* must release resources allocated by the GSS library before * must release resources allocated by the GSS library before
* exiting. * exiting.
*
* Returns 0 on success, non-zero on failure.
*/ */
static int static int
receive_token(int fd, gss_buffer_t token) receive_token(int fd, gss_buffer_t token)
{ {
/* /*
* Supply token framing and transmission code here. * Supply token framing and transmission code here.
* *
* In addition to checking for error returns from whichever * In addition to checking for error returns from whichever
* syscall(s) are used to receive data, applications should have * syscall(s) are used to receive data, applications should have
* a loop to handle EINTR returns. * a loop to handle EINTR returns.
skipping to change at page 20, line 27 skipping to change at page 20, line 43
in Simple Authentication and Security Layer (SASL): The in Simple Authentication and Security Layer (SASL): The
GS2 Mechanism Family", RFC 5801, July 2010. GS2 Mechanism Family", RFC 5801, July 2010.
[RFC4752] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple [RFC4752] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple
Authentication and Security Layer (SASL) Mechanism", RFC Authentication and Security Layer (SASL) Mechanism", RFC
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.
[NTLMSSP] Microsoft Corporation, "[MS-NLMP]: NT LAN Manager (NTLM)
Authentication Protocol", May 2014.
[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.
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.
 End of changes. 14 change blocks. 
30 lines changed or deleted 40 lines changed or added

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