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

From: Simon Josefsson <[email-masked]>
Date: Tue, 11 Sep 2007 10:21:29 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Larry Zhu <[email-masked]>
Date: Tue, 11 Sep 2007 17:24:03 -0700

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

Thanks for the positive feedback.

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

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

   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?

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

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

> answer is that the client simply disconnect in this situation, but maybe

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.

> 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:[email-masked]]
Sent: Tuesday, September 11, 2007 1:21 AM
To: [email-masked]
Subject: [TLS] Review of draft-santesson-tls-gssapi-03

3) Section 3 contains:

Section 3 also says:

/Simon

---

From: Larry Zhu <[email-masked]>
Date: Tue, 11 Sep 2007 19:56:16 -0700

Note that -04 is available here: http://www.secure-endpoints.com/tls-gss/draft-santesson-tls-gssapi-04.txt.

Thanks,

--larry

-----Original Message-----
From: Larry Zhu
Sent: Tuesday, September 11, 2007 5:24 PM
To: Simon Josefsson; [email-masked]
Subject: RE: [TLS] Review of draft-santesson-tls-gssapi-03

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

--larry

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

3) Section 3 contains:

Section 3 also says:

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 12 Sep 2007 08:25:18 +0200

>    TLS-handshake, typically to facilitate client authentication.

I like this.

This text leads to an even stronger argument for permitting X.509 client
authentication in the first authentication step.  Otherwise you are
vulnerable to tunneling attacks of the GSS-API authentication step since
there appear to be no channel binding used.

Btw, I forgot to bring up channel bindings.  Have you considered
supporting it?  It is not critical to me, I consider X.509 or OpenPGP
authentication sufficient to solve the tunnel problem.

>    of local policy on the client whether to continue or reject the TLS

I like this.

>    authenticate the server.

What does this imply in practice?  If GSS_Init_sec_context clears the
mutual_state flag after the first invocation (but before GSS_S_COMPLETE
or PROT_READY), is the client required ("MUST NOT") to not use PSK?  The
GSS-API specification says the mutual_state value is undefined in this
case, section 2.2.1 of RFC 2743:

   Not all of the optionally-requestable features will be available in
   all underlying mech_types. The corresponding return state values
   deleg_state, mutual_state, replay_det_state, and sequence_state
   indicate, as a function of mech_type processing capabilities and
   initiator-provided input flags, the set of features which will be
   active on the context.  ... These state indicators' values are
   undefined unless either the routine's major_status indicates
   GSS_S_COMPLETE, or TRUE prot_ready_state is returned along with
   GSS_S_CONTINUE_NEEDED major_status

This would lead to false positives rejecting PSK.

One solution is for implementation to only enable PSK for GSS-API
mechanisms which it knows out of band will lead to mutual
authentication, and to reject the session if the mechanism eventuelly
didn't lead to mutual authentication.

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

After re-reading this a few times, I think it may be saying what I
concluded in my last paragraph.  I'm not sure of this though.

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

Yes I think so.

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

Ok.  Are there any examples of when it would ever be useful to use a PSK
identity?  Anonymous GSS-API mechanism?  If you know of any example
where this could be useful, adding it would help the understanding.

> do you think this is better? Thanks.

Ah, I see.  You fail to specify the size of the length field though.  I
would prefer to make the token explicit though, by adding e.g.:

        struct {
            opaque gss_api_data<0..2^32-1>;
        } GSSAPIExtensionData;

>    MUST tear down the connection in this case.

Hm.  How would this work in the following situation?

  Client Hello   ------>
  GSS_Init_sec_context returns
  GSS_S_COMPLETE and a data buffer

                             <---------    Server Hello
                                           GSS_Accept_sec_context
                                           returns GSS_S_COMPLETE
                                           What to include in gss_api?

If the server doesn't send a gss_api extension token, the client doesn't
know that the server supported the GSS-API extension.

If the server sends a 0b token, the client will tear down the connection
because it cannot differentiate this from when the
GSS_Accept_sec_context did not return an additional token.

The gss_api data in the ServerHello may need to include a boolean saying
whether there actually was data returned or not:

        struct {
            opaque gss_api_data<0..2^32-1>;
            boolean finished;
        } GSSAPIExtensionData;

A similar problem may exist in the TokenTransfer handshake messages --
what if the client is waiting for the server to send something but the
server believes it is finished?  The session will eventually time out,
but that is poor error handling.  This would be avoided if the
gss_api_token tokens in TokenTransfer structure contained the
GSSAPIExtensionData structure above with a boolean 'finished'.

There may be simpler solutions to this problem though.

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

I believe this is the wrong place to solve that problem.  I also
disagree that it actually is a problem.  The HandShakeType namespace is
not close to running out.  Less than 10% of the values have been
allocated today (0-23 allocated, 24-255 unallocated according to IANA).

If you want to have this field, you need to specify how implementations
should behave if multiple TokenTransfer tokens are received during the
handshake and when only some of them contain supported token_type's.
Otherwise this structure can never be used in any future extension in a
reliable way.

/Simon

---

