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

From: "Bob Blakley" <[email-masked]>
Date: Tue, 17 Aug 1999 10:22:50 -0500

All

>I very much liked Todd Glassey's operational definition of NR sent today to
this
>list: 'Non-repudiation is a process that puts in place a trust model such
that any
>event that is "deemed nonrepudiable" is beyond question.'

I hate this definition.  In a book on the CORBAsecurity service (to appear
this fall), which
includes a non-repudiation function, I used the following *informal*
definition, which is very
different from the one above.

"Non-repudiation services work by generating evidence of subjects' actions.
When a
dispute arises, non-repudiation evidence can be used to help settle the
issue."

The point I'm trying to make here is that the only service we can really
provide is
generation of evidence.  We can use various mechanisms to make the evidence
plausible or compelling - including using strong cryptography, good trust
models,
good physical security, etc.....  But NONE of this puts an event "beyond
question",
because in the contexts in which protection against repudiation (=
non-repudiation
protection) is an issue, disputes always arise (hence there is by definition a
question),
and they are always settled according to procedures which include rules of
evidence
etc....

Ed's larger point, that the only context in which NR makes sense is the legal
context, is exactly right.  But so is Steve's - all we can do is to provide
technical
mechanisms of evidence generation which have well-understood properties,
and work with the lawyers to make sure that we've chosen the right properties
and are able to explain them to lawyers, judges, and juries so that they
understand the evidence they're evaluating.

--bob

Bob Blakley ([email-masked])
Chief Scientist, Dascom

---

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

>Ed Gerck wrote:
>> this list: 'Non-repudiation is a process that puts in place a trust model such
>> that any event that is "deemed nonrepudiable" is beyond question.'

Bob Blakley wrote:
>this fall), which includes a non-repudiation function, I used the following
>*informal* definition, which is very different from the one above.
>
>When a dispute arises, non-repudiation evidence can be used to help settle the
>issue."

Bob:

Maybe there is time to edit the galley proofs ;-)

I note that the "informal" definition of NR that you present is nothing
more than the definition of authentication.  Indeed, authentication works
by generating evidences of subject's actions (eg, a password being entered,
a certificate being verified, etc.).  When a dispute arises, such authentication
evidence can be recalled and used to help settle the issue.  In all this, note further
that the signer had *no* participation -- i.e., the signer could NOT deny to
provide what you call "NR".  Which is a sure sign that this is not NR.

> context, is exactly right.

I am afraid I must then be exactly wrong ;-)  because this is the opposite of
what I said.  Yes, I did say that the legal context cannot be ignored in business,
but I have also said a couple of times that NR can be based on a legal test, a
technical test, a policy test, etc.  Since I have received some pvt emails
asking for the NR model that I presented here in summary form
before (and which I cited yesterday but is IMO too complex for PKIX
usage but may be useful for CPS usage), I copy it below -- defining any
number of contexts in which NR makes sense, of which the legal context is
but one example.

--------------------copy/begin-----------------------------------------
{Fri, 23 Jul 1999 20:36:23 -0700}

 In order to preclude further interpretation problems, let me present a
NR model that classifies what I consider to be the major aspects that
any system wishing to provide non-repudiation at any given level should
include, also naming each of a series of levels and providing for a division
between Variables (which I can't control) and Modifiers (which I can
control to some extent):

A. Variables -- involves only "you", where "you" is the one that authenticates

A1. syntatic form (Is the authentication yours?),

A2. semantic form (Did you understand what you were authenticating?),

A3. trust form (Did you yourself willfully authenticate it?),

A4. identification form (Are you the authenticator you claim to be?),

A5. temporal form (When did you authenticate it?),

A6. local form (Where did you authenticate it?),

A7. etc.

B. Modifiers -- involves also "me" (ie, "I", the verifier)

B1. legal form (Can I legally prove it?)

B2. liability form (Can you back and idemnify it to me?)

