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

[Stefan Santesson <stefans at microsoft.com>]

Eric,

I'm sorry, but I need more information to understand your concern.

> As for taking security out of the picture, that was your claim not
> mine. For me, this state machine issue *is* a security issue and
> it's not purely an issue of establishing a key with a sufficiently
> strong algorithm.

What other security issue than the strength of the key is there?
TLS does not require any user authentication, so any added technology here can only be positive if the alternative in anonymous.

Regarding key strength, I think all cryptographic experts would agree that:

Good key XOR bad key = good key

At least if they are produced independent of each other, e.g. that the bad key is not actively selected with knowledge of the good key to cancel it or make it bad.
Following this logic, you can safely have another process creating a key of un-known strength and XOR it with the "good" key of TLS, and preserve the security level of TLS.

This simple assumption, makes the security impact very easy to analyze with respect to cryptographic strength.

> I've explained this as clearly as I can. Coupling two state machines
> is a big deal and needs careful analysis. I haven't seen any.

First I don't see them really as coupled. They are performing independent of each other with respect to the information exchange. So we have one protocol that allows another protocol exchange inside it. That is not very uncommon.

The coupling comes only in terms of some resulting information being handed over to the TLS state machine upon completion of the sub process.
I represent a vendor that is interested to do just this, and see no problem with it.
So yes, it would help a great deal to understand why this is a "big deal". Maybe we missed something, or maybe this isn't that big of a problem

If it would not turn out to be a big deal, we have a significant win here by allowing numerous non-PKI based authentication technologies to be used with TLS. That is a "big deal".


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: EKR [mailto:ekr at networkresonance.com]
> Sent: den 9 mars 2007 16:57
> To: Stefan Santesson
> Cc: martin.rex at sap.com; tls at ietf.org
> Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00
>
> Stefan Santesson <stefans at microsoft.com> writes:
>
> > Eric,
> >
> > I hear what you say. I still wander why that is a problem, more than
> > philosophically.
> > I said IF, we can take security out of the picture (if we can solve
> that issue so whatever GSS-API come up with, security is preserved),
> what is then the problem?
>
> I've explained this as clearly as I can. Coupling two state machines
> is a big deal and needs careful analysis. I haven't seen any.
>
> As for taking security out of the picture, that was your claim not
> mine. For me, this state machine issue *is* a security issue and
> it's not purely an issue of establishing a key with a sufficiently
> strong algorithm.
>
> -Ekr
>
>
>
> > Also provided that there are ways for the state machine to bail out
> and detect the end of the exchange, then what is the actual problem
> with that.
> >
> > To time consuming?
> > To bandwidth consuming?
> > To insecure anyway?
> > just not pretty enough?
> > Or something else..
> >
> > It doesn't seem very radical to me to have a protocol design which
> allows an arbitrary number or roundtrips for a sub process as long as
> the main process can bail out/timeout gracefully. It wouldn't be the
> first time in protocol design.


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