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

[Martin Rex <martin.rex at sap.com>]

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