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

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

Stefan Santesson wrote:
> 
> Before getting into detailed discussions on your comments,
> I would like to figure out the principles of concerns and
> figure out if there is any common ground we could build this on.
> 
> As I understand you have 2 major concerns:
> 
> 1) That the TLS state Machine has not control over the resulting
>    security of TLS. I.e. if a bad GSS-API mechanism is deployed,
>    it would degrade the security of TLS.
> 2) That the GSS-API exchange requires more than 1 roundtrip
>    of messages to be completed.

Actually, there's one more that hasn't been mentioned yet,
the issue of SSL session caching&resumption,

   - what GSS-API based authentication means for the state
     in the SSL session cache

   - how "leaky" is the abstraction

In case GSS-API authentication is hardwired into TLS (handshake)
in the proposed fashion, I would like to see a requirement that
the application has NO, NONE, ZERO control over the underlying
GSS-API operations, i.e. no access to the credential handles,
and in particular no access to the gssapi context handle.
There should be no attributes&characteristics available to
the application which the SSL/TLS stack does not know about
from an authentication, and the SSL/TLS stack should delete
the security context immediately after context establishment
(or failure) and NOT retain a context handle when it completes
the TLS handshake (so that there is no difference between
full TLS handshake and SSL session resume).

... this might not what Microsoft is looking, and it also
precludes the use of arbitrary authorization extensions.


If the application caller wants to play fancy games with
GSS-API and fiddle around with context handles and authorization
extensions, then we should NOT put GSS-API authentication
into the TLS handshake, but leave it up to the application
(and the application will have to deal with persisting
 context attributes and things like authorization data).


> 
> Martin suggested a method for ensuring at least TLS level security.
> This has also crossed my mind but we decided not to go there initially.
> But how much concern would go away if we did this in a way where at
> least TLS security level is achieved?
> 
> If the TLS state machine still have control over the security level
> of the encryption key, would it still be a problem that several
> roundtrips is required for the GSS exchange?

I've become accustomed to GSS-API over 12 years, so personally *I*
have less problems with the extra roundtrips than Eric.

In some areas, TLS is IMHO more "mature" and has been more carefully
analyzed and hardened than arbitrary GSS-API mechanisms.  GSS-API
based authentication might still have slight weaknesses that
have been addressed in TLS already (countermeasures against timing
attacks for decryption and padding failures).  I don't think that we can
"fix" those in TLS as long as GSS-API is being used for authentication,
even when the handshake is done outside of TLS, e.g. like at the
app-layer.

In GSS-API, there is no limit on the total number of round-trips
until it is determined whether authentication is successful or
has failed.  Performing the GSS-API handshake within TLS will
undoubtedly increase the number of states in the the TLS state
machine and require several additional transitions.

Setting an upper limit for the number of roundtrips acceptable
within the TLS handshake should be possible, but to be anywhere
near useful, we need at least two full roundtrips for GSS-API,
and to be on the safe side, I'd really like to see 3 full
roundtrips (i.e. two additional round-trips to the regular
TLS handshake).


-Martin

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