B3. extent form (What is the temporal and legal extent of the authentication, for you
                         towards me and me towards you?

B4. policy form (Is that allowed by the applicable policies, for you towards me
                         and me towards you?)

B5. etc.

Where I prefer to divide the issues of non-repudiation according to a
state-space where one has a FIRST set of clear variables which I do not
control, but measure:

 Variables: syntatic, semantic, trust, identification, temporal, local, etc.

and a SECOND set of clear modifiers which I can control at least to
some extent:

 Modifiers:  legal, liability, extent, policy, etc.

As needed, one combines the components for a specific
"law/policy non-repudiation system" as a logical function that uses
A1, A2,... and B1, B2, ...  above as functional inputs, but in
each respective classification.

So,  weak authentication (as provided by passwords) fails to
provide values for *ALL* variables when viewed under B.1
since any such value could be replayed at will by the verifier
(for example, or by an attacker) and there is nothing that the
password holder could do to avoid it. Thus, as a legal principle
valid in law theory in general (between power and liability),  since
the password holder has no power to deny weak authentication it
also has no derived liability from it, including non-repudiation.

However, it is possible that some A variables could provide
non-repudiation for passwords when viewed under the B4 modifier,
for example --  such as when an ISP uses A.1 and B.4 in order to
put an user's account on hold when two succesfull logins occur at a
given time (indicating either two persons using the same account or
a password compromise).  But, this is not legal NR -- which is what
we are focusing here.

So, to avoid further confusions whenever I mention NR, I mean legal
NR unless otherwise noted.
---------------------------------------copy/end------------------------

Cheers,

Ed Gerck

---

From: "Bob Blakley" <[email-masked]>
Date: Tue, 17 Aug 1999 14:38:45 -0500

All

>>> 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?

Not even a tautology, but an absurdity, unless it's intended to describe a set
(of events) with no members.  The whole point here is that if an event is
beyond question, there's no need for non-repudiation protection.  If there is
a need to protect against repudiation, then by definition a question might
arise.

>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.

I like this definition, except for the word "proof", which of course isn't
defined
here.  What's actually provided in DMS implementations is evidence, which
may be judged sufficient in some cases, depending upon who is eventually
called on to arbitrate disputes.  It seems clear that the JCS is more likely
to think that DMS NR evidence is "proof" than, say, the Supreme Court.

>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.

I like this verbiage too!

--bob

---

From: "Bob Blakley" <[email-masked]>
Date: Tue, 17 Aug 1999 15:32:11 -0500

--bob

>more than the definition of authentication.

Sorry, but this is obviously, absolutely wrong.  Authentication clearly does
NOT provide
evidence of a subject's actions.  In fact you explain this yourself below, in
your discussion
of weak authentication.  Authentication asserts the identity of one party to
another party
in an individual transaction, but NOT to third parties, and NOT outside the
scope (temporal
or spatial) of the transaction.  This is one of the reasons people want to
separate authentication
keys from NR keys -- because you're under a legal obligation, at the risk of
liability, for
*evidence* generated by executing a signature using a NR key, but you are NOT
at this
risk by virtue of executing a signature using an authentication key.

The whole notion of non-repudiation was invented because it was observed that
in
secret-key systems, and in poorly administered public-key systems,
authentication keys
could be stolen or maliciously disclosed in ways that created doubt about
whether the
subject using the key was the one whom it ostensibly authenticated.

>Indeed, authentication works
>evidence can be recalled and used to help settle the issue.

Absolutely not.

>In all this, note further

I think what you mean here is "refuse", not "deny".  Subjects can ALWAYS deny
that evidence is genuine, germane, accurate, etc....

However I don't understand what you're getting at here; the subject certainly
enters
the password, and hence does participate in authentication.  He doesn't
participate
in the later recovery of the evidence, but this is the case in most NR
scenarios too.

>technical test, a policy test, etc.

NR could be based on a technical test, if one expected that the evidence would
never be challenged before an impartial third party.  However this isn't an NR
case - it's an authoritarian regime.  In such a regime, a simple audit log
will
serve to convict both the innocent and the guilty of their real or imagined
offenses, and we need not resort to difficult technologies like digital
signature.
In regimes in which the arbitrator is to some degree impartial, NR will be
based
on rules of evidence and rules of procedure adhered to by the arbitrator.
In this case the test will always be in some sense "legal", in the context of
policy
and procedure.

>Since I have received some pvt emails

In principle not determinate

>A3. trust form (Did you yourself willfully authenticate it?),

In principle cannot be captured in evidence

>A4. identification form (Are you the authenticator you claim to be?),

About 2000 years of philosophy have not yet converged on a view of what this
means

>B1. legal form (Can I legally prove it?)

In most systems this can only be known after the fact (i.e. after the judge or
jury
renders a decision)

>B2. liability form (Can you back and idemnify it to me?)

Relevant, but more interesting if "can and will"

>                         towards me and me towards you?

I know something about how to define temporal extents - legal extents are very
tricky
and the syntax is going to be a bitch -- even in ASN.1 :-)

>also has no derived liability from it, including non-repudiation.

I certainly agree that "weak authentication" does not create a presumption
of intent or contract.

---

From: "Bob Blakley" <[email-masked]>
Date: Tue, 17 Aug 1999 16:33:16 -0500

All

>I see that non-repudiation is being mistaken for proof of authentication --
>so that there is  a paradigm shift involved here.  The ISO definitions and
>also at least two definitions of non-repudiation presented today are IMO
>not non-repudiation at  all; they just deal with proof of authentication.

I disagree; ISO definitions have explicitly to do with proof of action, but
that
action need not be authentication.

>It will take time for us all to sort the different nuances and the
discussions
>can be very helpful  to bring out the differences between authentication,
>proof of authentication and non-repudiation.
>
>But, non-repudiation is that which allows a truthful denial to be thwarted
>by a legal affirmation.

Another definition I don't agree with.  I think NR is *most effective* if
transactions
which use it are defined to have the following properties:

* Each party has evidence to cast doubt on all false accusations which
    might be made against it
* Each party has evidence to support all true accusations it might want to
make
* No party has evidence to support any false accusation it might want to make

It certainly isn't a desirable property to thwart truthful denials, any more
than it
is a desirable property to support false accusations.

Nevertheless, none of these things has fundamentally to do with the technical
aspects of a non-repudation service.  Such a service ought simply to produce
evidence of a transaction, and ought to have the property that it's easy to
explain to an adjudicator what must be done in order to successfully forge
such
evidence.  The adjudicator can then decide for himself the probative value
of the evidence, and whether it's germane to the accusations being made.

>This will however just punish the cert user, not the
>miscreant -- so that the NR "death penalty effect" will be not be a deterrent
>to crime in this case, even for those that believe in the effect.   IMO,
using
>non-repudiation certificates can actually decrease the security level of a
>system -- and I hope to make this point technically clear in a next text.

I'm fully prepared to believe this!

>So, using non-repudiation in a PKIX-QC implementation may not
>necessarily mean that a better assurance level will be reached in
>business transactions.

Using NR does not inherently have anything whatsoever to do with
the assurance level in business transactions.  It's possible to use NR to
increase the risk of engaging in fraudulent transactions, which may lower
the incidence of fraud and provide lower risk for the transactors.
But it's possible to use NR in lots of situations where it doesn't accomplish
this
goal.

--bob

---

From: "Bob Blakley" <[email-masked]>
Date: Tue, 17 Aug 1999 17:25:12 -0500

Ed,

>> >This is not what non-repudiation is in business -- what DMS-NR describes
is
>> >simply the assertion of a truth, which is authentication.
>>
>> Sorry, but your definitions are all non-standard from the security
viewpoint,
>> Ed.
>
>I disagree.  See, for example, Menezes et. al., "Handbook of Cryptography",
>page 3:
>
>- entity authentication: *corroboration* of the identity of an entity
>- message authentication: *corroborating* the source of information
>
>Now, see Webster:
>
>- corroboration: to support with evidence or authority, to make more certain

When confronted by multiple layers of definition, I usually try substitution.
Here goes:

    entity authentication: to support the identity of an entity with evidence
or authority

(according to your citations).

I have failed to find substitutions which make this equivalent to

    the assertion of a truth [about an entity?]

Identity is not truth, nor vice versa -- not even to a logician!

>Thus, authentication involves two steps:
>
>(i) cognition, in which a trusted value X is acquired (e.g., the identity,
>the public-key, etc.) -- cognition defines a "fact", X;

Cognition does not define a fact!! "Cogito ergo sum" -- not "Cogito ergo est"!

>(ii) recognition, in which that trusted value X is used to support with its
>evidenciary or authoritative value whether a variable x presented for
>recognition is accepted or rejected -- recognition defines whether x
>is in accord with fact X.

??!!

This doesn't appear even well-formed.  Variables aren't "accepted or
rejected";
predicates or propositions involving variables are either true or false in a
model,
or, more generally, valid or invalid, based on the *values* of the variables
(or their
range of admissible values).  Are you simply defining recognition as truth in
a model?
In other words

REC = f(x) with X substituted for x?
or are you defining a function REC (X, x)?  If so, what's the function?  (I
think this
is the point....)

In a real example, I might imagine an authentication procedure which takes as
inputs a claimed "identity" (say "bob"), a password (say "friend") and then
runs a procedure which uses a table lookup to see if the password is the one
which the verifier associates with the identity, i.e.

        REC = (pw("bob") = "friend")

Is this what's intended?

But in this case, neither "bob" nor "friend" is in any sense "trusted".... or
even "a fact".
They're just data coming in on some channel.

>Thus, authentication asserts a truth -- Webster:

I think you left a few steps out, at least from the viewpoint of the slower
among us,
myself included in this group.

>truth: the property (as of a statement) of being in accord with fact or
reality.

We're fixin' to get into deep water here.  Steve will have tender parts of my
anatomy in a vise
if I follow you down this path....

Suffice it to say that you've not explicitly given either the fact or the
statement
which would support the argument here.

>So, in terms of logic, to authenticate x is to assert the truth of x in the
system of
>X.

Now you've got things hopelessly confused; you've earlier defined x to be a
variable,
but now you seem to be using it to denote an expression which has a truth
value.
If you're going to use logic as the basis of your argument here, I'm going to
insist
on at least well-formed formulae!

But on the point, this isn't how the security community has defined *either*
entity
authentication or origin authentication.  Again I'll refer you to the paper I
cited earlier,
and to others in the related literature,
none of which agree.

>I know that it may sound confusing to say that a "truth" is not an absolute
truism
>but such is the world of mathematics -- truths can be denied, even if I
affirm
>them ;-)

I think much of this audience is perfectly familiar with formal logic, but
this line
of argument doesn't use it properly and doesn't in any event address the issue
of departures from the security community's established definitions.

>So, there is no tautology.  Just a little "getting used to" -- but in math,
not in
>security definitions.
>
>I suggest you re-read my msg with this explanation in mind.

--bob