From: Martin Rex <[email-masked]>
Date: Wed, 12 Sep 2007 18:12:00 +0200 (MEST)

>    MUST tear down the connection in this case.

Only nitpicking: In the GSS-API original design, it is possible to
receive a context-level token after having seen GSS_S_COMPLETE from
the local context establishment function.

The obvious and non-controversial case has been deprecated
(the context deletion token).  The specified behaviour was too
pass this token to gss_process_context_token().

Whether or not an peer is allowed to create an context-level error
token (not a delete token) that the peer does not expect is fairly
unclear, however.  Implementations of the Kerberos 5 gssapi
mechanisms send such error tokens (containing a KRB_ERROR message)
in some situations.  I don't know whether these implementations refrain
from sending the error token if the peer does not expect it
(e.g. when the client does not request mutual authentication
 and uses an incorrect target name on a Microsoft Windows platform).

I don't know what other GSS-API mechanisms (e.g. based on SPKM)
have been doing in this area.

The one thing that is clear from the GSS-API spec is that an application
caller MUST NOT call a context establishment call (init_sec_context,
accept_sec_context) on a context for which a previous call to
the context establishment functions returned GSS_S_COMPLETE.
If at all, such a token must be consumed through gss_process_context_token().
and in the two scenarios described in the GSS-API standard, the
context deletion token and the context error token, this will result
in the security context to become invalid/unusable...

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 12 Sep 2007 19:16:26 +0200 (MEST)

> >    TLS-handshake, typically to facilitate client authentication.

I also like this text better (however I still don't like the entire
proposal and want to come up with an alternative proposal--unfortunately
personal and health issues are severely draining my time at the moment).
It adds round-trips, though.

> there appear to be no channel binding used.

I fully agree.  I mentioned a couple of times that I consider it
important to make it as easy as possible for consumers to enable
cert-based server authentication along with GSS-API client authentication.
(this doesn't help the "simple" (unidirectional) gssapi mechanisms,
 however, since this proposal precludes their use entirely).

> authentication sufficient to solve the tunnel problem.

AFAIK, the architecture of this proposal does provide secure channel
bindings, in that it uses gss_prf output for the creation of the
master secret using the PSK ciphersuites.

-Martin

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 13 Sep 2007 10:31:21 +0200

> master secret using the PSK ciphersuites.

I missed that.  Right, it seems to be solved.

Thanks,
Simon

---

From: Larry Zhu <[email-masked]>
Date: Fri, 14 Sep 2007 14:05:56 -0700

> the local context establishment function.

Right, it should be further qualified as "context establishment tokens". thanks,

--larry

-----Original Message-----
From: Martin Rex [mailto:[email-masked]]
Sent: Wednesday, September 12, 2007 9:12 AM
To: Larry Zhu
Cc: [email-masked]; [email-masked]
Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-03

-Martin

---

From: Larry Zhu <[email-masked]>
Date: Fri, 14 Sep 2007 14:23:12 -0700

> Ah, I see.  You fail to specify the size of the length field though.  I would prefer to make the token explicit though, by adding e.g.:
>
>        struct {
The size of the length field is defined in section 2.3 of RFC3546. It is 2 in octets.

> Otherwise this structure can never be used in any future extension in a

A new value would indicate a new handshake message. I would make this clear, hopefully that addresses your comments w.r.t. this point.

Assuming that, all your comments have been addressed to your satisfactory, right?

-----Original Message-----
From: Simon Josefsson [mailto:[email-masked]]
Sent: Tuesday, September 11, 2007 11:25 PM
To: Larry Zhu
Cc: [email-masked]
Subject: Re: Review of draft-santesson-tls-gssapi-03

I like this.

I like this.

Yes I think so.

        struct {

  Client Hello   ------>

                             <---------    Server Hello
                                           GSS_Accept_sec_context
                                           returns GSS_S_COMPLETE

        struct {

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Sep 2007 10:22:53 +0200

> The size of the length field is defined in section 2.3 of RFC3546. It is 2 in octets.

Ok, now I get it, thanks.

> A new value would indicate a new handshake message. I would make this
> clear, hopefully that addresses your comments w.r.t. this point.

A new handshake message type or just a new handshake message?  If the
latter, I still think you need to discuss how implementations should
react if they receive unsupported token_type's.  I look forwward to new
text.

> Assuming that, all your comments have been addressed to your

Yes I think so, although I may have opinions on how the issues are
ultimately solved in later drafts.

/Simon

---

From: Larry Zhu <[email-masked]>
Date: Tue, 18 Sep 2007 10:45:20 -0700

Simon wrote:
> A new handshake message type or just a new handshake message?  If the latter, I still think you need to discuss how implementations should react if they receive unsupported token_type's.  I look
> forwward to new text.

The former, it should be treated as a new handshake message type.

> ultimately solved in later drafts.

Thanks for the positive acknowledgement.

--larry

-----Original Message-----
From: Simon Josefsson [mailto:[email-masked]]
Sent: Tuesday, September 18, 2007 1:23 AM
To: Larry Zhu
Cc: [email-masked]
Subject: Re: Review of draft-santesson-tls-gssapi-03

/Simon