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

Larry Zhu <lzhu@windows.microsoft.com> Fri, 14 September 2007 21:23 UTC

Return-path: <tls-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWIdC-0004F9-Co; Fri, 14 Sep 2007 17:23:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWIdB-00049H-6z for tls@lists.ietf.org; Fri, 14 Sep 2007 17:23:17 -0400
Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWId9-0003bG-T5 for tls@lists.ietf.org; Fri, 14 Sep 2007 17:23:17 -0400
Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.177.2; Fri, 14 Sep 2007 14:23:15 -0700
Received: from tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com (157.54.70.14) by tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) with Microsoft SMTP Server id 8.1.177.1; Fri, 14 Sep 2007 14:23:15 -0700
Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::5efe:10.255.255.2]) by tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com ([::1]) with mapi; Fri, 14 Sep 2007 14:23:14 -0700
From: Larry Zhu <lzhu@windows.microsoft.com>
To: Simon Josefsson <simon@josefsson.org>
Date: Fri, 14 Sep 2007 14:23:12 -0700
Thread-Topic: Review of draft-santesson-tls-gssapi-03
Thread-Index: Acf1Bc2ABRdp6GMYSB+i5kpjNWRJKgCDqc1Q
Message-ID: <B78121AEC3DFC949BF5080E7BCDD79F49D5D76A055@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
References: <87bqc9k3xy.fsf@mocca.josefsson.org> <B78121AEC3DFC949BF5080E7BCDD79F49BB7915A39@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <87abrse6y9.fsf@mocca.josefsson.org>
In-Reply-To: <87abrse6y9.fsf@mocca.josefsson.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: -108.0 (---------------------------------------------------)
X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606
Cc: "tls@lists.ietf.org" <tls@lists.ietf.org>
Subject: [TLS] RE: Review of draft-santesson-tls-gssapi-03
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

Simon Josefsson wrote:
> 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;
The size of the length field is defined in section 2.3 of RFC3546. It is 2 in octets.


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

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:simon@josefsson.org]
Sent: Tuesday, September 11, 2007 11:25 PM
To: Larry Zhu
Cc: tls@lists.ietf.org
Subject: Re: Review of draft-santesson-tls-gssapi-03

Larry Zhu <lzhu@windows.microsoft.com> writes:

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

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.

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

I like this.

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

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.

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

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.

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

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;

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

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.

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

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


_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls