0

I wrote a test client and server using the Cyrus SASL library, and I'm manually forcing it to select GSSAPI as the mechanism. While debugging, I printed the md5sum of each message as it was passed between the two. I noticed that the sequence seems to be the same every time I connect. That is, if the message sequence on the first negotiation was clientMessage1, serverResponse1, clientMessage2, etc... to successful authentication, if I then restart my client, the same clientMessage1, serverResponse2, clientMessage2,etc... sequence is repeated.

It seems to me like it would be a security concern. Is this the correct behavior and if so, should I be wrapping these communications in TLS or something?

1 Answers1

0

GSSAPI can use any number of underlying protocols. However, you are right, a replay attack could happen if it repeats the same messages.

Do you know what low-level protocol was used over GSSAPI?

Michael Graff
  • 6,588
  • 1
  • 23
  • 36
  • I'm connecting using TCP sockets... is that the "low-level protocol" you're speaking of? –  Jan 23 '10 at 00:30
  • No. The G in GSSAPI is 'generic', and GSSAPI can actually use any number of underlying protocols to get its job done. These could be anything from X509 certificates, Kerberos, some sort of challenge-response system, or even "none." If your GSSAPI uses SPEGNO, it has the ability to negotiate for any of these and select the one both sides have in common. – Michael Graff Jan 23 '10 at 00:44
  • Oh ok, I am using Kerberos 5. Thanks for clarifying. If there's anything else I'm leaving out, I'll do my best to supply that information as well. –  Jan 23 '10 at 01:01
  • 2
    It's true that GSSAPI itself can use a number of underlying mechanisms, but SASL only supports one use of GSSAPI, and that's for Kerberos. Nothing at all against Michael Graff--I'm just saying that SASL+GSSAPI implies Kerberos, for those watching at home. – John Zwinck Jan 23 '10 at 02:16