-1

As described in RFC 4559, the Negotiate mechanism may take several requests to complete a GSSAPI context. I cannot understand from the RFC what mechanism is used to associate those requests with one another, however. To take the example described in section 5 of the the RFC:

1:
  C: GET dir/index.html

2:
  S: HTTP/1.1 401 Unauthorized
  S: WWW-Authenticate: Negotiate

3:
  C: GET dir/index.html
  C: Authorization: Negotiate a87421000492aa874209af8bc028

4:
  S: HTTP/1.1 401 Unauthorized
  S: WWW-Authenticate: Negotiate 749efa7b23409c20b92356

5:
  C: GET dir/index.html
  C: Authorization: Negotiate 89a8742aa8729a8b028

This is clear to me up until step 5. Assuming there are potentially many clients doing authentication at the same time, how does server know that the Authorization header in step 5 is the response to the data from step 4? I can't see any mention of session cookies or anything, and while I'm not an expert on GSSAPI, I don't think there's anything inherent in the GSSAPI data that can be used to associate it with an authentication session.

So what's the deal? :)

Dolda2000
  • 25,216
  • 4
  • 51
  • 92
  • You'd need to decrypt the Negotiate data to know what it is exactly. That would certainly give you the answer... – Alexis Wilke Aug 11 '14 at 01:17
  • @AlexisWilke: But the GSSAPI data is supposed to be opaque to the user of GSSAPI. Even if I were to break abstraction and decrypt it, however, I very much doubt it contains any kind of session ID. – Dolda2000 Aug 11 '14 at 01:17

2 Answers2

2

State is maintained using the TCP connection. RFC-4559 doesn't spell this out directly, likely because it would make the author feel dirty. But they elude as much in section 6 when discussing "Session-Based-Authentication" when proxies are involved. This requirement is also "called-out" in the last paragraph of RFC-7230 section 2.3 when discussing how HTTP is supposed to be a stateless protocol:

Some non-standard HTTP extensions (e.g., [RFC4559]) have been known to violate this requirement, resulting in security and interoperability problems

There is even more ambiguity with another requirement in the last paragraph in Section 6:

When using the SPNEGO HTTP authentication facility with client-supplied data such as PUT and POST, the authentication should be complete between the client and server before sending the user data. The return status from the gss_init_security_context will indicate that the security context is complete. At this point, the data can be sent to the server.

So the server should remember the authentication state after the context is successfully completed (and sent the client the 200 with the last token), to let-in one last request containing the actual payload?

Your confusion is justified.

E_net4
  • 27,810
  • 13
  • 101
  • 139
Glenn Lane
  • 3,892
  • 17
  • 31
  • I was wondering if that might not be the case, but I didn't want to accept it unless I found an explicit reference to it, which I never did. That paragraph from RFC 7230 seems to be about as clear about it as I could hope for outside of it being explicitly said in RFC 4559, however. How unfortunate. – Dolda2000 Dec 20 '21 at 01:32
0

From RFC 7235

5.1.2. Considerations for New Authentication Schemes

There are certain aspects of the HTTP Authentication Framework that put constraints on how new authentication schemes can work:

o HTTP authentication is presumed to be stateless: all of the information necessary to authenticate a request MUST be provided in the request, rather than be dependent on the server remembering prior requests. Authentication based on, or bound to, the underlying connection is outside the scope of this specification and inherently flawed unless steps are taken to ensure that the connection cannot be used by any party other than the authenticated user (see Section 2.3 of [RFC7230]).

Which is how I remembered it, but I wanted to make sure. So each request that the user sends includes all the necessary credentials. The server itself knows nothing about what the authentication is. It just asks whether the credentials are valid, and if the answer is yes, go on with the request.

Community
  • 1
  • 1
Alexis Wilke
  • 19,179
  • 10
  • 84
  • 156
  • I'm sorry if I'm being dense, but I don't really see how this answers the question. It just seems to verify that it's a mystery, no? :) – Dolda2000 Aug 11 '14 at 02:31
  • The authentication is hidden in that 'strange' number being sent, each time the client sends a request to the server. In other words, the server (Apache) does not need to have a session ID since you send the necessary authentication data each time as required. – Alexis Wilke Aug 11 '14 at 04:13
  • You seem to misunderstand. What I'm asking is not how the server recognizes the client in the future after authentication is complete, but how it does it *during authentication*, given that `Negotiate` authentication, unlike `Basic` or `Digest`, may need several requests to complete. To quote the RFC: *"If the context is not complete, the server will respond with a 401 status code with a WWW-Authenticate header containing the gssapi-data. The client will decode the gssapi-data, pass this into Gss_Init_security_context, and return the new gssapi-data to the server."* – Dolda2000 Aug 11 '14 at 04:25