[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
- [TLS] Review of draft-santesson-tls-gssapi-03 Simon Josefsson
- RE: [TLS] Review of draft-santesson-tls-gssapi-03 Larry Zhu
- RE: [TLS] Review of draft-santesson-tls-gssapi-03 Larry Zhu
- [TLS] Re: Review of draft-santesson-tls-gssapi-03 Simon Josefsson
- Re: [TLS] Review of draft-santesson-tls-gssapi-03 Martin Rex
- Re: [TLS] Re: Review of draft-santesson-tls-gssapā¦ Martin Rex
- [TLS] Re: Review of draft-santesson-tls-gssapi-03 Simon Josefsson
- RE: [TLS] Review of draft-santesson-tls-gssapi-03 Larry Zhu
- [TLS] RE: Review of draft-santesson-tls-gssapi-03 Larry Zhu
- [TLS] Re: Review of draft-santesson-tls-gssapi-03 Simon Josefsson
- [TLS] RE: Review of draft-santesson-tls-gssapi-03 Larry Zhu