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

[Stefan Santesson <stefans at microsoft.com>]

In-line

Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: Martin Rex [mailto:martin.rex at sap.com]
> Sent: den 22 mars 2007 00:55
> To: Stefan Santesson
> Cc: tls at ietf.org
> Subject: Re: [TLS] Re: Review of draft-santesson-tls-gssapi-00
>
> Stefan Santesson wrote:
> >
> > I disagree that the application need to be altered in the original
> proposal.
> >
> > It all depends on where TLS obtains its policies and parameters.
> > If that is supplied by separate configuration or policy DB, then the
> > originally proposed handshake can be performed transparent to the
> > application.
>
> With a clean design, you'll have to alter the application.
>

I think this is where we have the principal disagreement. A clean design from an implementation standpoint allow applications to invoke TLS with no alterations to the applications. IN particular when the choice of authentication and encryption method is determined by a separate policy module. Many applications require this simplicity. Its easier to get things right within TLS implementation then to have applications to get this right. It is also much easier to upgrade the TLS implementation than all applications using it.

> A very short-sighted approach might work with some major hacks
> in some environments.
>
> Keep in mind that GSS-API abstraction normally means "authentication
> of a communication peer", and there is no requirement that this peer
> is anyhow related to user accounts of the local OS.
>

This would of course only be requested and invoked where it makes sense. I see no problem with controlling this.


> A clean architecture would ultimately allow binary plug-n-play of the
> gssapi mechanism with the TLS stack.  And since it is not know in
> advance what fancy gssapi extensions the mechanism will have, what
> the names will look like and wether or how gssapi state could
> be persisted, the TLS stack should NOT sit between the gssapi
> mechanism and the application, but underneath the gssapi mechanism.
> GSS-API state may include alternative names, authorization data
> and that information may be entirely independent (or incompatible)
> with the native-OS means to represent such data.
>

To me, the extnesion mechanism provide a precise and straightforward negotiation mechanism. This option will not be imposed on anyone that does not agree on using the particular GSS-exchange chosen.

> If someone says "In my scenario I could do it transparently",
> then he might be thinking with an extremely narrow focus and not
> sufficiently general for the architecture of the protocols at hand
> (TLS,GSS-API).
>
>
> Another issue:  TLS session can be cached and can be "forked".
> In fact, it is common practice to "fork" TLS sessions frequently.
>
> GSS-API security contexts, on the other hand, can not normally
> be duplicated.  And quite a lot of gssapi mechanism require/enforce
> a strictly sequential stream of protected messages (which is how
> they provide data replay protection).
>

Accordingly I would not expect a client and server to agree on using GSS-TLS unless it is meaningful and appropriate for the session. As I would not expect a server to accept anon-DH if client authentication is required.

> I really don't want to see the TLS stack being bothered with
> persisting state from the GSS-API authentication beyond
> a (flat) peer name.
>

And I think this problem is important enough to solve. I whish there was an easier way to do it that works transparent to applications. If there is, I'm more than willing to consider it.

/Stefan

>
> -Martin

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