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

[Stefan Santesson <stefans at microsoft.com>]

The problem is that it is very hard to engage into a discussion unless the objections are substantiated.

Considering the original proposal there is 1 isolated event (the GSS exchange) that hands a very specific piece of information to a standard TLS initialization process.
This happens to be input to key derivation.

   5. Key Derivation

      After successful completion of the gss_token messages, the client and
      server each obtain 46 bytes of key random data using the GSS-API PRF.
      This data is the TLS pre-master secret.

Therefore it is hard to understand what other security concerns there could be in the context of TLS other than the quality of the resulting key.

Structurally, the problem with your proposal that has been pointed out to me is that many use of TLS requires authentication have to be established before the finished message, or it will be useless. This aspect needs to be analyzed to determined whether completing authentication before the finished message is an absolute requirement for a solution to be meaningful.

As I understand this, the current status of this work is that we have not yet decided to adopt this work item, but that we should explore this issue further to see if we can come up with an acceptable solution. It would be great if you could confirm and elaborate how we will work towards a decision to accept or reject this work.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: Pasi.Eronen at nokia.com [mailto:Pasi.Eronen at nokia.com]
> Sent: den 20 mars 2007 14:13
> To: Stefan Santesson
> Cc: tls at ietf.org
> Subject: RE: [TLS] Review of draft-santesson-tls-gssapi-00
>
> Stefan Santesson wrote:
>
> > > 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'm not sure what Eric had in mind here, but I don't think key
> strength is the issue here. As we found out with e.g. PEAP and IKEv2,
> adding a new layer or round of authentication can *reduce* security
> if the layers/rounds are not coupled together in the right way.
> This *is* a big deal!
>
> (I'm referring to the "Man-in-the-Middle in Tunneled Authentication"
> paper by Asokan, Niemi and Nyberg; and related work.)
>
> I think Eric's concern was that the proposal would be easier to
> analyze if the interaction between current TLS state machine and
> GSS-API would be done in some other way that in the current draft.
>
> <snip>
> > 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".
>
> No disagreement from me here...
>
> Best regards,
> Pasi

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