Subject: Re: To Be, or NR To Be ...

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

>Tony,
>
>>>>If I employed a PK solution to authenticate "remote logins",
>>>>why should I settle for a mere "repudiable" login?

Why would you want "nonrepudiable login"?  Normally no liability is associated
with logging in -- it's what you do afterward that creates the liability.  The
system
owner has no interest in holding you accountable for logging  in, and is
unlikely
to be able to prove to a judge that you didn't walk away in the middle of a
session.
Hence it's much more interesting to have evidence of your having originated
requests for specific transactions, than to have evidence of your having
initiated
the session within which those transactions were originated.

>>>You mioght have to settle for a repudiable login to the extent that none of
>>>the current schemes for protected sessions (e.g., IPsec, SSL, Telnet
>>>authentication, ...) provide NR for the session.  Yes, one could engineer
>>>and exchange that provided evidence that a user logged in, but current
>>>protocols do not provide good technical evidence of what the user did after
>>>login.
>>
>>Should it not be up to the relying party to consider whether their system
>>can maintain the NR-trail for actions that occur during after login?

In some sense it's up to the arbitrator; he's the one who evaluates the
evidence.
He's only going to care about evidence of login if the evidence of the
transaction
about which a dispute has arisen, depends on evidence of the login.  (This is
similar to legal arguments about "chain of custody" of evidence, but not
identical).
But given that making this kind of argument is going to be harder than making
an argument without this kind of dependency built in, I don't see why you'd go
to
the trouble of generating evidence of logins.

>Now you are moving into an area where we no longer have crypto support for
>NR.  The protocols I cited permit either end to generate an audit trail for
>data that was not sent by the other party, and thus they do not provide a
>strong basis for NR (using "strong" in the technical sense, e.g., "strong
>authentication.")

There's also a problem of presumption here.  In a model in which login is
subject to NR evidence generation, and evidence of other transactions is
contingent upon login evidence, you could get into lots of situations in which
the user's login implies consent or assumes liability.  There's lots of
consumer
law limiting the counterparty's ability to impose implied consent or liability
on the user, so there might be lots of applications which could not legally
be deployed on such a system.

--bob

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

---

From: Tony Bartoletti <[email-masked]>
Date: Tue, 17 Aug 1999 17:17:27 -0700

At 05:51 PM 8/17/99 -0500, Bob Blakley wrote:
>system owner has no interest in holding you accountable for logging  in, and is
>unlikely to be able to prove to a judge that you didn't walk away in the middle
>of a session.
>initiated the session within which those transactions were originated.

I simply consider a login to be one particular transaction.  Why assume
that no system owner would want to hold me accountable thereby?  Seems just
a bit like saying that banks don't care if I can sneak into their vaults
undetected/unidentified, just so long as I don't take any money.

With regard to "walking away in the middle of a session", suppose I enter
a transaction where I am presented with an electronic contract, and after
I unlock my NR-key (but before following through with signature) I were to
be suddenly called away, and a co-worker enters my office and completes the
operation in my absence.

Convincing a judge that you did/didn't walk away seems comparably problematic
in both the login and digsig cases. 

I see only shades-of-gray here, as much as we want to see black and white.
And shades-of-gray are the domain of policies and lawyers, not protocols.

Really, I agree with the goals, I just don't have alot of faith in the
given mechanism not providing a certain false-sense of something that's
really not there.

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

---

From: Ed Gerck <[email-masked]>
Date: Tue, 17 Aug 1999 21:05:01 -0700

Bob Blakley wrote:

> unlikely to be able to prove to a judge that you didn't walk away in the middle of a
> session.

Bob and all:

Sorry to pick your text as an example for what non-repudiation is not, but
it exemplifies the paradigm shift, change of heart or whatever other metaphor
I can use to denote that need to stop, ponder and change.   To make this
posting clearer I will use "non-repudiation"  to denote what I call
non-repudiation and NR to denote what you mean by non-repudiation.

Reading your paragraph above -- when you talk about NR -- it is clear that
you think:

1. Only the use of NR will allow you to prove something to a judge

2.  Only the use of NR will be able to make the user accountable

3. Only the use of NR will provide legal evidence of user actions

So, these topics can be seen as "definition" of NR -- and you are not alone
because this is essentially what the DMS and ISO concepts of NR are all
about.  Well, these topics are all false in regard to non-repudiation, so that
NR <> non-repudiation.

But, this is not the main problem. The main problem is that you did not even
talk about non-repudiation!  In your entire text, the notion of non-repudiation
did not appear even once.

Contrary to what Steve Kent believes, there is a very clear idea in business
and banking about what non-repudiation is.  What those sectors do not know
is how to represent that in a reasonable fashion in security protocols -- and,
thank God they don't ;-)  So, how about we trying to find out how to do it
before they do it?

Oftentimes, a word is used just to satisfy a market need -- and, surely, we can
read press-releases of security companies that currently deliver products with
"non-repudiation" and at least one company even went as far as declaring that
it delivered products that offered "true non-repudiation".  Isn't this the same as
those "FREE" offers we read all the time? We all know it ain't FREE, so it
simply does not work after a while.  But, is this what we want?

To be fair, the motivation for the NR definition is a laudable one (contrary
to many of those FREE offers).  Indeed, this definition of NR reflects a concern
to improve security and it also recognizes that an element of proof is needed .

Where it fails is that it follows a common non-lawyer approach to solve a
legal issue -- non-lawyers believe that if they explain something "really well"
and provide "strong proof" then they will have a fat chance to win in court.
It is all a drive forward, a positive assertion -- more files, more logs, more
crypto keys, more digital signatures.  So, NR as you use it (and you are not
alone) is simply proof of authentication.  But, never non-repudiation.

Why? Because non-repudiation needs to be deniable a priori in order to be
legally valid -- yes, and please do not change my word "deny" to "refuse" ;-)
Because non-repudiation is a "two-prong test" [*] that allows a relying-party to
thwart a truthful denial (made a posteriori) with a legal affirmation (made a
priori).  Because if it does not allow all this, then it is not non-repudiation.

