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

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

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.

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.

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.

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

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.


-Martin

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