Re: Preemptive authentication throws IllegalStateException using ISA proxy server

[Oleg Kalnichevski <ol...@apache.org>]

On Tue, 2008-11-11 at 10:32 -0800, Henrich Kraemer wrote:
> > What for? As long as the connection is reused the overhead of an extra
> > request/response round trip is negligible (at least it does not outweigh
> > additional security risks)
> 
> I disagree. Extra roundtrips are worth avoiding for high latency
> connections.
> 

You are very welcome to disagree.


> It is unclear to me how much risk is added by this.
> I am not a security expert, so these statements should be
> taken with caution.

I am no security expert either, but to me the whole idea of sending user
credentials to an unknown host, especially in clear text, sounds like a
complete lunacy.

> - BASIC is not secure unless done over SSL. So I think one can assume
>   that it is only offered over SSL when security matters.
> - DIGEST is also relatively unsecure. It is not clear to me that
>   preemptive authentication increases the risk very much. Compared
>   to cases where each request causes a unauthorized response it
>   might even improve security as the matching unauthorized response
>   does not precede immediately the response.

The longer nonce is reused the more vulnerable DIGEST authentication
becomes. I do not see how this could possibly improve security. 

> One added risk is that the client may send Authorization headers
> to the wrong protection space (defined in RFC 2617) and thus leaks
> information.
> However this risk can be eliminated if the notion of the
> protection space is properly implemented.
> 

How exactly are you suggesting this should be done? 


> >
> > > Our app does not know ahead of time what kind of authentication is
> > > needed for the encountered targets and proxy (if any) as these are
> > > user configurable.
> > >
> >
> > The thing is _only_ BASIC authentication scheme lends itself to
> > preemptive authentication. Unless you are sure the target server accepts
> > BASIC, preemptive authentication is pretty much pointless.
> >
> > > With preemptive authentication enabled the extra request/response pair
> > > is only needed for the first request. Once the user provided
> > > credentials HttpClient keeps the credentials in the HttpClients' state
> > > field. HttpClient uses these from then on as long as the same
> > > HttpClient instance is used.
> > > This works as described as long as:
> > > 1. Not both the target and the proxy require authentication and
> > > 2. The proxy is not an ISA proxy using NTLM authentication. A proxy
> > > with digest or basic authentication does work.
> >
> > (Some soft of) preemptive DIGEST authentication works with HttpClient
> > 4.0 only.
> >
> > > In my mind an HttpClient should understand cases when preemptive
> > > authentication cannot be used and then ignore preemptive
> > > authentication mode.
> > >
> > > Does this scenario make sense?
> >
> > Can it be you are confusing credentials caching and preemptive
> > authentication?
> 
> With preemptive authentication I mean:
> 1. Setting the Authorization header.
> 2. Enabling an http client application to do this when it makes sense
> given the rules of RFC 2617.
> 
> For DIGEST authentication this involves:
> a. Providing the protection space for which credentials are requested.
> b. In addition to the credentials and their protection space, the
> app needs to know the nonce, nonce count and opaque values in order
> to form the authorization header.
> An authentication session is initiated by an unauthorized response
> and updated by a subsequent Authentication-Info header received or
> another unauthorized response with stale=TRUE.
> Each request send increases the nonce count, which must be tracked
> as well.
> 
> For BASIC authentication the authentication session does not
> carry information needed to form a preemptive authorization
> header beyond the associated realm.
> 
> HttpClient could choose to support both 1 and
> 2 such that an application would only have to enable
> preemptive authentication and the library would do all needed
> tracking of authentication sessions.
> I was under the impression that HttpClient 3's
> preemptive mode does just this -- at least for BASIC
> authentication.
> 
> The examples given for preemptive authentication
> for HttpClient 3 require the preemptive credentials are known in
> advance.

I do not understand. How exactly do you intend to authenticate
preemptively without knowing credentials in advance?

> I find this too limiting as it does not allow to implement
> apps that implement preemptive authentication in the sense
> mentioned as web browsers do.
> 
> Is this a limitation of HttpClient 3?
> 
> >
> > > Are there better ways to avoid the extra request/response?
> >
> > This extra request/response pair usually has a clear purpose:
> > transmitting an authentication challenge, which is necessary to provide
> > some degree of security.
> >
> > > I believe the challenge every request was seen using a vanilla apache
> > > httpd 2.x. server. Perhaps some simple server side configuration
> > > should be suggested?
> > > Is using preemptive authentication mode for this purpose outside of
> > > what it was designed for?
> > >
> >
> > Please consider moving to HttpClient 4.0 if you need a more flexible
> > authentication framework. HttpClient 4.0 can be tweaked to perform
> > preemptive authentication using BASIC and partially DIGEST scheme as
> > described below:
> >
> 
> I will look into this more when I get a chance.
> 
> Two things I noticed on a quick scan:
> AuthScope which is used in CredentialsProvider's
> getCredentials(AuthScope authScope) captures the realm.
> However for DIGEST authentication the protection
> space also involves the domain challenge parameter (See RFC 2617,
> section 3.2.1). I am not quite sure what consequences this has if
> any.
> 

