zurko@osf.org (Mary Ellen Zurko) writes:
> It seems that from the start of WWW security, the terms authentication
> and authorization have been used in ways that obfuscate the difference
> between them.
[etc]
I have just read through both section 10 of draft-ietf-http-v10-spec-00 and
draft-ietf-http-digest-aa-00 and have found only one place where I think that
either term is used incorrectly. This is under <domain> in 2.1 of digest-aa,
where I think "authorization" should replace "authentication.
The credentials are authorization information; "This request is from <username>
who claims the right to access <requested-uri> in <realm>" the digest is the
authentication information for the claim "Only <username> could and would have
created this <digest> of that claim and the secret we share". The server could
have constructed the credentials, but this scheme is not trying to address the
non-repudiation problem.
Reading through digest-aa-00 again has revealed two other problems:
1) <digest> and <message-digest> have only the nonce to link them in a
request. Specifically, if the server re-uses nonces, the client cannot ensure
that the message body matches the requested uri - this could be a problem
POSTing.
2) There is nothing except the nonce to link the response to the request. If
the nonce is re-used, an intruder could substitute an old response.
If there is any possibility that the client has used the same method:URI pair
before, the only way to ensure that the entities in request and response
messages are current is for the client to create a nonce of its own. This has
to be added to both <digest> amd <message-digest> (both ways) and therefore be
another parameter to the Authorization header so that the server can create
the <message-digest> for the response. Guaranteeing a current response from
the server only matters if the resource could change. If the client is happy
with a cached version, then it could use method:URI in place of the nonce to
ensure that the reply is to some version of this question.
Regards,
Owen Rees <rtor@ansa.co.uk>
Information about ANSA is at <URL:http://www.ansa.co.uk/>.