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

[Larry Zhu <[e-mail]>]

Simon Josefsson wrote:
> We'd like to support GSS-API user authentication in GnuTLS.

This is great to hear. Thanks for posting the message to the list.

>  Generally I believe the
> document looks good.

Thanks for the positive feedback.

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

This was added to address Martin's comments. I had offline email with Martin, Sam, and Pasi, in which I proposed
to use TLS-renegotiation to replace section 6. In other words, section 6 is completely removed in -04, with the following new text added in the section related to how to choose a GSS mechanism.


   It is generally beneficial to provide privacy protection for
   mechanisms that send client identifiers in the clear.  Furthermore,
   encrypting the GSS-API data can improve the strength of the overall
   systems, and when applicable complicate offline dictionary attacks
   against users' secrets based on which the keying materials are
   derived.  Therefore unless otherwise specified, TLS-renegotiation as
   defined in section 7.4.1.1 of [RFC4346] MUST be used to encrypt the
   GSS data in FXA-TLS gss_api extension.  This implies that the client
   and server negotiate FKA-TLS after completing a certificate-based
   TLS-handshake, typically to facilitate client authentication.

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

I can see the confusion in the original text. What do you think of the updated text for this here?


   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.

   Unless otherwise specified, the PSK key exchange described in Section
   2 of [RFC4279] MUST NOT be selected if the mutual authentication MAY
   NOT be available on the established GSS-API context, and the DHE_PSK
   or RSA_PSK key exchange MUST be negotiated instead in order to
   authenticate the server.  Because mutual authentication (if
   requested) cannot be guaranteed until GSS_S_COMPLETE is returned,
   typically through multiple invocations of GSS_Init_sec_context()
   calls, the PSK key exchange is allowed only through additional
   specifications unless the server authentication is provided a-priori
   and outside of the GSS-API exchange.  For example, when FKA-TLS
   is negotiated via TLS-renegotiation per Section 5, the server
   authentication may be provided before the initial GSS-API context
   establishment token.

the motivation of this text is to allow PSK key exchange to be used when Kerberos is selected.
We are trying to build a mechanism that does not use certifications, and GSS-API does not guarantee mutual auth in the first init call as you noted, hence we had the awkward text. Now do you think you understand the intention of this text?

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

It is fine to change the MUST to SHOULD. That is in-line with the IETF tenet that the original text intends to describe.

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

I suspect that the confusion here is related to the use of the TLS type opaque. I would rephrase the original text as follows:

   The gss_api TLS extension is defined according to [RFC3546].  The
   extension data for the gss_api extension type contains a GSS-API context establishment token.
  GSS-API tokens are thus carried within the TLS hello messages.


     enum {
         gss_api(54321), (65535)
     } ExtensionType;

   The payload of the gss_api extension is an GSS-API token.  In other
   words, the length of the byte vector (the TLS type opaque) for the extension data is the
   length of the GSS-API token and the content of the byte vector
   contains exactly the content of the GSS-API token.

do you think this is better? Thanks.

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

A note is added as follows:

   As implied by GSS-API, a GSS-API token SHOULD NOT be received after
   the context is established (GSS_S_COMPLETE is returned), the receiver
   MUST tear down the connection in this case.

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

The following text is added:

   The TokenTransferType field allows future extensions of the
   TokenTransfer handshake message.  The gss_api_token type is the only
   value defiend in this document.

The motivation is that the # of handshake messages is perceived as limited. Here by adding the
TokenTransferType field, we effectively add 254 new handshake messages to the TLS protocol. One should be frugal when the resources are plenty, shouldn't she?

--larry


-----Original Message-----
From: Simon Josefsson [mailto:[e-mail]]
Sent: Tuesday, September 11, 2007 1:21 AM
To: [e-mail]
Subject: [TLS] Review of draft-santesson-tls-gssapi-03

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


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