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

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Dave Cridland
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] does not specify channel binding
   behavior when only one party provides provides none.  In practice,
   some mechanisms (such as Kerberos [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.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Robbie Harwood
Dave Cridland <[hidden email]> 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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Dave Cridland


On Fri, 15 Feb 2019 at 19:39, Robbie Harwood <[hidden email]> wrote:
Dave Cridland <[hidden email]> 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. 

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten