Subject: [sasl] Recursive gs2-header definition

From: Simon Josefsson <[email-masked]>
Date: Tue, 02 Mar 2010 22:55:09 +0100

I'm implementing GS2 and noticed what I believe is a technical problem,
but I hope I am mistaken.

Recall that gs2-header is defined as:

    gs2-header = [gs2-nonstd-flag ","] gs2-cb-flag "," [gs2-authzid] ","
                        ;; The GS2 header is gs2-header.

And recall in particular this explanation:

   When the "gs2-nonstd-flag" flag is present, the client did not find/
   remove a token header ([RFC2743] section 3.1) from the initial token
   returned by GSS_Init_sec_context.  This signals to the server that it
   MUST NOT re-add the data that is normally removed by the client.

Also recall that the gs2-header is used in the channel binding data:

   The application-data field MUST be set to the gs2-header concatenated
   with, when a gs2-cb-flag of "p" is used, the application's channel
   binding data.

Thus the implementation needs to construct the channel binding data as
_input_ to GSS_Init_sec_context.  But whether the implementation needs
to add the gs2-nonstd-flag or not is decided by looking at the initial
context token, which is one _output_ from the GSS_Init_sec_context call.

One fix would be to modify the second quoted paragraph above to say that
what is used as the channel binding data is only this part:

  gs2-cb-flag "," [gs2-authzid] ","

This leaves the gs2-nonstd-flag unauthenticated, though, so attackers
can insert or remove it without being detected.

This fix would be a protocol level visible technical change, though, so
I think we need to discuss it.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 3 Mar 2010 11:17:54 -0600

On Tue, Mar 02, 2010 at 10:55:09PM +0100, Simon Josefsson wrote:
> [...]

Ah, well, technically you can know a priori if a mechanism is a
"standard" one or not (standard in the sense of having/not having that
OID header).  And RFC5578 provides the API you need to make such a
determination a priori.

But not every implementor will have RFC5578 APIs available, nor a priori
knowledge of which mechanisms are standard and which are not.  We should
do something to solve this problem for them.

>   gs2-cb-flag "," [gs2-authzid] ","

Yes.  I'd rather not modify the header definition, but simply state say
that the gs2-nonstd-flag is not present in the CB input.

> can insert or remove it without being detected.

That's Ok: there's no harm from this (at most a DoS since you can make
the acceptor fail, but that was already possible).

> I think we need to discuss it.

Yes.

Proposed text for GS2:

OLD:

NEW:
   The application-data field MUST be set to the gs2-header, excluding
   the gs2-nonstd-flag, concatenated with, when a gs2-cb-flag of "p" is
   used, the application's channel binding data.

No changes are needed for SCRAM.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 03 Mar 2010 21:26:44 +0100

>    used, the application's channel binding data.

I like this approach.  It is a bit underspecified whether the "," goes
in or not though.  How about this:

    The application-data field MUST be set to the gs2-header, excluding
    the initial [gs2-nonstd-flag ","] part, concatenated with, when a
    gs2-cb-flag of "p" is used, the application's channel binding data.

If there are no objections to this, we'll send this edit request to the
RFC editor shortly.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 3 Mar 2010 14:51:32 -0600

> in or not though.  How about this:

No need: if gs2-cb-flag is empty then the "," must be missing as well
since only the conjunction of both is optional.

Nico
--

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 03 Mar 2010 22:58:10 +0000

>If there are no objections to this, we'll send this edit request to the
Works for me.