draft-ietf-kitten-channel-bound-flag-00.txt   draft-ietf-kitten-channel-bound-flag-01.txt 
KITTEN N. Williams KITTEN N. Williams
Internet-Draft Cryptonector Internet-Draft Cryptonector
Updates: 2743, 2744 (if approved) July 7, 2013 Updates: 2743, 2744 (if approved) March 30, 2017
Intended status: Standards Track Intended status: Standards Track
Expires: January 8, 2014 Expires: October 1, 2017
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-00 draft-ietf-kitten-channel-bound-flag-01
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 that those specified in the base GSS-API RFC (RFC2743), and different that 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 33 skipping to change at page 1, line 33
This Internet-Draft proposes the addition of a "channel bound" return This Internet-Draft proposes the addition of a "channel bound" return
flag for the GSS_Init_sec_context() and GSS_Accept_sec_context() flag for the GSS_Init_sec_context() and GSS_Accept_sec_context()
functions. Two behaviors are specified: a default, safe behavior functions. Two behaviors are specified: a default, safe behavior
reflecting existing implementation deployments, and a behavior that reflecting existing implementation deployments, and a behavior that
is only safe when the application specifically tells the GSS-API that is only safe when the application specifically tells the GSS-API that
it (the application) supports the new behavior. Additional API it (the application) supports the new behavior. Additional API
elements related to this are also added, including a new security elements related to this are also added, including a new security
context establishment API. context establishment API.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 8, 2014. This Internet-Draft will expire on October 1, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2017 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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Error in RFC2743 . . . . . . . . . . . . . . . . . . . . . 3 1.1. Error in RFC2743 . . . . . . . . . . . . . . . . . . . . . 3
1.2. Design . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Design . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Alternative Design . . . . . . . . . . . . . . . . . . . . 4 1.3. Alternative Design . . . . . . . . . . . . . . . . . . . . 4
1.4. Future Directions . . . . . . . . . . . . . . . . . . . . 4 1.4. Future Directions . . . . . . . . . . . . . . . . . . . . . 4
1.5. Conventions used in this document . . . . . . . . . . . . 4 1.5. Conventions used in this document . . . . . . . . . . . . . 4
2. Channel Binding State Extension . . . . . . . . . . . . . 5 2. Channel Binding State Extension . . . . . . . . . . . . . . . 5
2.1. GSS_Create_sec_context() . . . . . . . . . . . . . . . . . 5 2.1. GSS_Create_sec_context() . . . . . . . . . . . . . . . . . 5
2.1.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. GSS_Set_context_flags() . . . . . . . . . . . . . . . . . 6 2.2. GSS_Set_context_flags() . . . . . . . . . . . . . . . . . . 6
2.2.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Return Flag for Channel Binding State Signalling . . . . . 6 2.3. Return Flag for Channel Binding State Signalling . . . . . 7
2.3.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. New Mechanism Attributes . . . . . . . . . . . . . . . . . 7 2.4. New Mechanism Attributes . . . . . . . . . . . . . . . . . 7
2.5. Request Flag for Acceptor Confirmation of Channel 2.5. Request Flag for Acceptor Confirmation of Channel Binding . 7
Binding . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.5.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . 8
2.5.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 7 2.6. GSS_Delete_sec_context() Behavior When Applied to Empty
2.6. GSS_Delete_sec_context() Behavior When Applied to Security Contexts . . . . . . . . . . . . . . . . . . . . . 8
Empty Security Contexts . . . . . . . . . . . . . . . . . 8 3. Modified Channel Binding Semantics . . . . . . . . . . . . . 8
3. Modified Channel Binding Semantics . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . 13
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.
skipping to change at page 5, line 50 skipping to change at page 5, line 50
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 a NULL 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:
context CONTEXT HANDLE context CONTEXT HANDLE
req_flags FLAGS Requested flags. Applicable to acceptors and req_flags FLAGS Requested flags. Applicable to acceptors and
initiators. initiators.
skipping to change at page 6, line 43 skipping to change at page 6, line 43
requested there then the req_flags set on the empty context will be requested there then the req_flags set on the empty context will be
used. used.
NOTE: The abstract GSS-API [RFC2743] uses individual elements -one NOTE: The abstract GSS-API [RFC2743] uses individual elements -one
per-flag- instead of a "FLAGS" type. This is unwieldy, therefore we per-flag- instead of a "FLAGS" type. This is unwieldy, therefore we
introduce an abstract type named "FLAGS" to act as a set of all the introduce an abstract type named "FLAGS" to act as a set of all the
request/return flags defined for the abstract GSS-API. request/return flags defined for the abstract GSS-API.
2.2.1. C-Bindings 2.2.1. C-Bindings
OM_uint32 OM_uint32
gss_set_context_flags(OM_uint32 *minor_status, gss_set_context_flags(OM_uint32 *minor_status,
gss_ctx_id_t context, gss_ctx_id_t context,
uint64_t req_flags, uint64_t req_flags,
uint64_t ret_flags); uint64_t ret_flags);
2.3. Return Flag for Channel Binding State Signalling 2.3. Return Flag for Channel Binding State Signalling
Whenever both the initiator and the acceptor provide matching channel Whenever both the initiator and the acceptor provide matching channel
bindings to GSS_Init_sec_context() and GSS_Accept_sec_context(), bindings to GSS_Init_sec_context() and GSS_Accept_sec_context(),
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 Attributes
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. Mechanisms acceptor application supplied channel bindings. Mechanisms
advertising this attribute MUST always indicate acceptor channel advertising this attribute MUST always indicate acceptor channel
bound state to the initiator. bound state to the initiator.
o We add a new mechanism attribute, GSS_C_MA_CBINDING_MAY_CONFIRM, o We add a new mechanism attribute, GSS_C_MA_CBINDING_MAY_CONFIRM,
skipping to change at page 7, line 51 skipping to change at page 8, line 11
mechanism attributes, and SHOULD NOT negotiate mechanisms that lack mechanism attributes, and SHOULD NOT negotiate mechanisms that lack
the GSS_C_MA_CBINDING_CONFIRM mechanism attribute (except if allowed the GSS_C_MA_CBINDING_CONFIRM mechanism attribute (except if allowed
by local configuration). 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. GSS_Delete_sec_context() Behavior When Applied to Empty Security 2.6. GSS_Delete_sec_context() Behavior When Applied to Empty Security
Contexts Contexts
GSS_Delete_sec_context() MUST NOT output a context deletion token GSS_Delete_sec_context() MUST NOT output a context deletion token
when applied to empty security contexts. when applied to empty security contexts.
3. Modified Channel Binding Semantics 3. Modified Channel Binding Semantics
The channel binding semantics of the base GSS-API are modified as The channel binding semantics of the base GSS-API are modified as
skipping to change at page 12, line 10 skipping to change at page 9, line 33
Two GSS-API mechanism attributes are to be added to the "SMI Security Two GSS-API mechanism attributes are 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, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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,
DOI 10.17487/RFC2743, January 2000,
<http://www.rfc-editor.org/info/rfc2743>.
[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, DOI 10.17487/RFC2744, January 2000,
<http://www.rfc-editor.org/info/rfc2744>.
[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, November 2007. Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,
<http://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, July 2009. Inquiry APIs", RFC 5587, DOI 10.17487/RFC5587, July 2009,
<http://www.rfc-editor.org/info/rfc5587>.
6.2. Informative References 6.2. Informative References
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121, Interface (GSS-API) Mechanism: Version 2", RFC 4121,
July 2005. DOI 10.17487/RFC4121, July 2005,
<http://www.rfc-editor.org/info/rfc4121>.
[RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
Simple and Protected Generic Security Service Application Simple and Protected Generic Security Service Application
Program Interface (GSS-API) Negotiation Mechanism", Program Interface (GSS-API) Negotiation Mechanism",
RFC 4178, October 2005. RFC 4178, DOI 10.17487/RFC4178, October 2005,
<http://www.rfc-editor.org/info/rfc4178>.
[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, August 2009. Version 2: Java Bindings Update", RFC 5653,
DOI 10.17487/RFC5653, August 2009,
<http://www.rfc-editor.org/info/rfc5653>.
[I-D.williams-williams-kitten-ctx-simple-async] [I-D.williams-williams-kitten-ctx-simple-async]
Williams, N., "Simplified and Asynchronous Security Williams, N., "Simplified and Asynchronous Security
Context Interfaces for the Generic Security Services Context Interfaces for the Generic Security Services
Application Programming Interface", Application Programming Interface", draft-williams-
draft-williams-williams-kitten-ctx-simple-async-00 (work williams-kitten-ctx-simple-async-00 (work in progress),
in progress), February 2013. February 2013.
Author's Address Author's Address
Nicolas Williams Nicolas Williams
Cryptonector, LLC Cryptonector, LLC
Email: nico@cryptonector.com Email: nico@cryptonector.com
 End of changes. 20 change blocks. 
53 lines changed or deleted 63 lines changed or added

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