draft-ietf-kitten-channel-bound-flag-02.txt   draft-ietf-kitten-channel-bound-flag-03.txt 
KITTEN R. Harwood KITTEN R. Harwood
Internet-Draft Red Hat Internet-Draft Red Hat
Updates: 2743, 2744 (if approved) N. Williams Updates: 2743, 2744 (if approved) N. Williams
Intended status: Standards Track Cryptonector Intended status: Standards Track Cryptonector
Expires: April 8, 2018 October 5, 2017 Expires: January 28, 2019 July 27, 2018
Channel Binding Signalling for the Generic Security Services Application Channel Binding Signalling for the Generic Security Services Application
Programming Interface Programming Interface
draft-ietf-kitten-channel-bound-flag-02 draft-ietf-kitten-channel-bound-flag-03
Abstract Abstract
Channel binding is a technique that allows applications to use a Channel binding is a technique that allows applications to use a
secure channel at a lower layer without having to use authentication secure channel at a lower layer without having to use authentication
at that lower layer. The concept of channel binding comes from the at that lower layer. The concept of channel binding comes from the
Generic Security Services Application Programming Interface (GSS- Generic Security Services Application Programming Interface (GSS-
API). It turns out that the semantics commonly implemented are API). It turns out that the semantics commonly implemented are
different than those specified in the base GSS-API RFC (RFC2743), and different than those specified in the base GSS-API RFC (RFC2743), and
that that specification has a serious bug. This document addresses that that specification has a serious bug. This document addresses
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 April 8, 2018. This Internet-Draft will expire on January 28, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 2, line 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Design and Future directions . . . . . . . . . . . . . . . 3 1.1. Design and Future directions . . . . . . . . . . . . . . . 3
1.2. Conventions used in this document . . . . . . . . . . . . . 3 1.2. Conventions used in this document . . . . . . . . . . . . . 3
2. Channel Binding State Extension . . . . . . . . . . . . . . . 4 2. Channel Binding State Extension . . . . . . . . . . . . . . . 4
2.1. GSS_Create_sec_context() . . . . . . . . . . . . . . . . . 4 2.1. GSS_Create_sec_context() . . . . . . . . . . . . . . . . . 4
2.1.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. GSS_Set_context_flags() . . . . . . . . . . . . . . . . . . 5 2.2. GSS_Set_context_flags() . . . . . . . . . . . . . . . . . . 5
2.2.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Return Flag for Channel Binding State Signalling . . . . . 6 2.3. Return Flag for Channel Binding State Signalling . . . . . 6
2.3.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. New Mechanism Attributes . . . . . . . . . . . . . . . . . 6 2.4. New Mechanism Attribute . . . . . . . . . . . . . . . . . . 6
2.5. Request Flag for Acceptor Confirmation of Channel Binding . 6 2.5. Request Flag for Acceptor Confirmation of Channel Binding . 6
2.5.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . 7 2.5.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . 6
2.6. Handling Empty Contexts in Other GSS-API Functions . . . . 7 2.6. Handling Empty Contexts in Other GSS-API Functions . . . . 6
3. Modified Channel Binding Semantics . . . . . . . . . . . . . 7 3. Modified Channel Binding Semantics . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The GSS-API [RFC2743] supports "channel binding" [RFC5056], a The GSS-API [RFC2743] supports "channel binding" [RFC5056], a
technique for detection of man-in-the-middle (MITM) attacks in secure technique for detection of man-in-the-middle (MITM) attacks in secure
channels at lower network layers. This facility is meant to be all- channels at lower network layers. This facility is meant to be all-
or-nothing: either both the initiator and acceptor use it and it or-nothing: either both the initiator and acceptor use it and it
succeeds, or both must not use it. This has created a negotiation succeeds, or both must not use it. This has created a negotiation
problem when retrofitting the use of channel binding into existing problem when retrofitting the use of channel binding into existing
application protocols. application protocols.
However, GSS-APIv2u1 [RFC2743] does not specify channel binding However, GSS-APIv2u1 [RFC2743] does not specify channel binding
behavior when only one party provides provides none. In practice behavior when only one party provides provides none. In practice,
some mechanisms ignore channel bindings when the acceptor provides some mechanisms (such as Kerberos [RFC4121]) ignore channel bindings
none, but not when the initiator provides none. [XXX add references when the acceptor provides none, but not when the initiator provides
to the relevant SSPI docs? -Nico] Note that it would be useless to none. Note that it would be useless to allow security context
allow security context establishment to succeed when the initiator establishment to succeed when the initiator does not provide channel
does not provide channel bindings but the acceptor does, at least as bindings but the acceptor does, at least as long as there's no
long as there's no outward indication of whether channel binding was outward indication of whether channel binding was used! Since the
used! Since the GSS-APIv2u1 does not provide any such indication, GSS-APIv2u1 does not provide any such indication, this document
this document corrects that flaw. corrects that flaw.
Allowing the connection to succeed when an initiator provides Allowing the connection to succeed when an initiator provides
bindings but an acceptor does not has helped deployment of channel bindings but an acceptor does not has helped deployment of channel
binding in existing applications: first fix all the initiators, then binding in existing applications: first fix all the initiators, then
fix all the acceptors. But even this technique is insufficient when fix all the acceptors. But even this technique is insufficient when
there are many clients to fix, such that fixing them all will take a there are many clients to fix, such that fixing them all will take a
long time. Additionally, it limits the usefulness of channel long time. Additionally, it limits the usefulness of channel
bindings, while allowing the acceptor to provide but not enforce bindings, while allowing the acceptor to provide but not enforce
would protect against man in the middle attacks (for channel binding would protect against man in the middle attacks (for channel binding
aware initiators). aware initiators).
skipping to change at page 3, line 38 skipping to change at page 3, line 38
fixing all initiators. If the GSS-API had always had a return flag fixing all initiators. If the GSS-API had always had a return flag
by which to indicate channel binding state then we could have had a by which to indicate channel binding state then we could have had a
simpler method of deploying channel binding: applications check that simpler method of deploying channel binding: applications check that
return flag and act accordingly (e.g., fail when channel binding is return flag and act accordingly (e.g., fail when channel binding is
required). We cannot safely introduce this behavior now without an required). We cannot safely introduce this behavior now without an
indication of support by the application. indication of support by the application.
Additionally, there may be applications where it is important for Additionally, there may be applications where it is important for
initiators to know that acceptors did use channel binding, and even initiators to know that acceptors did use channel binding, and even
to know whether a mechanism is capable of indicating as much. We add to know whether a mechanism is capable of indicating as much. We add
a request flag and two mechanism attributes for such applications. a request flag and a mechanism attribute for such applications.
1.1. Design and Future directions 1.1. Design and Future directions
The design for signalling application flag support and empty contexts The design for signalling application flag support and empty contexts
is based on the Java Bindings of the GSS-API [RFC5653]. This is based on the Java Bindings of the GSS-API [RFC5653]. This
document begins introduction of additional context inquiry and document begins introduction of additional context inquiry and
mutation functions, which eventually will also allow for simplified mutation functions, which eventually will also allow for simplified
stepping to replace the GSS_Init/Accept_sec_context() loop. stepping to replace the GSS_Init/Accept_sec_context() loop.
1.2. Conventions used in this document 1.2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Channel Binding State Extension 2. Channel Binding State Extension
We propose a new return flag for GSS_Init_sec_context() and We propose a new return flag for GSS_Init_sec_context() and
GSS_Accept_sec_context(), as well as a pair of functions for a) GSS_Accept_sec_context(), as well as a pair of functions for a)
creating "empty" security context handles, b) requesting flags and creating "empty" security context handles, b) requesting flags and
indicating which flags the application understands. We also add new indicating which flags the application understands. We also add a
mechanism attributes describing mechanism capabilities. new mechanism attribute for supporting channel binding confirmation.
C bindings of these extensions are provided along the lines of C bindings of these extensions are provided along the lines of
[RFC2744] and [RFC5587]. [RFC2744] and [RFC5587].
In the future we might move more of the many input (and output) In the future we might move more of the many input (and output)
arguments to GSS_Init_sec_context() and GSS_Accept_sec_context() into arguments to GSS_Init_sec_context() and GSS_Accept_sec_context() into
mutators on empty security context handles. mutators on empty security context handles.
2.1. GSS_Create_sec_context() 2.1. GSS_Create_sec_context()
skipping to change at page 4, line 46 skipping to change at page 4, line 46
o GSS_S_COMPLETE indicates success. o GSS_S_COMPLETE indicates success.
o GSS_S_UNAVAILABLE indicates that memory is not available, for o GSS_S_UNAVAILABLE indicates that memory is not available, for
example. example.
o GSS_S_FAILURE indicates a general failure. o GSS_S_FAILURE indicates a general failure.
This function creates an "empty" security context handle that can be This function creates an "empty" security context handle that can be
passed to GSS_Init_sec_context() or GSS_Accept_sec_context() where passed to GSS_Init_sec_context() or GSS_Accept_sec_context() where
they expect a NULL context. they expect GSS_C_NO_CONTEXT.
2.1.1. C-Bindings 2.1.1. C-Bindings
OM_uint32 OM_uint32
gss_create_sec_context(OM_uint32 *minor_status, gss_create_sec_context(OM_uint32 *minor_status,
gss_ctx_id_t *context); gss_ctx_id_t *context);
2.2. GSS_Set_context_flags() 2.2. GSS_Set_context_flags()
Inputs: Inputs:
skipping to change at page 6, line 19 skipping to change at page 6, line 19
respectively, then the mechanism SHALL indicate that the context is respectively, then the mechanism SHALL indicate that the context is
channel bound via an output flag, ret_channel_bound_flag, for the channel bound via an output flag, ret_channel_bound_flag, for the
established context. Note that some mechanisms have no way for the established context. Note that some mechanisms have no way for the
acceptor to signal CB success to the initiator, in which case acceptor to signal CB success to the initiator, in which case
GSS_Init_sec_context() MUST NOT output the ret_channel_bound_flag. GSS_Init_sec_context() MUST NOT output the ret_channel_bound_flag.
2.3.1. C-Bindings 2.3.1. C-Bindings
#define GSS_C_CHANNEL_BOUND_FLAG 2048 /* 0x00000800 */ #define GSS_C_CHANNEL_BOUND_FLAG 2048 /* 0x00000800 */
2.4. New Mechanism Attributes 2.4. New Mechanism Attribute
o We add a new mechanism attribute, GSS_C_MA_CBINDING_CONFIRM, to o We add a new mechanism attribute, GSS_C_MA_CBINDING_CONFIRM, to
indicate that the initiator can and always does learn whether the indicate that the initiator can and always does learn whether the
acceptor application supplied channel bindings (assuming mutual acceptor application supplied channel bindings (assuming mutual
auth has been requested). Mechanisms advertising this attribute auth has been requested). Mechanisms advertising this attribute
MUST always indicate acceptor channel bound state to the MUST always indicate acceptor channel bound state to the
initiator. initiator.
o We add a new mechanism attribute, GSS_C_MA_CBINDING_MAY_CONFIRM,
to indicate that the initiator may learn whether the acceptor
application supplied channel bindings (assuming mutual auth has
been requested), but only when the acceptor implementation of the
mechanism has been suitably updated. Mechanisms MUST advertise
this attribute when the local initiator functionality for acceptor
channel bound state indication exists but the acceptor may lack
the same functionality (because, for example, the mechanism
predates this specification).
OID assignments TBD. OID assignments TBD.
2.5. Request Flag for Acceptor Confirmation of Channel Binding 2.5. Request Flag for Acceptor Confirmation of Channel Binding
We add a new request flag for GSS_Init_sec_context(), We add a new request flag for GSS_Init_sec_context(),
req_cb_confirmation_flag, to be used by initiators that insist on req_cb_confirmation_flag, to be used by initiators that insist on
acceptors providing channel bindings. This flag is only of use to acceptors providing channel bindings. If set, the mechanism MUST
mechanism-negotiation pseudo-mechanisms (e.g., SPNEGO [RFC4178]): if prefer establishment of contexts which provide channel binding
set, the pseudo-mechanism MUST NOT negotiate any mechanisms that lack confirmation. It SHOULD NOT fail to negotiate just because it cannot
both the GSS_C_MA_CBINDING_CONFIRM and GSS_C_MA_CBINDING_MAY_CONFIRM provide the GSS_C_MA_CBINDING_CONFIRM attribute.
mechanism attributes, and SHOULD NOT negotiate mechanisms that lack
the GSS_C_MA_CBINDING_CONFIRM mechanism attribute (except if allowed
by local configuration).
2.5.1. C-Bindings 2.5.1. C-Bindings
Because GSS_C_CHANNEL_BOUND_FLAG is a return flag only, and this flag Because GSS_C_CHANNEL_BOUND_FLAG is a return flag only, and this flag
is a request flag only, and to save on precious flag bits, we use the is a request flag only, and to save on precious flag bits, we use the
same flag bit assignment for both flags: same flag bit assignment for both flags:
#define GSS_C_CB_CONFIRM_FLAG 2048 /* 0x00000800 */ #define GSS_C_CB_CONFIRM_FLAG 2048 /* 0x00000800 */
2.6. Handling Empty Contexts in Other GSS-API Functions 2.6. Handling Empty Contexts in Other GSS-API Functions
skipping to change at page 7, line 46 skipping to change at page 7, line 33
o Whenever the acceptor application has a) provided channel bindings o Whenever the acceptor application has a) provided channel bindings
to GSS_Accept_sec_context(), and b) not indicated support for the to GSS_Accept_sec_context(), and b) not indicated support for the
ret_channel_bound_flag flag, then the mechanism MUST fail to ret_channel_bound_flag flag, then the mechanism MUST fail to
establish a security context if the initiator did not provide establish a security context if the initiator did not provide
channel bindings data. This requirement is critical for security channel bindings data. This requirement is critical for security
purposes, to make applications predating this document secure, and purposes, to make applications predating this document secure, and
this requirement reflects actual implementations as deployed. this requirement reflects actual implementations as deployed.
o Whenever the initiator application has a) provided channel o Whenever the initiator application has a) provided channel
bindings to GSS_Init_sec_context(), and b) not indicated support bindings to GSS_Init_sec_context(), and b) not indicated support
for the ret_channel_bound_flag flag, then the mechanism MUST NOT for the ret_channel_bound_flag flag, then the mechanism SHOULD NOT
fail to establish a security context just because the acceptor fail to establish a security context just because the acceptor
failed to provide channel bindings data. This requirement is for failed to provide channel bindings data. This strong sugestion is
interoperability purposes, and reflects actual implementations for interoperability purposes, and reflects actual implementations
that have been deployed. that have been deployed.
o Whenever the application has a) provided channel bindings to o Whenever the application has a) provided channel bindings to
GSS_Init_sec_context() or GSS_Accept_sec_context(), and b) GSS_Init_sec_context() or GSS_Accept_sec_context(), and b)
indicated support for the ret_channel_bound_flag flag, then the indicated support for the ret_channel_bound_flag flag, then the
mechanism MUST NOT fail to establish a security context just mechanism SHOULD NOT fail to establish a security context just
because the peer did not provide channel bindings data. The because the peer did not provide channel bindings data. The
mechanism MUST output the ret_channel_bound_flag if both peers mechanism MUST output the ret_channel_bound_flag if both peers
provided the same input_channel_bindings to GSS_Init_sec_context() provided the same input_channel_bindings to GSS_Init_sec_context()
and GSS_Accept_sec_context. The mechanism MUST NOT output the and GSS_Accept_sec_context(). The mechanism MUST NOT output the
ret_channel_bound_flag if either (or both) peer did not provide ret_channel_bound_flag if either (or both) peer did not provide
input_channel_bindings to GSS_Init/Accept_sec_context(). This input_channel_bindings to GSS_Init/Accept_sec_context(). This
requirement restores the original base GSS-API specified behavior, requirement restores the original base GSS-API specified behavior,
with the addition of the ret_channel_bound_flag flag. with the addition of the ret_channel_bound_flag flag.
4. Security Considerations 4. Security Considerations
This document deals with security. There are no security This document deals with security. There are no security
considerations that should be documented separately in this section. considerations that should be documented separately in this section.
To recap, this document fixes a significant flaw in the base GSS-API To recap, this document fixes a significant flaw in the base GSS-API
[RFC2743] specification that fortunately has not been implemented, [RFC2743] specification that fortunately has not been implemented,
and it adds a feature (that should have been in the base and it adds a feature (that should have been in the base
specification) for improved negotiation of use of channel binding specification) for improved negotiation of use of channel binding
[RFC5056]. [RFC5056].
5. IANA Considerations 5. IANA Considerations
Two GSS-API mechanism attributes are to be added to the "SMI Security The GSS-API mechanism attribute is to be added to the "SMI Security
for Mechanism gsscma Codes" registry established by RFC5587 for Mechanism gsscma Codes" registry established by RFC5587
[RFC5587]. See Section 2.4. [RFC5587]. See Section 2.4.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
skipping to change at page 9, line 15 skipping to change at page 9, line 5
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,
<https://www.rfc-editor.org/info/rfc5056>. <https://www.rfc-editor.org/info/rfc5056>.
[RFC5587] Williams, N., "Extended Generic Security Service Mechanism [RFC5587] Williams, N., "Extended Generic Security Service Mechanism
Inquiry APIs", RFC 5587, DOI 10.17487/RFC5587, July 2009, Inquiry APIs", RFC 5587, DOI 10.17487/RFC5587, July 2009,
<https://www.rfc-editor.org/info/rfc5587>. <https://www.rfc-editor.org/info/rfc5587>.
6.2. Informative References 6.2. Informative References
[RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Simple and Protected Generic Security Service Application Version 5 Generic Security Service Application Program
Program Interface (GSS-API) Negotiation Mechanism", Interface (GSS-API) Mechanism: Version 2", RFC 4121,
RFC 4178, DOI 10.17487/RFC4178, October 2005, DOI 10.17487/RFC4121, July 2005,
<https://www.rfc-editor.org/info/rfc4178>. <https://www.rfc-editor.org/info/rfc4121>.
[RFC5653] Upadhyay, M. and S. Malkani, "Generic Security Service API [RFC5653] Upadhyay, M. and S. Malkani, "Generic Security Service API
Version 2: Java Bindings Update", RFC 5653, Version 2: Java Bindings Update", RFC 5653,
DOI 10.17487/RFC5653, August 2009, DOI 10.17487/RFC5653, August 2009,
<https://www.rfc-editor.org/info/rfc5653>. <https://www.rfc-editor.org/info/rfc5653>.
Authors' Addresses Authors' Addresses
Robbie Harwood Robbie Harwood
Red Hat, Inc. Red Hat, Inc.
 End of changes. 20 change blocks. 
50 lines changed or deleted 37 lines changed or added

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