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

[Stefan Santesson <stefans at microsoft.com>]

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.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: Simon Josefsson [mailto:simon at josefsson.org]
> Sent: den 21 mars 2007 18:34
> To: Pasi.Eronen at nokia.com
> Cc: Ari Medvinsky; tls at ietf.org
> Subject: [TLS] Re: Review of draft-santesson-tls-gssapi-00
>
> <Pasi.Eronen at nokia.com> writes:
>
> > Ari Medvinsky wrote:
> >>
> >> Pasi,
> >>
> >> 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'm not sure if I understand this concern. Certainly a TLS library
> > doing GSS-API would tell the application "handshake completed"
> > only after the GSS-API part was also completed?
>
> I'm not convinced of that.  It is useful for TLS library APIs to be
> consistent with the TLS protocol.  Your proposal was to add the
> GSS-API negotiation after the TLS handshake.
>
> What this means in practice is that, to speak in library-specific API
> terms, that applications after calling gnutls_handshake() will have to
> call gnutls_gssapi_handshake().  This is similar to what we did for
> TLS/IA, after gnutls_handshake() the application calls
> gnutls_ia_handshake() to perform the inner handshake.  Only once both
> calls have finished successfully will the application be satisfied.
>
> I disagree that this is a serious problem.  Yes, both TLS libraries
> and applications must be changed, but they need to be changed to
> support this functionality anyway.  The changes inherent in Pasi's
> proposal aren't that much bigger than those in Stefan's original
> proposal.
>
> /Simon
>
> _______________________________________________
> TLS mailing list
> TLS at lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls

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