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

[Dave Cridland <[e-mail]>]

On Fri, 15 Feb 2019 at 19:39, Robbie Harwood <[e-mail]> wrote:

> Dave Cridland <[e-mail]> writes:
>
> > 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.
>
> Thanks Dave!
>
> > 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.
>
> Yes.  Suggested first sentence language:
>
>     However, GSS-APIv2u1 [RFC2743] does not specify channel binding
>     behavior when only one party provides them.
>
>
That works.


> > * In practice, if an acceptor does not provide a channel binding, some
> > mechanisms ignore channel bindings entirely, such as Kerberos.
>
> Yes.  In general it seems like the phrase "provides none" is confusing -
> is that right?  How do you feel about replacing it with language more
> like "when only provided by one party"?
>
>
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.


> > * 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.
>
> Yes - per section 3, the acceptor fails to establish a security context.
>
>
Right. That could use some clarification.


> > * 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.
>
> Nico, do you have comments here?
>
> > * There is no such indication in GSS-APIv2u1.
>
> Yes - specifying the behavior here is (in my view) more important than
> which way we specify it.
>
> > 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?
>
> Good point.  It's valid to call with a non-empty context as I understand
> (maybe Nico can speak more on this?), but the important attribute is
> ret_flags_understood, which there isn't currently a way to convey.  And
> then just doing it this particular way is based on how the Java bindings
> work (1.1).
>
> How about this for text in 1.1:
>
>     The design for signalling application flag support and empty
>     contexts is based on the Java Bindings of the GSS-API [RFC5653].  We
>     introduce a new function GSS_Set_context_flags() for applications to
>     instruct the GSSAPI implementation what flags they understand.
>     However, since the understood flags information needs to be present
>     before GSS_Init/Accept_sec_context() are called, we also introduce a
>     notion of empty contexts, and begin introduction of additional
>     context inquiry and mutation functions, which eventually will also
>     allow for simplified stepping to replace the
>     GSS_Init/Accept_sec_context() loop.
>
>
Yes, that makes sense.


> > c) Typographical errors
> >
> > * §1, Page 2, "provides provides" (as noted before).
> > * §3, Page 7, "This strong sugestion"
>
> Agreed, will fix.
>
> > 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.
>
> Interesting.  This doesn't sound like the kind of idiom we have
> elsewhere in GSSAPI (not that that's necessarily a bad thing)
>
>
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.


> > 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.
>
> We're talking about the third bullet in section 3, right?
>
>
Yes, that's the one.


>     Whenever the initiator application has 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 strong sugestion is for
>     interoperability purposes, and reflects actual implementations that
>     have been deployed.
>
> The difference between SHOULD NOT / MAY NOT isn't particularly important
> to me; Nico, do you have feelings in this regard?


Dave.