As far as I understand domain attribute can useful when re-using
authentication challenge details for subsequent requests.   

> Also it seems that Authentication-Info headers are not looked
> at by the HttpClient 4. Presumably this would have to be done by
> the application in some way. Will this cause problems?
> 
> 

One cannot completely rule out the possibility of this provoking a
full-scale Martian invasion or accelerating the global warming.
Otherwise 

We _happily_ take patches. You are _very_ welcome to submit a better
implementation of DIGEST authentication. The existing code has not been
worked on since 2003 and could certainly be improved in many ways.

Oleg 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: Preemptive authentication throws IllegalStateException using ISA proxy server

[Oleg Kalnichevski <ol...@apache.org>]

...


> > > The examples given for preemptive authentication
> > > for HttpClient 3 require the preemptive credentials are known in
> > > advance.
> >
> > I do not understand. How exactly do you intend to authenticate
> > preemptively without knowing credentials in advance?
> 
> One can observe this in a single firefox 3 window. Firefox asks
> on the (first?) unauthorized response possibly filling in the
> fields with persisted credentials for and then sends preemptive
> authorization headers for requests compatible with the
> protection domain.
> 

There is absolutely _nothing_ that prevents you from popping up a dialog
asking the user for username and password, initializing BasicAuthScheme
and sticking it into the HttpContext.

...

> >
> > > Also it seems that Authentication-Info headers are not looked
> > > at by the HttpClient 4. Presumably this would have to be done by
> > > the application in some way. Will this cause problems?
> > >
> > >
> >
> > One cannot completely rule out the possibility of this provoking a
> > full-scale Martian invasion or accelerating the global warming.
> > Otherwise
> >
> > We _happily_ take patches. You are _very_ welcome to submit a better
> > implementation of DIGEST authentication. The existing code has not
> been
> > worked on since 2003 and could certainly be improved in many ways.
> 
> Thanks, I will keep this in mind.
> I do not have a coded patch -- at this point its mind vaporware.
> I am also not in a position to contribute at this time but that
> may change, for example if one cannot implement this at all which
> at this point I do not assume.
> 

I understand IBM employees need to apply for special permissions in
order to contribute code to an open-source project

Anyways, to sum things up, I _personally_ see very little value in
preemptive authentication but will happily take a patch for review from
an external contributor.

Oleg 

> >
> > Oleg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: Preemptive authentication throws IllegalStateException using ISA proxy server

[Henrich Kraemer <he...@us.ibm.com>]

See comments below.

Thanks,
Henrich


Oleg Kalnichevski <ol...@apache.org> wrote on 11/12/2008 02:14:33 AM:

