On 10/12/2015 10:21 PM, Rick van Rein wrote: > Hello Benjamin, > >> This would seem to require an application protocol doing some Kerberos >> exchanges up front to establish the Kerberos session key before pivoting >> into TLS-PSK in a STARTLS-esque fashion. If that's what the application >> protocol would look like, it seems like there's no reason not to go >> full-on GSSAPI with GSS_Pseudo_random to extract a PSK on both sides. > GSSAPI is too general IMHO; it specifies an unpredictable number of exchanges > and TLS cannot carry that.
There seems to be some miscommunication going on. My comment was in response to the proposal to "just use PSK" with the Kerberos session key as the "pre-shared" secret -- that is, it would be "pre-shared" immediately before initiating the TLS exchange. That would require that the application protocol send some Kerberos messages (so as to get both peers the same session key) before starting up TLS and using a PSK mode with that session key as the shared secret. If the application protocol is going to involve doing some "other stuff" before TLS, there's no reason why that "other stuff" has to be limited to pure Kerberos; multiple hops for a GSS-API exchange is fine for the "other stuff", which is *not* part of the TLS exchange. In your previous message, you (understandably) are resisting that, but I just wanted to make clear that it's just as feasible to run GSS-API to get a PSK to use for TLS as it is to run Kerberos to get a PSK, once the restriction of being part of the TLS exchange is removed. -Ben _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
