kerberos authentication with neon 0.29.3

Danil Shopyrin danil at
Tue Mar 23 17:54:18 EDT 2010

>> I notice that the SSPI code does not
>> process the server's response token in the 2xx response as the GSSAPI
>> code; maybe this is the issue but I can't fathom how.

We have investigated the problem and have found the following. The
current SSPI code doesn't correctly implement Kerberos authentication
because it doesn't process the final leg authentication token from the
server (in a 2xx response). The RFC 4559 says:
   A status code 200 status response can also carry a "WWW-Authenticate"
   response header containing the final leg of an authentication.  In
   this case, the gssapi-data will be present.  Before using the
   contents of the response, the gssapi-data should be processed by
   gss_init_security_context to determine the state of the security
   context.  If this function indicates success, the response can be
   used by the application.  Otherwise, an appropriate action, based on
   the authentication status, should be taken.

   For example, the authentication could have failed on the final leg if
   mutual authentication was requested and the server was not able to
   prove its identity.  In this case, the returned results are suspect.
   It is not always possible to mutually authenticate the server before
   the HTTP operation.  POST methods are in this category.

The problem exists in the current trunk and it also exist in versions
prior to 0.29.3. Unfortunately, this problem has been hidden by other
bug that was fixed by my patch in 0.29.3. The story is that my patch
in neon 0.29.3 have affected the neon's internal logic and the problem
becomes visible.

The behavior of neon in versions prior to 0.29.3 was the following:
* The client ignores final leg token from the server. Kerberos
authentication scheme is significantly violated.
* As soon as the first Kerberos token is generated, the client
re-sends it in each subsequent request. There can be two options:
  - the token is transferred in the subsequent requests and is ignored
by server.;
  - re-authentication is performed for each subsequent request (it
seems that mod_auth_kerb follows this way).
  Both options seems to be incorrect.

We have prepared a simple patch that enables SSPI code to verify 2xx
responses (attached). We have tested it with the VisualSVN Server and
everything works fine for us. Review and any possible comments are

Dariush, Amit: in order to test the proposed patch in your
environment, we can provide you with a special build of svn.exe
(statically linked with all the libraries including neon). Feel free
to contact me by private e-mail.

With best regards,
Danil Shopyrin
VisualSVN Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: neon-kerberos-2xx.patch
Type: application/octet-stream
Size: 2530 bytes
Desc: not available
Url : 

More information about the neon mailing list