Source: http://kerberos.996246.n3.nabble.com/kitten-Review-of-draft-ietf-kitten-channel-bound-flag-td48959.html
Timestamp: 2019-04-23 06:03:53+00:00

Document:
Robbie asked me to look over the aforementioned draft, and so I did, and sent him the notes below. You'll be able to readily tell that I don't know GSS-API from a bar of soap, but I hope they're useful nonetheless.
He asked me to send them to the list, so here they are. I realise, re-reading them, that I seem a little grumpy. The content still stands, I think, but the tone was not intended, sorry!
a) General comment - I'm a native English speaker, and I find parsing the double-negative "not when the initiator provides none" incredibly hard. Is this necessary phrasing, or could this be changed to be a bit more readable?
* There is undefined behaviour when only one party supports channel binding. I think. Note typo in the first sentence.
* In practice, if an acceptor does not provide a channel binding, some mechanisms ignore channel bindings entirely, such as Kerberos.
* Conversely, if the initiator does not provide channel bindings, but the acceptor does, channel bindings are typically not ignored. I have no idea what this means in practice - does authentication fail? I get that impression from the later paragraphs.
* I don't understand the note. I think it says: This latter behaviour is sensible, since to allow security context establishment to succeed in this case would be problematic absent any indication of whether channel binding was used. Maybe? But I note that's also what this document recommends later in §3, so I suspect I'm wrong.
* There is no such indication in GSS-APIv2u1.
It's a mystery to me why this is in this document. The rationale isn't explained at all. It might be that this is obvious to anyone indoctrinated into the dark art of GSS-API, which I'm certainly not. But it's first mentioned in §1.1 as if it were a necessary extension for addressing the problems described in §1. Is GSS_Set_context_flags() always to be called with an empty context?
* §1, Page 2, "provides provides" (as noted before).
* §3, Page 7, "This strong sugestion"
I'm still confused about the outcome where the Initiator supports channel bindings but does not support the flag, and the Acceptor does not support channel bindings. In SCRAM, this case is special, and the Initiator ends up passing a channel binding essentially saying it could have done it if you'd asked. This allows an Acceptor to determine if a downgrade attack were in effect or not.. I have no clue if this is common in GSS-API.
In any case, if an Initiator is unable to know if the channel bindings were used or not, I agree with the initial assessment that this is problematic. On that basis, I'm uncomfortable with the suggestion that an Acceptor SHOULD ignore the channel bindings and continue anyway - but there are clear trade offs between interoperability and security here.
I would therefore suggest this recommendation is downgraded to OPTIONAL (ie, a MAY), and the pros and cons spelt out clearly.
> binding. I think. Note typo in the first sentence.
behavior when only one party provides them.
> mechanisms ignore channel bindings entirely, such as Kerberos.
like "when only provided by one party"?
> that impression from the later paragraphs.
Yes - per section 3, the acceptor fails to establish a security context.
> document recommends later in §3, so I suspect I'm wrong.
Nico, do you have comments here?
> * There is no such indication in GSS-APIv2u1.
which way we specify it.
> GSS_Set_context_flags() always to be called with an empty context?
instruct the GSSAPI implementation what flags they understand.
> * §1, Page 2, "provides provides" (as noted before).
> * §3, Page 7, "This strong sugestion"
> if this is common in GSS-API.
> (ie, a MAY), and the pros and cons spelt out clearly.
We're talking about the third bullet in section 3, right?
to me; Nico, do you have feelings in this regard?
I think "provides none" is confusing - it's not a natural English formation. "when only provided by one party" etc seem more understandable to me.
Right. That could use some clarification.
instruct the GSSAPI implementation what flags they understand..
Interesting - the channel bindings are transferred in SCRAM within the GS2 prefix (or header). I was expecting this case to be common. Alexey Melnikov or others might remember more detail about how that behaviour came about.

References: §3
 §1
 §1
 §1
 §3
 §3
 §1
 §3