You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by ca...@nokia.com on 2003/03/20 09:52:18 UTC

Digest Authentication

Hi all

I've been trying unsuccessfully to use the Digest authentication in Tomcat with my webapp. I need it because Basic authentication is too weak and I cannot use SSL on the client side.

I noticed that the implementation in Tomcat has some problems that I describe below:

1. In org.apache.catalina.realm.RealmBase it is said that it implements RFC 2069 but IMHO it actually implements partially RFC 2617 since it uses the qop option to calculate the digests, which first appeared in RFC 2617

2. RFC 2617 clearly says that if qop is not present the request-digest should be calculated as in RFC 2069. However in the current implementation it is always calculated as RFC 2617, i.e.

String serverDigestValue = md5a1 + ":" + nOnce + ":" + nc + ":"
						+ cnonce + ":" + qop + ":" + md5a2;

This excludes the possibility of qop being null in which case the serverDigestValue should be

String serverDigestValue = md5a1 + ":" + nOnce + ":" + md5a2;

Also the case of qop being auth-int is not taken into account at all

3. Finally, there is a problem when obtaining the values qop and nc. Some browsers send qop with quotes, for instance IE, but Mozilla sends them without quotes. Same with nc. 

What happens is that in org.apache.catalina.authenticator.DigestAuthenticator the qop is calculated always removing the quotes. That makes that in a mozilla's request qop=auth becomes qop=ut and the Digest calculation is different. I'm not sure what should be the right thing to do since clearly both cases may happen. Should they both be supported or should Tomcat be able to analyze the values and accept both? I don't know if Tomcat has some policy about being able to accept "bogus" input

BR

Carlos Quiroz

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Re: Digest Authentication

Posted by Remy Maucherat <re...@apache.org>.
carlos.quiroz-castro@nokia.com wrote:
> Hi all
> 
> I've been trying unsuccessfully to use the Digest authentication in Tomcat with my webapp. I need it because Basic authentication is too weak and I cannot use SSL on the client side.
> 
> I noticed that the implementation in Tomcat has some problems that I describe below:
> 
> 1. In org.apache.catalina.realm.RealmBase it is said that it implements RFC 2069 but IMHO it actually implements partially RFC 2617 since it uses the qop option to calculate the digests, which first appeared in RFC 2617
> 
> 2. RFC 2617 clearly says that if qop is not present the request-digest should be calculated as in RFC 2069. However in the current implementation it is always calculated as RFC 2617, i.e.
> 
> String serverDigestValue = md5a1 + ":" + nOnce + ":" + nc + ":"
> 						+ cnonce + ":" + qop + ":" + md5a2;
> 
> This excludes the possibility of qop being null in which case the serverDigestValue should be
> 
> String serverDigestValue = md5a1 + ":" + nOnce + ":" + md5a2;
> 
> Also the case of qop being auth-int is not taken into account at all
> 
> 3. Finally, there is a problem when obtaining the values qop and nc. Some browsers send qop with quotes, for instance IE, but Mozilla sends them without quotes. Same with nc. 
> 
> What happens is that in org.apache.catalina.authenticator.DigestAuthenticator the qop is calculated always removing the quotes. That makes that in a mozilla's request qop=auth becomes qop=ut and the Digest calculation is different. I'm not sure what should be the right thing to do since clearly both cases may happen. Should they both be supported or should Tomcat be able to analyze the values and accept both? I don't know if Tomcat has some policy about being able to accept "bogus" input

I recommend you prepare a patch for this. I'm pretty sure you know about 
that already, but DIGEST will not work with most Tomcat realms (a 
refactoring is needed, and will hopefully occur in Tomcat 5).

Remy


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org