kerberos authentication with neon 0.29.3
danil at visualsvn.com
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
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
- 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,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2530 bytes
Desc: not available
Url : http://lists.manyfish.co.uk/pipermail/neon/attachments/20100324/b120975d/attachment.obj
More information about the neon