RE: [TLS] GSS based PSK-TLS

[Larry Zhu <lzhu at windows.microsoft.com>]

Martin Rex wrote:
> With the current proposal this will be pretty difficult and awkward.

Please elaborate. The FKA-TLS is a supper set of PSK-TLS, can you
explain why a different way to establish the shared key would make it
worse.

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

I would like to understand what are the things unsaid.

> - GSS-API naming

This ID does not define additional naming. Any naming scheme would work.
If there is the need to call out for a specific naming, please do tell.


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

What are those? If you have non-standard extensions, you will need to
take care of it yourself. The draft will work with standard GSS-API
operations.
We envision it is sufficient with what is said in -03.


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

What is the TLS API you are referring to here?


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

Let me reiterate that the ID does not encourage plug'n'play of GSS
mechanisms.

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

 Let me reiterate that this ID does not encourage plug'n'play of GSS
mechanisms.


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

It is hard to trust that cert and authenticate the server. This approach
provides a high-scalable and robust solution without PKI.


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

This is an understatement. This approach pushes the solution down the
stack.

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

Please describe the problems and see if this ID can address them.

--larry



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