Subject: Re[2]: And the definition of non-repudiation is....?

From: "Zmudzinski, Tom" <[email-masked]>
Date: Tue, 17 Aug 1999 14:08:31 -0400

>>> truncated message with additional comments <<<
> From:	tog <[email-masked]> on 08/16/99 10:46 PM
> To:	Alfred Arsenault <[email-masked]>, [email-masked], [email-masked]
> Subject:	Re: And the definition of non-repudiation is....?
>
> Comments Inline below
> 
> Todd
> ----- Original Message -----
> From: Alfred Arsenault <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Sent: Monday, August 16, 1999 6:41 PM
> Subject: And the definition of non-repudiation is....?
> 
>> Ed,
>>
>> Since you so outspokenly oppose the definition of "non-repudiation"
>> from ISO 7498-2 which (most of) the group has been working under for
>> these last few years, perhaps you'd like to enlighten us as to the one
>> true, correct definition of non-repudiation?
>
> Actually, I will...
>
> Non-repudiation is a process that puts in place a trust model such that
any
> event that is "deemed nonrepudiable" is beyond question. It's about the
> totality of the trust model that surrounds the envelope of the transaction
> and the facilities for evaluating it. Such events are deemed
non-repudiated.

Now can we try it without the tautology?  The Defense Message System
defines non-repudiation as a security service that "protects against the 
denial by one of the entities involved in a message exchange of having 
participated in all or part of the exchange.  It supports the
proof-of-origin 
and the proof-of-receipt services that provide proof of message origin to 
the recipient and proof of message receipt to the sender.  Non-repudiation 
combines the use of modification detection with digital signatures.  These 
security services are vital in a military message system to verify that the 
proper authority issued an order and that the correct recipient received 
the order." -- DMS System Security Authorization Agreement Version 2.1

In the early days of DMS, we used to say simply [sorry about the message-
centric verbiage] that non-repudiation was that property which would 
demonstrate to an impartial third party that a given message had been 
sent by a specific individual or received by a specific individual.

v/r
Thomas E. Zmudzinski, CISSP                            [email-masked]
IPMO matrixed support for DMS PMO               703.681.9089 [DSN 761.9089]

---

From: Ed Gerck <[email-masked]>
Date: Tue, 17 Aug 1999 12:27:10 -0700

"Zmudzinski, Tom" wrote:

> ...The Defense Message System defines non-repudiation as a security
> service that "protects against the denial by one of the entities involved
> in a message exchange of having participated in all or part of the
> exchange.  It supports the proof-of-origin  and the proof-of-receipt
> services that provide proof of  message origin to the recipient and proof
> of message receipt to the sender. Non-repudiation combines the use of
> modification detection with digital signatures.  These security services
> are vital in a military message system to verify that the proper authority
> issued an order and that the correct recipient received the order." --
> DMS System Security Authorization  Agreement Version 2.1
>

This is not what non-repudiation is in business -- what DMS-NR describes is
simply the assertion of a truth, which is authentication.  BTW, the sure sign
that the DMS-NR definition does not define a non-repudiation process is
the fact  that the signer can NOT deny providing DMS-NR.

To a bank or in business [cf. Nicholas Bohm, CC'd] , non-repudiation
means that I can be held liable for a signature I did not make if the
recipient could not distinguish it from a signature I did make. The
recipient's trust in what was apparently (but not in fact) my signature
is therefore held by law to be well-founded.  My trust in the reliability
of the systems concerned (i.e. my trust that only a signature made or
authorised by me will be treated as binding on me) is held by law
to be ill-founded.

In fact, non-repudiation occurs and is logically granted even if, indeed,
the signer *proves* (legal, technical, etc.) beyond doubt that it did
NOT make the signature -- the basic tenet here is that the
relying-party had (past) to make a decision to accept the signature
and based (past) such decision on its means to deny signature
repudiation, which power was granted by the signer.  That is
why *absence* of the signer's expression of power to grant
non-repudiation to the relying-party is a sure sign that
non-repudiation does not exist (since the signer cannot be coerced
into granting a liability).

I take that non-repudiation in this sense is a desirable feature:  I should
not be free to deny that I signed what in fact I did sign.  But we need
to be aware of the other use of this expression (or misuse of it) in
the sense that a truthful denial is thwarted by a legal affirmation.

The NR "definition" presented by Todd captured IMO the fine points
of this business scenario and that is why I believe Todd's definition is
closer to non-repudiation as used in business than the one adopted
by DMS -- which is simply proof of authentication.

Cheers,

Ed Gerck

---

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Aug 1999 16:11:23 -0400

Ed,

>simply the assertion of a truth, which is authentication.

We again seem to have a terminology problem.  Authentication, in our
technical context, is either entity (e.g., user) authehntication or data
authentication (e.g., data origin authentication).  There is a very
significant difference between the sort of user or data origin
authentication, and the mechanisms that we often employ to implement these
services, and the NR technology we are discussing.  Specifically,
authentication mechanaims usually do not provide a good technical basis for
NR, since either party to the authentication process could, in most cases,
generate the same sets of bits that are the product of the auth process.

[snip]

Steve

---

From: "tog" <[email-masked]>
Date: Tue, 17 Aug 1999 14:55:13 -0700

Stephen, Ed
the simple issue is that we are talking about NR as a number of different
things... At different altitudes so to speak. In the context of these
discussions, no real resolution will be possible until the specific use and
constraint of the NR concept is hammered down.

Is this like David K says, a bit to inform the process of the Keying
Information used, or is it something more that says something to the using
applications?

Once this is answered formally and finally, these conversations will likely
turn to whether the answer we come to is enough to support the anticipated
use models or needs to be augmented.

Either way, lets get on with it.

Oh, and Bob, congrats on the book!.

Todd