Re: [TLS] SPNEGO over TLS - proposed new work item

[Martin Rex <martin.rex@xxxxxxx>]

Followup on myself...

Martin Rex wrote:
> 
> Stefan Santesson wrote:
> > 
> > As such the proposal has changed in the way that SPNEGO has been removed
> > from the proposal and replaced with  direct exchange of GSS-API tokens.
> > The slides for the presentation tomorrow has been sent to Eric and should
> > be up on the meeting materials page before the TLS meeting.
> 
> A thought that came to me during todays tls meeting was the following:
> 
> With exiting SSL/TLS (and -implementations), the authenticated peer
> becomes part of the SSL session state in the SSL session cache.

I meant the peers cert and cert chain (when one was sent) becomes
part of the SSL session.

> 
> When including an "external" authentication in the TLS handshake,
> what happens with the information about the authenicated peer,
> how is it "persistet", so that it will be transparently available
> when that SSL session is later resumed?
> 
> Some features of existing GSS-API mechanisms (and future features,
> in particular about authorization attributes and subject alt name
> retrieval) might be extremely non-trivial to persist in the
> SSL session cache.

At first glance, one may think about using "gss_export_sec_context()"
and "gss_import_sec_context()".  But even when using the transfered
context only to retrieve information about the authenticated identity
on session resume, it may not work.

potential problems:
 - SSL sessions can be forked in high numbers (and it is actually
   the most interesting feature of SSL session caching), while
   it is undefined whether a exported gssapi security context can be
   imported more than once.  It may work for many pure user-space
   library implementations of gssapi mechanisms.

 - Even if it does work (not covered by the GSS-API v2 spec),
   the actual use of message protection facilities on a duplicated
   and multiple times imported security context token will likely
   have serious security implications, like re-use of same crypto-keys
   with same sequence numbers, and in the case of symmetric stream
   ciphers for confidentiality protection, the exact same keystream
   may get used over and over again...

 - weird things like Microsoft's impersonation model might become
   tricky to implement.

 - credential delegation within gss-api will not work in a straightforward
   fashion -- how does the application recieve the gssapi cred handle
   and how can it later release it.  How will multiple import of
   an exported security context token affect a delegated credential?


A TLS-integrated (instead of HTTP-based GSS-API authentication) will
also not work with existing SSL accellerators, and create a burdon
for server-side (=reverse) proxies/loadbalancers.

Btw. for large AppServers there are real performance benefits when the
client authentication is not performed at the TLS layer (and **NOT** tied
to the TLS channel) but instead at the HTTP or application level.
The processing load (including the costly client authenication)
can be much better loadbalanced to a farm of backend servers.

-Martin

_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls