Re: [TLS] TLS renegotiation issue

[Martin Rex <[e-mail]>]

Nicolas Williams wrote:
> 
> > I would not mind if those TLS implementers with the GGF and SSPI
> > use the terminology and function parameters they formerly called
> > "channel bindings" (AFAIK SSPI doesn't have channel bindings)
> > to pass along the finished messages described in Erics document.
> 
> Neither would I.  Except that they _can't_ with Eric's proposal, not
> without violating abstractions and interpreting the contents of the
> channel bindings input, which is why I object.

The security context iterators (InitializeSecurityContext
and AcceptSecurityContext  or gss_init_sec_context/gss_accept_sec_context)
are designed to exchange opaque tokens between the peers (client
and server  / initiator and acceptor ) 

What you are looking for is a token exchange between two security
contexts, old and new.  Ultimately you could create full blown
iterator calls to do this.  Or a "cheap" one-token hack like this:

GetCarryOverData ( oldsecuritycontext, &opaque_buffer );
CreateSecurityContextWithCarryOver( opaque_buffer, &newsecuritycontext );
ReleaseBuffer( &opaque_buffer );

Or with just a single call:

CreateRenegoContext(oldcontext, flags, &newcontext);

with a little modification of the init and accept iterators so that
they can start with a context handle created by this new call
instead of a NULL handle.

The latter single-call approach seems the cleanest to me,
because it is the most flexible in case we ever find another
need to transfer information between an original and renegotiated
session -- without having to change apps that use a GSS-API style
architecture.  And it is the one which is the most difficult
to break by careless applications.  :)


Limiting the evolution of the TLS protocol and the interaction
between current and pending session states seems like an
unjustified restriction to me.  If a particular API has
a problem with a useful evolutionary change of TLS,
then this might be a design shortcoming in the API
and should be fixed there.  I don't think we should deny
in a very useful way just it might have an impact on
certain esoteric API architectures.  

Comparing the amout of work to (a) technically block
the renegotiation in the TLS implementation and 
(b) replace/update the renegotion with a secure
renegotiation for the OpenSSL-style architecture
and for the SSPI architecture, it seems that
the OpenSSL architecture is not so bad after all.

I have never looked at GGF.  Does it really create two
seperate, unrelated contexts similar to what SSPI does?
 

A while back, a vendor had his GSS-API mechanism certified
for interoperability with out application, and he told me
that this mechanism was built on top of OpenSSL.  I don't
know whether they have implemented renegotiation (I doubt it,
since that mechanism is not wire-compatible with native SSL
due to the GSS-API token framing.  But I could conceive
a renegotiation architecture without a seperate context
handle.


Maybe apps shouldn't be sitting straight on top of SSPI?
I'm glad we have our thin gsskrb5.dll between our own apps
and SSPI, because I had to work around several bugs and
backwards incompatible changes during the last 9 years,
and that additional abstraction helped me significantly
in the logistics of getting updates or workarounds
out to the customers.  Since we provide gsskrb5.dll
as OpenSource, customers could even do that themselves...


-Martin