[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 02 draft-ietf-kitten-channel-bound-flag

Network Working Group                                        N. Williams
Internet-Draft                                              Cryptonector
Updates: RFC2743 RFC2744                               February 22, 2013
(if approved)
Intended status: Standards Track
Expires: August 26, 2013


Channel Binding Signalling for the Generic Security Services Application
                         Programming Interface
              draft-williams-kitten-channel-bound-flag-02

Abstract

   This Internet-Draft proposes the addition of a "channel bound" return
   flag for the GSS_Init_sec_context() and GSS_Accept_sec_context()
   functions.  Two behaviors are specified: a default, safe behavior,
   and a behavior that is only safe when the application specifically
   tells the Generic Security Services Application Programming Interface
   (GSS-API) that it (the applicaiton) supports the new behavior.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 26, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Williams                 Expires August 26, 2013                [Page 1]


Internet-Draft           GSS Channel Bound Flag            February 2013


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1.    Error in RFC2743 . . . . . . . . . . . . . . . . . . . . .  3
   1.2.    Design . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.3.    Alternative Design . . . . . . . . . . . . . . . . . . . .  4
   1.4.    Future Directions  . . . . . . . . . . . . . . . . . . . .  4
   1.5.    Conventions used in this document  . . . . . . . . . . . .  4
   2.      Channel Binding State Extension  . . . . . . . . . . . . .  5
   2.1.    GSS_Create_sec_context() . . . . . . . . . . . . . . . . .  5
   2.1.1.  C-Bindings . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.2.    GSS_Set_context_flags()  . . . . . . . . . . . . . . . . .  6
   2.2.1.  C-Bindings . . . . . . . . . . . . . . . . . . . . . . . .  6
   2.3.    Return Flag for Channel Binding State Signalling . . . . .  7
   2.3.1.  C-Bindings . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.      Modified Channel Binding Semantics . . . . . . . . . . . .  8
   4.      Security Considerations  . . . . . . . . . . . . . . . . .  9
   5.      IANA Considerations  . . . . . . . . . . . . . . . . . . . 10
   6.      References . . . . . . . . . . . . . . . . . . . . . . . . 11
   6.1.    Normative References . . . . . . . . . . . . . . . . . . . 11
   6.2.    Informative References . . . . . . . . . . . . . . . . . . 11
           Author's Address . . . . . . . . . . . . . . . . . . . . . 12























Williams                 Expires August 26, 2013                [Page 2]


Internet-Draft           GSS Channel Bound Flag            February 2013


1.  Introduction

   The GSS-API [RFC2743] supports "channel binding" [RFC5056], a
   technique for detection of man-in-the-middle (MITM) attacks in secure
   channels at lower network layers.  This facility is meant to be all-
   or-nothing: either both the initiator and acceptor use it and it
   succeeds, or both must not use it.  This has created a negotiation
   problem when retrofitting the use of channel binding into existing
   application protocols.

   Many implementations of the Kerberos V5 GSS-API mechanism [RFC4121]
   cause the acceptor to succeed when the initiator used channel binding
   but the acceptor application did not.  This has helped deployment of
   channel binding in existing applications: first fix all the
   initiators, then fix all the acceptors.  But even this is
   insufficient when there are many clients to fix, such that fixing
   them all will take a long time.

   This document proposes a new method for deployment of channel binding
   that allows the feature to be enabled on the acceptor side before
   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
   simpler method of deploying channel binding: applications check that
   return flag and act accordingly (e.g., fail when channel binding is
   required).  We cannot safely introduce this behavior now without an
   indication of support by the application.

   It is worth noting that at least one implementor of GSS-API
   mechanisms (but not of the GSS-API itself) has similar semantics in
   its API to those proposed herein.  [XXX add references to the
   relevant SSPI docs? -Nico]

1.1.  Error in RFC2743

   The GSS-APIv2u1 [RFC2743] seems to indicate that mechanisms must
   ignore channel bindings when one party provided none.  In practice
   some mechanisms ignore channel bindings when the acceptor provides
   none, but not when the initiator provides none.  Note that it would
   be useless to allow security context establishment to succeed when
   the initiator does not provide channel bindings but the acceptor
   does, at least as long as there's no outward indication of whether
   channel binding was used!  And indeed, the GSS-APIv2u1 does not
   provide any such indication.  We correct this flaw in this document.

1.2.  Design

   After some discussion on the mailing list of various designs for
   signalling application support for the new flag we've settled on



Williams                 Expires August 26, 2013                [Page 3]


Internet-Draft           GSS Channel Bound Flag            February 2013


   copying an aspect of the Java Bindings of the GSS-API [RFC5653],
   specifically the notion of creating an "empty" SECURITY CONTEXT
   handle that can then be passed to GSS_Init_sec_context() and
   GSS_Accept_sec_context() where they normally expect a NULL handle.
   This empty security context handle can then be used to set options
   relating to security context token establishment.

1.3.  Alternative Design

   The previous design was based on an existing, non-standard extension
   for carrying security context establishment options in CREDENTIAL
   HANDLEs.  Note that a notion of CREDENTIAL HANDLE options might still
   be useful for options that are really specific to credentials rather
   than security context tokens (for example: setting an acceptable
   cryptographic security profile on a CREDENTIAL HANDLE and receiving a
   new handle with possibly fewer elements, reflecting that some
   credentials cannot meet the requirement).

1.4.  Future Directions

   We're likely to introduce additional mutator functions of empty
   contexts, with mutators corresponding to many of the existing input
   arguments of GSS_Init_sec_context() and GSS_Accept_sec_context(), as
   well as a few additional security context inquiry functions.  We're
   also likely to then introduce new variants of GSS_Init_sec_context()
   and GSS_Accept_sec_context() with all of those input and output
   parameters removed that could be set or retrieved with the other new
   functions.  The only inputs that the new GSS_Init/
   Accept_sec_context() must have are: a security context handle (never
   NULL), and an input context token, and the only outputs should be the
   status indicators and an output token -- in fact, we may want to have
   just one new function called, perhaps, GSS_Step_sec_context(), with
   the role of initiator or acceptor set as a context option.

1.5.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].












