[kitten] Review of draft-ietf-kitten-channel-bound-flag

[Dave Cridland <[e-mail]>]

Hi all,

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?

For example, at the beginning of page 2:

   However, GSS-APIv2u1 [RFC2743
<https://tools.ietf.org/html/rfc2743>] does not specify channel
binding
   behavior when only one party provides provides none.  In practice,
   some mechanisms (such as Kerberos [RFC4121
<https://tools.ietf.org/html/rfc4121>]) 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!  Since the
   GSS-APIv2u1 does not provide any such indication, this document
   corrects that flaw.


So, I understand from this:
* 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.

Is that right?

b) Empty Contexts

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?

c) Typographical errors

* §1, Page 2, "provides provides" (as noted before).
* §3, Page 7, "This strong sugestion"

--

Further notes:

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.

Dave.