> On Tue, 2008-11-11 at 10:32 -0800, Henrich Kraemer wrote:
> > > What for? As long as the connection is reused the overhead of an
extra
> > > request/response round trip is negligible (at least it does not
outweigh
> > > additional security risks)
> >
> > I disagree. Extra roundtrips are worth avoiding for high latency
> > connections.
> >
>
> You are very welcome to disagree.
>
>
> > It is unclear to me how much risk is added by this.
> > I am not a security expert, so these statements should be
> > taken with caution.
>
> I am no security expert either, but to me the whole idea of sending user
> credentials to an unknown host, especially in clear text, sounds like a
> complete lunacy.
>
> > - BASIC is not secure unless done over SSL. So I think one can assume
> >   that it is only offered over SSL when security matters.
> > - DIGEST is also relatively unsecure. It is not clear to me that
> >   preemptive authentication increases the risk very much. Compared
> >   to cases where each request causes a unauthorized response it
> >   might even improve security as the matching unauthorized response
> >   does not precede immediately the response.
>
> The longer nonce is reused the more vulnerable DIGEST authentication
> becomes. I do not see how this could possibly improve security.
>
> > One added risk is that the client may send Authorization headers
> > to the wrong protection space (defined in RFC 2617) and thus leaks
> > information.
> > However this risk can be eliminated if the notion of the
> > protection space is properly implemented.
> >
>
> How exactly are you suggesting this should be done?
>
>
> > >
> > > > Our app does not know ahead of time what kind of authentication is
> > > > needed for the encountered targets and proxy (if any) as these are
> > > > user configurable.
> > > >
> > >
> > > The thing is _only_ BASIC authentication scheme lends itself to
> > > preemptive authentication. Unless you are sure the target server
accepts
> > > BASIC, preemptive authentication is pretty much pointless.
> > >
> > > > With preemptive authentication enabled the extra request/response
pair
> > > > is only needed for the first request. Once the user provided
> > > > credentials HttpClient keeps the credentials in the HttpClients'
state
> > > > field. HttpClient uses these from then on as long as the same
> > > > HttpClient instance is used.
> > > > This works as described as long as:
> > > > 1. Not both the target and the proxy require authentication and
> > > > 2. The proxy is not an ISA proxy using NTLM authentication. A proxy
> > > > with digest or basic authentication does work.
> > >
> > > (Some soft of) preemptive DIGEST authentication works with HttpClient
> > > 4.0 only.
> > >
> > > > In my mind an HttpClient should understand cases when preemptive
> > > > authentication cannot be used and then ignore preemptive
> > > > authentication mode.
> > > >
> > > > Does this scenario make sense?
> > >
> > > Can it be you are confusing credentials caching and preemptive
> > > authentication?
> >
> > With preemptive authentication I mean:
> > 1. Setting the Authorization header.
> > 2. Enabling an http client application to do this when it makes sense
> > given the rules of RFC 2617.
> >
> > For DIGEST authentication this involves:
> > a. Providing the protection space for which credentials are requested.
> > b. In addition to the credentials and their protection space, the
> > app needs to know the nonce, nonce count and opaque values in order
> > to form the authorization header.
> > An authentication session is initiated by an unauthorized response
> > and updated by a subsequent Authentication-Info header received or
> > another unauthorized response with stale=TRUE.
> > Each request send increases the nonce count, which must be tracked
> > as well.
> >
> > For BASIC authentication the authentication session does not
> > carry information needed to form a preemptive authorization
> > header beyond the associated realm.
> >
> > HttpClient could choose to support both 1 and
> > 2 such that an application would only have to enable
> > preemptive authentication and the library would do all needed
> > tracking of authentication sessions.
> > I was under the impression that HttpClient 3's
> > preemptive mode does just this -- at least for BASIC
> > authentication.
> >
> > The examples given for preemptive authentication
> > for HttpClient 3 require the preemptive credentials are known in
> > advance.
>
> I do not understand. How exactly do you intend to authenticate
> preemptively without knowing credentials in advance?

One can observe this in a single firefox 3 window. Firefox asks
on the (first?) unauthorized response possibly filling in the
fields with persisted credentials for and then sends preemptive
authorization headers for requests compatible with the
protection domain.

>
> > I find this too limiting as it does not allow to implement
> > apps that implement preemptive authentication in the sense
> > mentioned as web browsers do.
> >
> > Is this a limitation of HttpClient 3?
> >
> > >
> > > > Are there better ways to avoid the extra request/response?
> > >
> > > This extra request/response pair usually has a clear purpose:
> > > transmitting an authentication challenge, which is necessary to
provide
> > > some degree of security.
> > >
> > > > I believe the challenge every request was seen using a vanilla
apache
> > > > httpd 2.x. server. Perhaps some simple server side configuration
> > > > should be suggested?
> > > > Is using preemptive authentication mode for this purpose outside of
> > > > what it was designed for?
> > > >
> > >
> > > Please consider moving to HttpClient 4.0 if you need a more flexible
> > > authentication framework. HttpClient 4.0 can be tweaked to perform
> > > preemptive authentication using BASIC and partially DIGEST scheme as
> > > described below:
> > >
> >
> > I will look into this more when I get a chance.
> >
> > Two things I noticed on a quick scan:
> > AuthScope which is used in CredentialsProvider's
> > getCredentials(AuthScope authScope) captures the realm.
> > However for DIGEST authentication the protection
> > space also involves the domain challenge parameter (See RFC 2617,
> > section 3.2.1). I am not quite sure what consequences this has if
> > any.
> >
>
> As far as I understand domain attribute can useful when re-using
> authentication challenge details for subsequent requests.
>
> > Also it seems that Authentication-Info headers are not looked
> > at by the HttpClient 4. Presumably this would have to be done by
> > the application in some way. Will this cause problems?
> >
> >
>
> One cannot completely rule out the possibility of this provoking a
> full-scale Martian invasion or accelerating the global warming.
> Otherwise
>
> We _happily_ take patches. You are _very_ welcome to submit a better
> implementation of DIGEST authentication. The existing code has not been
> worked on since 2003 and could certainly be improved in many ways.

Thanks, I will keep this in mind.
I do not have a coded patch -- at this point its mind vaporware.
I am also not in a position to contribute at this time but that
may change, for example if one cannot implement this at all which
at this point I do not assume.

>
> Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>