kerberos authentication with neon 0.29.3

Bert Huijben bert at vmoo.com
Mon Aug 9 10:12:11 EDT 2010



> -----Original Message-----
> From: Kravzov Amit Aharon [mailto:amitkar at rafael.co.il]
> Sent: zondag 27 juni 2010 9:46
> To: Joe Orton; 'Danil Shopyrin'; KATZIR MALKA LIAT;
> 'neon at lists.manyfish.co.uk'; 'Bert Huijben'; 'NathanaelRensen'; 'ml-
> neon at safo.in'
> Subject: FW: kerberos authentication with neon 0.29.3
> 
> Hi all,
> 
> Is there anything new we know about this issue? And how to proceed?
> 
> Joe, meanwhile is is possible to compile Ankh 2.1 with former version of
> neon for us, so we will able to work with VS2010?

	Ping,

@Joe, what is the status?

	Bert
> 
> Best Regards,
> Amit.
> 
> -----Original Message-----
> From: Kravzov Amit Aharon
> Sent: Thursday, June 10, 2010 8:24 AM
> To: Joe Orton
> Cc: 'Danil Shopyrin'; KATZIR MALKA LIAT; neon at lists.manyfish.co.uk; Bert
> Huijben; Nathanael Rensen; ml-neon at safo.in
> Subject: RE: kerberos authentication with neon 0.29.3
> 
> 
> Hello,
> 
> In my opinion we should first commit the patch. Joe, do you have an
> objection for that? Secondly, once we have discovered the cause for the
> performance issue, I believe it is inevitable to fix it.
> 
> Regards,
> Amit.
> 
> -----Original Message-----
> From: Danil Shopyrin [mailto:danil at visualsvn.com]
> Sent: Thursday, June 03, 2010 4:50 PM
> To: Joe Orton
> Cc: Kravzov Amit Aharon; KATZIR MALKA LIAT; neon at lists.manyfish.co.uk;
> Bert Huijben; Nathanael Rensen; ml-neon at safo.in
> Subject: Re: kerberos authentication with neon 0.29.3
> 
> 
> > I have prepared the following statically linked builds:
> >
> > * http://www.visualsvn.com/files/svn-neon-clear-sspi-context-1.zip
> > This is neon 0.29.3 with backported r1797 and
> > neon-clear-sspi-context-1.patch.
> >
> > * http://www.visualsvn.com/files/svn-neon-clear-sspi-context-2.zip
> > This is neon 0.29.3 with backported r1797 and
> > neon-clear-sspi-context-2.patch.
> >
> > *
> > http://www.visualsvn.com/files/svn-neon-clear-sspi-context-2-no-
> mutual.zip
> > This is neon 0.29.3 with backported r1797 and
> > neon-clear-sspi-context-2.patch. As a bonus, mutual Kerberos
> > authentication is also disabled in the build.
> >
> > I believe that svn-neon-clear-sspi-context-2.zip should work fine in
> > most cases.
> 
> Eyck, Amit and Nathanael have confirmed that all the provided builds work
> without errors for them. So we can proceed and commit one of the
> proposed patches:
> 
> > 1) neon-clear-sspi-context-1.patch
> 
> > This patch just appends the ne_sspi_clear_context() call to the
> > verify_sspi() function. This patch is very local and shouldn't affect
> > any other behavior.
> 
> > 2) neon-clear-sspi-context-2.patch
> 
> > The neon-clear-sspi-context-2 patch changes ths ah_post_send()
> > behavior to call the ne_sspi_clear_context() in any case when
> > sspi_context is not null.
> 
> I still prefer the neon-clear-sspi-context-2 patch. But code review will
be still
> helpful.
> 
> Note that comparing to neon 0.28.6, the current performance of
> authentication with mod_auth_kerb is really slower (but performance of
> Negotiate authentication with Windows-based servers is not degraded).
> Amit reports that it can be 20 times slower! This is caused by the
following
> facts:
> 
> * AFAICT, mod_auth_kerb authenticates clients per request (while
> VisualSVN Server and IIS authenticate clients per connection);
> 
> * the current neon's implementation isn't capable to effectively perform
per-
> request authentication;
> 
> * that's why additional 401 round-trips occur for the each request when
> mod_auth_kerb is used;
> 
> * AFAICT, the same additional 401 round-trips reproduce for GSSAPI clients
> on Unix/Linux (with neon 0.29.3). In other words, it's a higher level
problem
> and it affects both the SSPI and GSSAPI code.
> 
> The current behavior (neon 0.29.3 + one of the proposed patches) with
> mod_auth_kerb will looks like this: [[ 1. initial request gets an auth
challenge:
> C -> S : PROPFIND /foo S -> C : 401, WWW-Authenticate: Negotiate
> 
> 2. request resent with SSPI token
> C -> S : PROPFIND /foo, Authorization: Negotiate blob1
> S -> C : 200, WWW-Authenticate: Negotiate blob2
> 
> 3. subsequent request gets another auth challenge
> C -> S : PROPFIND /bar [ -> no Authorization header]
> S -> C : 401, WWW-Authenticate: Negotiate
> 
> 4. subsequent request resent with SSPI token
> C -> S : PROPFIND /foo, Authorization: Negotiate blob3
> S -> C : 200, WWW-Authenticate: Negotiate blob4
> ]]
> 
> 
> The old behavior (neon 0.28.6) with mod_auth_kerb looks like this: [[ 1.
initial
> request gets an auth challenge: C -> S : PROPFIND /foo S -> C : 401, WWW-
> Authenticate: Negotiate
> 
> 2. request resent with SSPI token
> C -> S : PROPFIND /foo, Authorization: Negotiate blob1
> S -> C : 200, WWW-Authenticate: Negotiate blob2
> 
> 3. subsequent request proceeds with the old(!) blob1 challenge C -> S :
> PROPFIND /bar, Authorization: Negotiate blob1 S -> C : 200, WWW-
> Authenticate: Negotiate blob3 ]]
> 
> Nevertheless that the old neon 0.28.6 behavior is much faster, it is
buggy.
> 
> First of all, I believe that this behavior is unintentional.
> 
> Secondly, the old behavior relies on the fact that ASC_REQ_REPLAY_DETECT
> flag is not enabled on the server. It is not safe to have
> ASC_REQ_REPLAY_DETECT disabled because this allows malefactor to be
> authenticated using stoled challenge.
> 
> I think that ideal behavior for mod_auth_kerb authentication should be
like
> this: [[ 1. initial request gets an auth challenge: C -> S : PROPFIND /foo
S -> C :
> 401, WWW-Authenticate: Negotiate
> 
> 2. request resent with SSPI token
> C -> S : PROPFIND /foo, Authorization: Negotiate blob1
> S -> C : 200, WWW-Authenticate: Negotiate blob2
> 
> 3. subsequent request sent with the new(!) authentication challenge C -> S
:
> PROPFIND /bar, Authorization: Negotiate blob3 S -> C : 200, WWW-
> Authenticate: Negotiate blob4 ]]
> 
> Anyway, I'm arguing to commit one of the proposed patches to make neon
> 0.29.3 compatible with mod_auth_kerb. The performance will be much
> slower (comparing to 0.28.6) but the behavior will be exactly the same as
in
> the GSSAPI code.
> 
> Then we can discuss the possible ways of performance improvements.
> 
> Any thoughts?
> 
> --
> 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 rafael.co.il 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