Re: Authentication, security requirements

Along with authentication, authorization and privacy, one might want to
include non-repudiation as a requirement for authoring.

Non-repudiation would be a handy capability for any type of collabortive
efforts or submission/modification of sensitive data. It needs to be
tied closely with strong authentication.

To the best of my knowledge (which is always suspect) there is no one
dealing with this issue in a commercial product today. If there is some
work going on out there, perhaps we could look at it for input.

And then ....

On the subject of idempotency.

I'm concerned that people are compromising the definition of idempotency
to fit what they think can be easily implemented. My understanding of
the term is that an idempotent operation can be repeated any number of
times and the result is the same.

A common example of an idempotent operation is a directory lookup. Even
with this apparently safe example, it's clear that the operation is not
idempotent over all space and TIME. However, the example is normally
accepted.

Another example of an idempotent operation is a file (or object or
container or whatever) DELETE. This example gives me some concern. It
seems as though the proof of idemptency is based on the following
scenerio:

	handle = Enumerate(object);
	(void)Delete(handle);
	handle = Enumerate(object);

If the final assigned value of 'handle' is null (implying no such
object). This is the desired state after a 'delete' operation, so all is
well.

Observation would also note that the final value of 'handle' in the
following sequence is also null. Some would argue that this proves the
'delete' operation is therefore idempotent.

	handle = Enumerate(object);
	(void)Delete(handle);
	(void)Delete(handle);
	(void)Delete(handle);
	(void)Delete(handle);
	handle = Enumerate(object);

This is observing the result, but ignoring the cause. What's missing is
the status of completion of the 'delete' operation.

There is and should be an important distinction between a delete that
completes with 'success' verses a delete the completes with a status of
'invalid handle'.

There are two possible reasons for the latter case:

	Another process deleted the object after the 'Enumerate'
	was called. This could be a access violation, and non-
	repudiation (should it be enabled for deletes) would provide
	information regarding who actually deleted the object.

Or

	The protocol does not have "at most once exection" semantics.
	Without such sematics, one will have great difficulty creating
	anything but idempotent protocols. Of course, that's how the
	definition of idempotent got compromised in the first place,
	isn't it?

I believe useful idempotent networking protocols do not exist.
Continuing to believe they do and trying to design processes to take
advantage of idempotency is fruitless. The real goal is to control cache
coherency; can the sending of the object across the network be
suppressed and a more local copy offered instead.

AO
-- 
Alan O. Freier		Corporate Cynic
<freier@netscape.com>	(415) 937-3638 (work)

Received on Thursday, 26 September 1996 13:14:57 UTC