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

From: Dave Cridland <[email-masked]>
Date: Fri, 8 Feb 2019 22:56:51 +0000

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.

---

From: Robbie Harwood <[email-masked]>
Date: Fri, 15 Feb 2019 14:39:45 -0500

Dave Cridland <[email-masked]> 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?
>
>    behavior when only one party provides provides none.In practice,

Yes.  Suggested first sentence language:

    However, GSS-APIv2u1 [RFC2743] does not specify channel binding
    behavior when only one party provides them.

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

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

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

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

---

From: Dave Cridland <[email-masked]>
Date: Fri, 15 Feb 2019 21:47:12 +0000

>     behavior when only one party provides them.
That works.

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

> Yes - per section 3, the acceptor fails to establish a security context.
Right. That could use some clarification.

>     GSS_Init/Accept_sec_context() loop.
Yes, that makes sense.

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

> We're talking about the third bullet in section 3, right?
Yes, that's the one.

Dave.