kerberos authentication with neon 0.29.3

Kravzov Amit Aharon amitkar at
Wed Mar 24 12:13:48 EDT 2010

First of all, thanks for the help.
As I'm using neon only as part of AnkhSVN\TortoiseSVN, I think I can't check the fix with svn.exe.

Bert's answer (AnkhSVN Team) is that he will use this patch only if it comes from neon's trunk or some version of 0.29.x, so right now I'm in the middle of that loop. Any suggestion how can we check this fix so it will be possoble to officially commit it?


-----Original Message-----
From: Danil Shopyrin [mailto:danil at]
Sent: Tuesday, March 23, 2010 11:54 PM
To: joe at; neon at
Cc: Dariush Pietrzak; Kravzov Amit Aharon
Subject: Re: kerberos authentication with neon 0.29.3

>> 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 welcome!

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
This message (including any attachments) issued by RAFAEL- ADVANCED DEFENSE SYSTEMS LTD. 
(hereinafter "RAFAEL") contains confidential information intended for a specific individual and purpose, may 
constitute information that is privileged or confidential or otherwise protected from disclosure. If you are not 
the intended recipient, you should contact us immediately and thereafter delete this message from your 
system. You are hereby notified that any disclosure, copying, dissemination, distribution or forwarding of this 
message, or the taking of any action based on it, is strictly prohibited. If you have received this e-mail in error, 
please notify us immediately by e-mail mailto:lawraf at and completely delete or destroy any and all 
electronic or other copies of the original message and any attachments thereof.

More information about the neon mailing list