Re: What am I waiting on for gs2?

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

Sam Hartman <hartmans-ietf@xxxxxxx> writes:

>>>>>> "Sam" == Sam Hartman <hartmans-ietf@xxxxxxx> writes:
>
>>>>>> "Simon" == Simon Josefsson <simon@xxxxxxxxxxxxx> writes:
>
>     Simon> Sam Hartman <hartmans-ietf@xxxxxxx> writes:
>     >>> I seem to have dropped the ball on gs2.  What if anything am I
>     >>> waiting on to align with RFC 5056?
>     >>> 
>     >>> Were the other issues all resolved?
>
>     Simon> As far as I understood, the concern you raised was that GS2
>     Simon> had to supply two fields for the channel binding prefix and
>     Simon> the channel binding data, which was not how I had
>     Simon> understood the channel-binding document.  The
>     Simon> channel-binding document was changed to prefix all data
>     Simon> with the unique prefix, I think.  Thus no change would be
>     Simon> needed for GS2.
>
> Simon, I reviewed the changes and I believe that there is one open
> issue.
>
> The channel binding spec requires applications know about channel
> binding failure.  You added text passing this requirement along, but I
> don't see how your protocol allows the client to detect channel
> binding failure.
>
> We have c->m->s where m is a passive man in the middle that joins the
> TLS stream.  So, the channel bindings are different.  C sends the
> gss_wrap to s using the same qop for channel binding and non-channel
> binding.
> How does s indicate to c that the channel binding from s's standpoint is not the same as what it received from c?
>
> I think you need a bit (possibly as a flag bit xored in with the qop)
> to indicate this.

FYI, I had interpreted the requirement in RFC 5056:

   o  Authentication frameworks and mechanisms that support channel
      binding MUST communicate channel binding failure to applications.

to mean that implementations must let the local applications know about
the situation.  That allows them to abort the connection depending on
local policy.  I didn't read that to mean that protocols are required to
notify the other side of the situation.  The latter requirement is
stronger than the former.  I must admit that I don't see why the
stronger requirement is a useful one.

I have applied the patch below to address your concern.  Updated
document:

http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.txt

Changes since the last version:

http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-from--09.diff.html

As always, general information available from:

http://josefsson.org/sasl-gs2/

I'll submit this to the IETF in a few days unless there are comments.

/Simon

@@ -802,11 +802,11 @@
    no security layer and instead depend on the session security afforded
    by the bound-in channel.
 
-   In order to accomodate the requirement in [16] "Authentication
+   In order to accomodate the requirement in [8] "Authentication
    frameworks and mechanisms that support channel binding MUST
    communicate channel binding failure to applications" implementations
-   MUST provide a way to communicate channel binding failures to
-   applications.
+   assert bit 7 in the security layer bitmask (see Section 9) on
+   negotiation failures.
 
    Use of no SASL security layers in combination with channel binding
    should provide better performance than using SASL security layers
@@ -1087,7 +1087,8 @@
       token.
 
    o  Local policy reject the attempt.  For example, client and server
-      can't agree on qop proposal.
+      can't agree on qop proposal, or channel binding negotiation
+      failed.
 
    o  (server-side) Authorization of client principal (i.e., src_name in
       GSS_Acecpt_sec_context) to requested authzid failed.
@@ -1195,6 +1195,13 @@
    "server_qop" MUST verify that it corresponds to an acceptable
    security level.
 
+   Whether the channel binding negotiation is successful or not may
+   influence the security layer selection.  Bit 7 is used to signal
+   failed channel binding negotiation.  Implementations MUST set the bit
+   if channel bindings were provided from the other end and a local
+   channel binding is absent or not equal.  Implementation MUST clear
+   the bit otherwise.
+
    The security layers and their corresponding bit-masks are as follows:
 
      1 No security layer
@@ -1202,6 +1209,7 @@
        Sender calls GSS_Wrap with conf_flag set to FALSE
      4 Confidentiality protection.
        Sender calls GSS_Wrap with conf_flag set to TRUE
+     7 Channel binding negotiation failed.
 
    Other bit-masks may be defined in the future; bits which are not
    understood MUST be negotiated off.
@@ -1530,6 +1530,9 @@
    responses.  This is a generic design critera for the GSS-API
    mechanisms used under GS2.
 
+   GS2 permits channel binding negotiation to fail.  Implementation may
+   have a local policy to reject authentication attempts in this case.
+
    When a server or client supports multiple GSS-API mechanisms, each of
    which has a different security strength, it is possible for an active
    attacker to cause a party to use the least secure mechanism