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

[Nicolas Williams <[e-mail]>]

On Fri, Nov 20, 2009 at 02:39:59PM -0500, Glen Zorn wrote:
> GENERAL COMMENTS
> The reference to a document is not the document; for example, in the
> following excerpt from section 2, there are no names defined in the
> reference to RFC 2743:
>    The document uses many terms and function names defined in [RFC2743]
>    as updated by [RFC5554].
> Please change to something like
>    The document uses many terms and function names defined in RFC 2743
> [RFC2743]
>    as updated by RFC 5554 [RFC5554].
> Note that this comment applies globally to all such usages in the document.

I'm with Alexey on this.  The RFC Editor might even re-write this by
replacing the reference with the full title and reference.

(Personally I very much dislike unnecessary redundancy, as in "defined
in RFC 2743 [RFC2743]", but whatever style the RFC Editor thinks is
appropriate and consistent with current RFC Editor practice is what we
should go with.

> ABSTRACT
> The last sentence of the Abstract says: "See
> <http://josefsson.org/sasl-gs2-*/> for more information."  Unless the
> referenced URL is intended to be permanently available (and probably even
> then), this line should be removed before publication as an RFC.

I think that's clearly not intended to remain in the final RFC, but to
help reviewers understand the progression.  I agree that this is best
placed in a changelog-type section, but at this point it does not
matter.

> In paragraph 5, "The [RFC2743] section 3.1 initial context token header" has
> the sound of GSSAPI "code words" ;-).  Suggest changing to "The GSSAPIv2
> initial context token header (see section 3.1 of RFC 2743 [RFC2743])" or
> some such.

My attitude is that different technologies tend to have different
terminology, and we can't forever be explaining it when we have
documents that deal with more than one technology.  In this case the
reader is expected to, and indeed must have some familiarity with both,
SASL and the GSS-API.  I'm not sure how we could avoid that.

The text in qquestion is very specific as to where you'll find the
definition of "initial context token header": RFC2743, section 3.1.
That should suffice; it's certainly better than writing a lengthy
exposition on what a context token is, what an initial context token is,
what an "initial context token header" is, and why it's there.

(Also, FYI it's GSS-API, or GSS-API v2, update 1 -- not "GSSAPIv2".  One
of the many _annoying_ terminology bridging problems of the past is that
the original SASL/GSS-API bridge wasn't named properly.  As a result
"GSS-API" means one thing, and "GSSAPI" (without the hyphen) can mean
another, and you have to know the context in order to tell which it is.
Better to always be careful to include the hyphen.  This is really,
really annoying.  I hope this document will put that problem to bed for
good once GS2 is widely adopted..)

> 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

Note the use of 'may', 'must' and 'will' in the above.

"Authentication must fail" means that the server must fail
authentication.  "Authentication will fail" means that the GS2 message
exchange will proceed but authentication will necessarily fail as a
result of CB inputs differing on the client and server side.

> SECTION 6
> This section needs a lot of work if it is expected to be understood by
> non-members of the Illuminati ;->.  Just one example (of many possible):
> 
>    Example #3: a two round-trip GSS-API context token exchange, no
>    channel binding, no standard token header.
> 
>          C: Request authentication exchange
>          S: Empty Challenge
>          C: F,n,,<initial context token without
>                              standard header>
>          S: Send reply context token as is
>          C: Send reply context token as is
>          S: Send reply context token as is
>          C: Empty message
>          S: Outcome of authentication exchange
> 
> What does this mean?  What do 'F' & 'n' stand for?  How is it useful?  It
> might be claimed that these questions could be answered by dissecting the
> ABNF for the gs2 header, but I don't think that's a good answer: examples
> should be self-contained.

I don't agree.  Example protocol exchanges need to be simplified --
we're trying show what the flows look like, not to be exacting in
detail.  The more explanation the example needs, the less clear it
obviously is.  In the example above the "<initial context token
withoutstandard header>" makes it clear, if you've read the preceding
sections, that the "F,n,," part is the GS2 header.  We could add quotes
to the F,n,, part, if you think that will help.

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

Thanks!

Nico
--