Re: [secdir] secdir review of draft-ietf-sasl-gs2-17

[Simon Josefsson <[e-mail]>]

Nicolas Williams <[e-mail]> writes:

>> SECTION 5
>> I find this section rather difficult to understand: not all of the possible
>> combinations of gs2-cb-flag and server support for channel bindings seem to
>> be covered.  A table might help, if not for that the gs2-cb-flag is
>> tri-valued & used to signal two different things.
>
> I believe we handled all cases.  There are three flag values and two
> server support alternatives.  I suppose we can add a table, something
> like:
>
>     FLAG	SERVER CB SUPPORT	DISPOSITION
>     ----	-----------------	-----------
>
>     n		Irrelevant		If server disallows non-channel-
>                                         bound authentication, then fail
>
>     y		CB not supported	Authentication may succeed
>
>     y		CB supported		Authentication must fail
>
>     p		CB supported		Authentication may succeed, with
>                                         CB used
>
>     p		CB not supported	Authentication will fail
>
>     <none>	CB not supported	Client does not even try because
>                                         it insists on CB

I have added this table to section 5.

>> The first paragraph says:
>> 
>>    GS2 does not use any GSS-API per-message tokens.  Therefore the
>>    setting of req_flags related to per-message tokens is irrelevant.
>> 
>> OK, but what should the client and server behavior should be WRT the flags?
>
> There's no actual behavior w.r.t. req_flags and ret_flags.  The GSS-API
> mechanism is free to enable per-msg token features not requested by the
> caller, but they are truly irrelevant: the application won't be using
> per-msg tokens.  It may make things simpler if we explicitly require
> that req_flags not be set:
>
>    GS2 does not use any GSS-API per-message tokens.  Therefore the
>    per-message token ret_flags from GSS_Init_sec_context() and
>    GSS_Accept_sec_context() are irrelevant; implementations SHOULD NOT
>    set the per-message req_flags.

This is in the document now too.

Thanks,
Simon