Williams                 Expires August 26, 2013                [Page 4]


Internet-Draft           GSS Channel Bound Flag            February 2013


2.  Channel Binding State Extension

   We propose a new return flag for GSS_Init_sec_context() and
   GSS_Accept_sec_context(), as well as a pair of functions for setting
   a) creating "empty" security context handles, b) setting req_flags
   and indicating which ret_flags the application understands.

   C bindings of these extensions are provided along the lines of
   [RFC2744] and [RFC5587].

   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
   mutators on empty security context handles.

2.1.  GSS_Create_sec_context()

   Inputs:

   o  <none>

   Outputs:

   o  major_status INTEGER

   o  minor_status INTEGER -- note: mostly useless, but we should keep
      it

   o  context SECURITY CONTEXT

   Return major status codes:

   o  GSS_S_COMPLETE indicates success.

   o  GSS_S_UNAVAILABLE indicates that memory is not available, for
      example.

   o  GSS_S_FAILURE indicates a general failure.

   This function creates an "empty" security context handle that can be
   passed to GSS_Init_sec_context() or GSS_Accept_sec_context() where
   they expect a NULL context.

2.1.1.  C-Bindings








Williams                 Expires August 26, 2013                [Page 5]


Internet-Draft           GSS Channel Bound Flag            February 2013


    OM_uint32
    gss_create_sec_context(OM_uint32 *minor_status,
                           gss_ctx_id_t *context);

             Figure 1: C-Bindings of GSS_Create_sec_context()

2.2.  GSS_Set_context_flags()

   Inputs:

   context CONTEXT HANDLE

   req_flags FLAGS  Requested flags.  Applicable to acceptors and
      initiators.

   ret_flags_understood FLAGS  Return flags understood by the caller.

   Outputs:

   o  major_status INTEGER

   o  minor_status INTEGER

   Return major status codes:

   o  GSS_S_COMPLETE indicates success.

   o  GSS_S_FAILURE indicates a general failure.

   This function tells the mechanism (when one is eventually chosen and
   invoked) that the application requests the given req_flags and
   undestands the given ret_flags.  Initiators can override the
   req_flags in their GSS_Init_sec_context() call, but if no flags are
   requested there then the req_flags set on the empty context will be
   used.

   NOTE: The abstract GSS-API [RFC2743] uses individual elements -one
   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
   request/return flags defined for the abstract GSS-API.

2.2.1.  C-Bindings









Williams                 Expires August 26, 2013                [Page 6]


Internet-Draft           GSS Channel Bound Flag            February 2013


    OM_uint32
    gss_set_context_flags(OM_uint32 *minor_status,
                          gss_ctx_id_t context,
                          uint64_t req_flags,
                          uint64_t ret_flags);

              Figure 2: C-Bindings of GSS_Set_context_flags()

