draft-ietf-kitten-gss-loop-02.txt   draft-ietf-kitten-gss-loop-03.txt 
Network Working Group B. Kaduk Network Working Group B. Kaduk
Internet-Draft MIT Internet-Draft MIT
Intended status: Informational December 8, 2014 Intended status: Informational December 31, 2014
Expires: June 11, 2015 Expires: July 4, 2015
Structure of the GSS Negotiation Loop Structure of the GSS Negotiation Loop
draft-ietf-kitten-gss-loop-02 draft-ietf-kitten-gss-loop-03
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 June 11, 2015. This Internet-Draft will expire on July 4, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Application Protocol Requirements . . . . . . . . . . . . . . 3
3. Loop Structure . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Anonymous Initiators . . . . . . . . . . . . . . . . . . 4
3.2. GSS_Init_sec_context . . . . . . . . . . . . . . . . . . 5
3.3. Sending from Initiator to Acceptor . . . . . . . . . . . 5
3.4. Acceptor Sanity Checking . . . . . . . . . . . . . . . . 6
3.5. GSS_Accept_sec_context . . . . . . . . . . . . . . . . . 7
3.6. Sending from Acceptor to Initiator . . . . . . . . . . . 8
3.7. Initiator input validation . . . . . . . . . . . . . . . 8
3.8. Continue the Loop . . . . . . . . . . . . . . . . . . . . 9
4. After Security Context Negotiation . . . . . . . . . . . . . 9
4.1. Authorization Checks . . . . . . . . . . . . . . . . . . 10
4.2. Using Partially Complete Security Contexts . . . . . . . 10
4.3. Additional Context Tokens . . . . . . . . . . . . . . . . 10
5. Sample Code . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. GSS Application Sample Code . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . 19
7.2. Informational References . . . . . . . . . . . . . . . . 19
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
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
messages between the initiator and acceptor, the generation of messages between the initiator and acceptor, the generation of
skipping to change at page 4, line 26 skipping to change at page 5, line 4
call in the loop. call in the loop.
3.1. Anonymous Initiators 3.1. Anonymous Initiators
If the initiator is requesting anonymity by setting the anon_req_flag If the initiator is requesting anonymity by setting the anon_req_flag
input to GSS_Init_sec_context(), then on non-error returns from input to GSS_Init_sec_context(), then on non-error returns from
GSS_Init_sec_context() (that is, when the major status is GSS_Init_sec_context() (that is, when the major status is
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 proto-security-context and its
fixed set of input parameters, and the input_token received from the fixed set of input parameters, and the input_token received from the
acceptor (if not the first iteration of the loop). The presence of a acceptor (if not the first iteration of the loop). The presence or
nonempty output_token and the value of the major status code are the absence of a nonempty output_token and the value of the major status
indicators for how to proceed: code are the indicators for how to proceed:
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.
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.
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.
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 which do produce empty
context negotiation tokens. For maximum interoperability, context negotiation tokens. For maximum interoperability,
applications should be prepared to accept such tokens, and should applications should be prepared to accept such tokens, and should
transmit them to the acceptor if they are generated. transmit them to the acceptor if they are generated.
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
The establishment of a GSS security context between initiator and The establishment of a GSS security context between initiator and
acceptor requires some communication channel by which to exchange the acceptor requires some communication channel by which to exchange the
skipping to change at page 6, line 47 skipping to change at page 7, line 25
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 proto-security-context and the
input_token received from the initiator. The presence of a nonempty input_token received from the initiator. The presence or absence of
output_token and the value of the major status code are the a nonempty output_token and the value of the major status code are
indicators for how to proceed: the indicators for how to proceed:
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.
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.
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.
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 which do produce empty
context negotiation tokens. For maximum interoperability, context negotiation tokens. For maximum interoperability,
applications should be prepared to accept such tokens, and should applications should be prepared to accept such tokens, and should
transmit them to the initiator if they are generated. transmit them to the initiator if they are generated.
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
The mechanism for sending the context token from acceptor to The mechanism for sending the context token from acceptor to
initiator will depend on the nature of the communication channel initiator will depend on the nature of the communication channel
 End of changes. 17 change blocks. 
20 lines changed or deleted 47 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/