On 09/01/2015 13:36, Kehlenbach, Andreas wrote: > Hello, > > With debugging I finally found out why Jersey and Tomcat doesn't play > well with digest authentication. > > If a nonce got stale and tomcat issues a new authentication request. > Jersey answers this request and responds with a valid header in terms > of the HTTP digest specification. The nonce-count field isn’t set to > 1 by Jersey in this case. Instead the old value is increased.
In which case Jersey is not responding with a valid header in terms of the HTTP Digest specification. The requirements of RFC-2617, section 3.2.2, "nonce-count" are: <quote> The nc-value is the hexadecimal count of the number of requests (including the current request) that the client has sent with the nonce value in this request. For example, in the first request sent in response to a given nonce value, the client sends "nc=00000001". </quote> > This > new value isn't accepted by tomcat (DigestInfo class, > isNonceCountValid()). Tomcat forces this value to be 0 on new > authentication. As required by the specification. > As the HTTP Digest authentication isn't clean at this point I > strongly recommend to change tomcat sources and allow nonces with a > random value on authentication. This could be achieved if the > nonce-count is read from the client request on authentication. This proposal makes no sense. Nonces are random but they are server generated. The client must return the nonce that it was sent. The nonce-count is already read from the client and then validated against what the server expects to see to prevent replay attacks. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