And please note what I say above. That even the strongest of proofs
(more files, more logs, more keys, more signatures, better timestamps,
better whatever you want) made afterwards to a judge is powerless
against a legal affirmation made a priori -- when non-repudiation is
either correctly applied or denied.   Thus, the non-lawyer approach
must fail in either case.

That is why a change of heart is needed.  What DMC, PKIX and ISO
have been calling "non-repudiation" simply is not non-repudiation -- is
proof of authentication.

And, maybe this is one way out of this corner were are all painted in.   We
may change the current NR bit name to "PA bit" -- proofOfAuthentication
bit. In a rather humorous rendering:

- We hereby declare that when the proofOfAuthentication bit is asserted in a
  certificate, any  message signed with the certificate can be used as legal
  proof against us, but not otherwise.

But, I suggest to indeed add a non-repudiation bit -- exactly because
non-repudiation is NOT the same as authentication, or strong authentication,
or proof of authentication.  Non-repudiation and authentication are
complement operations (technically speaking, reference upon request). As
I wrote earlier, my suggestion to define non-repudiation in PKIX is that
the text would negate any semantics to the non-repudiation bit beyond its own
syntactic expression as a boolean bit, while defining non-repudiation as
a qualified pointer (i.e., avoiding the dangling clause problem):

1'. Non-repudiation is defined in the CPS and its usage is asserted by setting the
nonRepudiation bit.

I also suggest to follow Tony's comment and define all other usage bits that are
not taken, calling them by generic names (say, in a humorous tone, Green, Red,
Blue):

- The Green service is defined in the CPS and its usage is asserted by setting the
  green bit.

etc.

Thus, what some sectors of the security community have felt a need to express
(and, with which need I agree), will be well represented by the PA bit. This
includes some needs previously expressed by Dave Kemp as the "XYZ" bit.
Thus,  marketing materials can say that a product offers "true proof of
authentication" without a  second thought (if, indeed, it does, of course).

Likewise, what some sectors of the business community have felt a need to use
and apply as non-repudiation will be well represented by the non-repudiation bit
in support of such (future?) uses.

And, other special services will be available as flagged by the R,G,B bits.

Comments?

Cheers,

Ed Gerck

[*] defined here in some of my messages.