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

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

Ari Medvinsky wrote:
> 
> I have two objections to the proposal of doing a GSS exchange after the
> finished msgs:
> 1) Numerous existing applications expect to know the identity of the
> client upon completion of the handshake (e.g., consider https for
> existing web servers, there lots of other examples); your proposal would
> require major overhaul to the way apps are secured today with TLS

I completely disagree.  If you're doing the abstraction correctly,
it will be transparent for the existing web-servers.

You will need to insert an additional "tls-gss" layer on top of TLS
which does all the GSS-API wizardry, provides the TLS stack with
the necessary tokens for the mech oid negotiation and supplies
the gssapi context level tokens for the context establishment
following the TLS finished exchange.  This tls-gss layer might
persist GSS-API status/context information and  provide access
to things like authorization data.  You really don't want to
go all the way through the TLS layers to frob with gssapi
features and extensions.

Unless a severely broken application looks at the bits-on-the-wire,
it doesn't know and doesn't care where exactly the finished
message goes on the wire.  The App can (and SHOULD) only react to
API return codes tell the application "TLS handshake complete" --
and the tls-gss layer on top of TLS will indicate "finished" when
it is done with the gssapi handshake, which is all what the
web-server above will see and care about.


GSS-API was designed as a token-based protocol that can be inserted
into existing protocol stacks where it fits best.  Since GSS-API
authentication is something that the application cares about
(TLS doesn't and shouldn't care about this), the gss-api
authentication exchange should be layered on top.


>
> 2) Your proposal still requires the server to have an X509 certificate;
> the original proposal does not have this constraint.  There are
> scenarios where it is desirable not require server to have an SSL cert.

Personally, I'd really like to see a requirement for an X.509 server
cert, because this is what will provide interopability with older
TLS clients that don't support this extension.  It should be up
to the application to decide whether it can or wants to provide
alternative authentication methods if GSS-API based authentication
is not available.


-Martin

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