1

When running with Kerberos tickets, I have noticed that every firefox request has a different Authorization line in the HTTP header. I loaded a simple page, then hit the reload button several times and it was never the same. What causes this behavior? I would have thought that the Authorization line would stay constant for the duration of the Kerberos credentials. (Note that I got the credentials via the kinit command before firing up firefox.)

When the authentication method is Basic, then firefox continues to send the same base64 string of 'user:password' every time. This is the behavior I expected.

Any ideas?

No One in Particular
  • 2,846
  • 4
  • 27
  • 32
  • you are not giving anyone enough information to answer this question. You need to spend more time with the problem. – rook Jun 23 '12 at 09:08
  • Rook - are you saying that I need to dig into the firefox source code in order to figure out why the browser is continuously updating its Authorization element? If so, that is fine. I was more interested in the actual on-wire packets I see. Is it the expected behavior? (I am NOT a security expert.) Does this sound like a firefox bug? I somehow also lost our old comments. Sorry. – No One in Particular Jun 23 '12 at 14:48
  • You probably don't need into the source. But have you fired up wireshark? Are you sure firefox knows to use the right authentication method? No it doesn't sound like a firefox bug, it sounds like a difficult issue to debug and you aren't giving anyone enough information (including your self) to solve this problem. – rook Jun 23 '12 at 20:53
  • Rook - wireshark output shows exactly what I was saying from my traces. The Authorization element is different for each GET. In fact, I can see a request for a TGS between http:GET requests. So we are back to the original question - why does firefox go back to the KDC when the original ticket should be good for 8 hours? – No One in Particular Jun 23 '12 at 23:33

2 Answers2

0

mmm it is odd. Any chance that you can post snipptes of the wireshark output. One possibility is that the Service Ticket obtained is not cached and FF gets a service ticket. There have been implementations where a client will get a service but not cache it, instead go and get a service ticket every time needed. Sometimes it is because the process may not have write permissions and it is relatively an inexpensive operation ( a single round trip and symmetric encrypted data)

R V Marti
  • 347
  • 2
  • 5
  • RVM - I will see if I can post the wireshark output. (I doubt it, but you never know what the company will allow.) I presume that what you said is correct - that the ticket is NOT cached. This would seem to be a relatively easy task to do. (Is there any mozilla developers watching this?) – No One in Particular Jul 29 '12 at 01:16
0

This is due to various limitations in both HTTP and in how Negotiate-Auth works.

HTTP was originally designed as a stateless protocol, and HTTP's authentication system assumes that model. It was designed to do a full authentication exchange in each request; for example, with Basic, it's enclosing your full credentials in each request. With Negotiate-Auth and SPNEGO, the same thing is true: a brand new GSS-API context is created and a fresh authentication is performed with each request.

Yes, this is very wasteful. But there (currently) isn't any standardized way to authenticate once, establish a session, and then bind all subsequent requests to that session (the way that, say, IMAP, POP, or ssh does). There is some IETF work in this direction, but it's very preliminary.

The ticket is cached; it's not doing that much work each time. But the server and the client go through the whole GSS-API session dance each time.

rra
  • 3,807
  • 18
  • 29