[TLS] Review of draft-santesson-tls-gssapi-03

[Simon Josefsson <[e-mail]>]

Hi.  We'd like to support GSS-API user authentication in GnuTLS.  I
don't care strongly about which approach to use to achieve that goal.
I've seen several drafts that could work, and believe it is important
that we reach consensus on one approach or we'll have different
approaches deployed soon.  I reviewed this draft since it appears to be
the most recent one still being worked on.  Generally I believe the
document looks good.

1) One major concern I have is that section 6 specifies a new GSS-API
mechanism that appear to be mostly unrelated the specification of the
gss_api TLS extension.  I believe it would simplify things considerably
if this section was moved to a separate document.  The GSS-API mechanism
is unlikely to be implemented by a TLS library, and is thus not within
the scope of the TLS WG.  Frankly, I'm not convinced it is useful to
have that GSS-API mechanism on the standards track in the IETF.  The
document says:

   It is possible to design a GSS-API mechanism that can be used with
   FKA-TLS in order to, for example, provide client authentication, and
   is so weak that its GSS- API token MUST NOT be in clear text over the
   open network.  A good example is a GSS-API mechanism that implements
   basic authentication.  Although such mechanisms are unlikely to be
   standardized and will be encouraged in no circumstance, they exist
   for practical reasons.

If that is indeed the only motivation for section 6, I strongly believe
it doesn't belong in this document.

Further, section 6 seems to be underspecified and needs more work.  For
example, there is no discussion how the inner TLS channel is terminated.
I didn't write down all my concerns with the mechanism.  If it brought
back as a separate draft, I may review that.

2) Section 5 disallows use of client X.509 authentication when the
gss_api extension is used.  I see no reason to actively disallow X.509
client authentication.  There may be situations where it is desirable to
use both X.509 authentication and some GSS-API mechanism, e.g., for
two-factor authentication.

3) Section 3 contains:

   Initially the client computes the gss_api TLS extension data by
   calling GSS_Init_sec_context() [RFC2743] to establish a security
   context.  The TLS client MUST set the mutual_req_flag and identify
   the server by targ_name so that mutual authentication is performed in
   the course of context establishment.  The extension_data from the
   client contains the output token of GSS_Init_sec_context().

   If a GSS-API context cannot be established, the gss_api TLS extension
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   MUST NOT be included in the client hello message and it is a matter
   of local policy on the client whether to continue or reject the TLS
   authentication as if the gss_api TLS extension is not supported.

   If the mutual authentication is not available on the established GSS-
                                                        ^^^^^^^^^^^^^^^^
   API context, the PSK key exchange described in Section 2 of [RFC4279]
   ^^^^^^^^^^^
   MUST NOT be selected, and the DHE_PSK or RSA_PSK key exchange MUST be
   negotiated instead in order to authenticate the server.

Here it is unclear to me what is meant by "established GSS-API context".
The first call to gss_init_sec_context does generally not lead to an
established context, several invocations to that function may be
necessary to get an established context.  Similarly, the mutual
authentication output flag from GSS_Init_sec_context cannot be relied on
until the context has been established.

What is intended here?  Does the middle paragraph refer to the situation
where the initial call to GSS_Init_sec_context fails completely?  And
the final paragraph refer to the situation where the call to
GSS_Init_sec_context succeeds and a security context is established, but
the mutual authentication flag not asserted?  If my understanding is
correct, I can suggest better wordings here.

Section 3 also says:

   o  If the server key exchange message is present, the PSK identity
      hint as defined in Section 5.2 of [RFC4279] MUST be empty, and it
      MUST be ignored by the client.

I see no reason for the client to ignore this?  If the server MUST send
an empty PSK identity, the client should reject anything else.
Alternatively, change the MUST to SHOULD if there are situations where
the PSK identity will not be empty.

4) The definition of the data structure for the gss_api extension data
appear to be missing from the document.  I assume it is identical to the
TokenTransfer structure?  I suggest adding a note describing this where
the gss_api ExtensionType is described.

5) Does the wire protocol differentiate between GSS_S_CONTINUE_NEEDED
and GSS_S_COMPLETE?  I'm thinking if the initial GSS_Init_sec_context
call returns GSS_S_COMPLETE.  The server will call
GSS_Accept_sec_context which shouldn't return any data.  The server
sends back a 0b string.  How can the client differentiate this from when
GSS_Accept_sec_context returned GSS_S_CONTINUE_NEEDED?  Perhaps the
answer is that the client simply disconnect in this situation, but maybe
that has to be noted.

6) What purpose does the TokenTransferType serve?  It is never discussed
in the text.  It appears to be designed to allow non-GSS-API tokens in
the future.  I don't think that would be a good idea.  I would prefer
that the TokenTransferType was dropped from the document.

/Simon

_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls