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

[Robbie Harwood <[e-mail]>]

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.

> * 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"?

> * 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.

> * 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.

> 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)

> 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?

    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?

Thanks,
--Robbie