2.3.  Return Flag for Channel Binding State Signalling

   Whenever both the initiator and the acceptor provide matching channel
   bindings to GSS_Init_sec_context() and GSS_Accept_sec_context(),
   respectively, then the mechanism SHALL indicate that the context is
   channel bound via an output flag, ret_channel_bound_flag, for the
   established context.

2.3.1.  C-Bindings

    #define GSS_C_CHANNEL_BOUND_FLAG 2048 /* 0x00000800 */

                Figure 3: C-Bindings of channel_bound_flag






























Williams                 Expires August 26, 2013                [Page 7]


Internet-Draft           GSS Channel Bound Flag            February 2013


3.  Modified Channel Binding Semantics

   The channel binding semantics of the base GSS-API are modified as
   follows:

   o  Whenever both, the initiator and acceptor shall have provided
      input_channel_bindings to GSS_Init/Accept_sec_context() and the
      channel bindings do not match, then the mechanism MUST fail to
      establish a security context token.  This is a restatement of an
      existing requirement in the base specification, restated for
      convenience.

   o  Whenever the acceptor application shall have a) provided channel
      bindings to GSS_Accept_sec_context(), and b) not indicated support
      for the ret_channel_bound_flag flag, then the mechanism MUST fail
      to establish a security context if the initiator did not provide
      channel bindings data.  This requirement is for security purposes,
      to make applications predating this document secure, and this
      requirement reflects actual implementations as deployed.

   o  Whenever the initiator application shall have a) provided channel
      bindings to GSS_Init_sec_context(), and b) not indicated support
      for the ret_channel_bound_flag flag, then the mechanism SHOULD NOT
      fail to establish a security context just because the acceptor
      failed to provide channel bindings data.  This recommendation is
      for interoperability purposes, and reflects actual implementations
      that have been deployed.  It is possible that not all security
      mechanism protocols can implement this requirement easily.

   o  Whenever the application shall have a) provided channel bindings
      to GSS_Init_sec_context() or GSS_Accept_sec_context(), and b)
      indicated support for the ret_channel_bound_flag flag, then the
      mechanism MUST NOT fail to establish a security context just
      because the peer did not provide channel bindings data.  The
      mechanism MUST output the ret_channel_bound_flag if both peers
      provided the same input_channel_bindings to GSS_Init_sec_context()
      and GSS_Accept_sec_context.  The mechanism MUST NOT output the
      ret_channel_bound_flag if either (or both) peer did not provide
      input_channel_bindings to GSS_Init/Accept_sec_context().  This
      requirement restores the original base GSS-API specified behavior,
      with the addition of the ret_channel_bound_flag flag










Williams                 Expires August 26, 2013                [Page 8]


Internet-Draft           GSS Channel Bound Flag            February 2013


4.  Security Considerations

   This document deals with security.  There are no security
   considerations that should be documented separately in this section.
   To recap, this document fixes a significant flaw in the base GSS-API
   [RFC2743] specification that fortunately has not been implemented,
   and it adds a feature (that should have been in the base
   specification) for improved negotiation of use of channel binding
   [RFC5056].










































Williams                 Expires August 26, 2013                [Page 9]


Internet-Draft           GSS Channel Bound Flag            February 2013


5.  IANA Considerations

   This document has no IANA considerations.
















































Williams                 Expires August 26, 2013               [Page 10]


Internet-Draft           GSS Channel Bound Flag            February 2013


6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2743]  Linn, J., "Generic Security Service Application Program
              Interface Version 2, Update 1", RFC 2743, January 2000.

   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
              C-bindings", RFC 2744, January 2000.

   [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
              Channels", RFC 5056, November 2007.

   [RFC5587]  Williams, N., "Extended Generic Security Service Mechanism
              Inquiry APIs", RFC 5587, July 2009.

6.2.  Informative References

   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
              Version 5 Generic Security Service Application Program
              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
              July 2005.

   [RFC5653]  Upadhyay, M. and S. Malkani, "Generic Security Service API
              Version 2: Java Bindings Update", RFC 5653, August 2009.























Williams                 Expires August 26, 2013               [Page 11]


Internet-Draft           GSS Channel Bound Flag            February 2013


Author's Address

   Nicolas Williams
   Cryptonector, LLC

   Email: nico@cryptonector.com













































Williams                 Expires August 26, 2013               [Page 12]


Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/