Re: [TLS] GSS based PSK-TLS

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

Larry Zhu wrote:
> 
> Martin Rex wrote:
> > TLS session can be cached, resumed and forked.  Although performance
> > is an issue for a significant amount of our customers, the RSA-server-
> > authentication in the SSL handshake is NOT normally an issue (it only
> > becomes an issue if the SSL session cache is configured too small).
> 
> This will continue to work. I would like to emphasize FKA-TLS is a
> variant of PSK-TLS.

With the current proposal this will be pretty difficult and awkward.

> 
> > GSS-API security context can not be cached and not be resumed.
> 
> you do not need to resume in the GSS level. You can resume in the
> PSK-TLS level. Again, this is a variant of PSK-TLS, you have all the
> bells and whistlers of PSK-TLS.

As soon as you say GSS-API, a lot of unsaid things become an issue
which the current draft does not address at all, and which create
huge architectural problems (for the TLS implementation).

 - GSS-API naming

 - GSS-API extensions, like authorization
   (Microsoft will likely want impersonation to work)
   persitence of GSS-API objects and attributes and access to
   such attributes (currently existing as well as future defined ones)

With the proposed architecture FKA-TLS bolts GSS-API deep into
the TLS (protocol) stack, and in order to make anything besides
an "authentication succeded" boolean available to the calling
application, you will have to hack up the TLS API in a massive
way to make the underlying GSS-API accessible and session
caching interoperate smoothly with GSS-API related feature
requests and expectations of the calling application.


Compare this to an architecture, where you have an almost vanilla
TLS stack with support for a small "GSS-API mechanism list negotiation
extension plus server name signalling" and one or more vanilla
legacy GSS-API mechanisms bundled by an thin additional glue layer
that combines this into a TLS-with-adjacent-GSSAPI-handshake,
where you can plug'n'play gssapi mechanisms and TLS stacks.

In such an architecture, you may still have to solve the
GSS-API persistence in this additional top-level glue layer,
but you can support close to any existing and conceivable GSS-API 
mechanism and the necessary changes to SSL/TLS are
minimalistic and fully transparent/orthogonal to the
evolution of the TLS protocol&stack (like addition of
new ciphersuites).  Not having to deal with GSS-API
extensinos, objects, object persistence and naming
within TLS will be by far the biggest advantage. 


Generating a self-signed RSA server certificate is trivial and a non-issue.

Ignoring a self-signed RSA server certificate when the server
is authenticated by GSS-API as well is trivial and a non-issue.

Do NOT overestimate the security of the "endpoint identification"
that Web-Browsers currently perform (EKR: I really appreciate your
choice of terminology in rfc-2818).  As I said before, the approach
taken by SSH is much better, even without CA-signed host keys.



-Martin


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