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

[Stefan Santesson <stefans at microsoft.com>]

Eric and Martin,

Thank you for elaborate comments on your positions.

Before getting into detailed discussions on your comments, I would like to figure out the principles of concerns and figure out if there is any common ground we could build this on.

As I understand you have 2 major concerns:

1) That the TLS state Machine has not control over the resulting security of TLS. I.e. if a bad GSS-API mechanism is deployed, it would degrade the security of TLS.
2) That the GSS-API exchange requires more than 1 roundtrip of messages to be completed.

Martin suggested a method for ensuring at least TLS level security. This has also crossed my mind but we decided not to go there initially. But how much concern would go away if we did this in a way where at least TLS security level is achieved?

If the TLS state machine still have control over the security level of the encryption key, would it still be a problem that several roundtrips is required for the GSS exchange?
If so, why is this a problem, except from an emotional purity perspective.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: Martin Rex [mailto:martin.rex at sap.com]
> Sent: den 8 mars 2007 18:52
> To: Stefan Santesson
> Cc: ekr at networkresonance.com; tls at ietf.org
> Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00
>
>
> Stefan Santesson wrote:
> >
> > I never got any response on this posting to the list.
> > I have sent a request to put this on the agenda for Prague.
> >
> > It would be great if we could continue the discussion so we could get
> > to an agreement on the future of this draft in Prague, or shortly
> thereafter.
>
> I do not like the key-exchange in draft-santesson-tls-gssapi-00.txt.
>
> Since the architecture leaves the message protection completely up
> to the TLS layer, it should also do this with the key exchange
> and _limit_ the GSS-API involvement to (a) authentication and
> (b) mixing gss-api provided entropy (if available) with
> traditional TLS-provided entropy for the pre-master secret.
>
> IMHO, the key exchange should be either DHE or RSA-encryption,
> where the latter will require an RSA-based server certificate,
> even if self-signed.
>
> The current proposal comes with too many ifs/restrictions for my taste.
>
> GSS-API does allow authentication-only and no-encryption gssapi
> mechanisms and the current proposal precludes their use, and I also
> don't think that we should mandate the availability of gss_prf
> functionality even for those mechanisms where this optional feature
> has recently be specified.
>
> Authentication-only gssapi mechanisms as well as integrity-only
> gssapi mechanisms will be unable to provide protection for the
> key exchange, which is why I think we should stick completely
> to the original SSL/TLS key exchange algorithms.
>
> One idea to mix the gssapi authentication into the key exchange
> would be to exchange a strong random string of the same length
> as the pre-master secret protected with the gssapi message
> protection gss_wrap(conf=true) and XOR it with the
> pre-master secret that is protected with the traditional TLS
> key exchange algorithm before use.  This extra random protected
> by gss_wrap(conf=true) should probably be generated by the server
> right after successful context establishment and sent to the client
> and should be applied (XOR'ed) by the client _after_ sending the
> ClientKeyExchange message and applied by the server after receiving
> the ClientKeyExchange message.
>
> The strength of the binding between the GSS-API authentication
> and the TLS communication channel will only be as strong as the
> gss_api message protection itself (i.e. no binding for authentication-
> and integrity-only gss-api mechanisms), but that is probably as good
> as it can get.
>
> Limiting the strength of the key exchange of a cipher suite like
> TLS_GSS_API_WITH_AES_256_CBC_SHA to a single-DES-based gssapi
> authentication seems to be a bad idea.
> In contast to that, securely mixing in additional entropy from gssapi
> authentication into a regular TLS key exchange shouldn't hurt.
>
>
> SSL/TLS (in contrast to GSS-API) was invented to provide a broad
> level of interoperability _on_the_wire_, while GSS-API was invented
> to provide interoperability NOT _on_the_wire_ but at the API level
> (as an extreme plug'n'play) between applications and GSS-API
> mechanisms,
> and at the same time being strictly limited to a particular gss-api
> mechanism and a single user-management/namespace.
>
>
> Setting up and using clients and servers with a future TLS-stack
> that allows for gss-api based authentication but rejects all
> cipher-suites without gss-api authentication (or makes it quite
> difficult for the users/admins to enable&configure non-gssapi
> ciphersuites), is IMHO heading in the wrong direction.
>
>
> Initial specs had a strong focus on interoperability (in order to
> establish a protected communication channel), ultimately leaving
> it up to the application to figure out ways to secure the
> authentication process (server-side uses the well-known endpoint
> identification, client-side SSL certs are still rare, and obvious
> design flaws in installed base (WinHTTP) make it difficult to
> migrate to SSL client certs today.
>
>
> So in the tradition of interoperability, I'd really like to see
> a requirement for future TLS implementations with support for
> gssapi-based authentication that they must offer alternative
> ciphersuites (ciphersuites with traditional server-authentication
> based on a Server certificate), and that these must be enabled
> by default (and only be disabled if the admin explicitly configures
> it that way).  We will have to wiggle out the details.
>
>
> -Martin

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