[9781] in cryptography@c2.net mail archive
Re: when a fraud is a sale, Re: Rubber hose attack
daemon@ATHENA.MIT.EDU (Rick Smith at Secure Computing)
Mon Nov 5 15:42:55 2001
Message-Id: <5.1.0.14.0.20011105111309.02cc2e18@STPNTMX03.sctc.com>
Date: Mon, 05 Nov 2001 11:24:06 -0600
To: JohnE37179@aol.com, egerck@nma.com
From: Rick Smith at Secure Computing <rick_smith@securecomputing.com>
Cc: lynn.wheeler@firstdata.com, cryptography@wasabisystems.com,
Jason.Gruber@btinternet.com, vertigo@panix.com
In-Reply-To: <2d.138c757d.29180f00@aol.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
At 09:49 AM 11/5/2001, JohnE37179@aol.com wrote:
>I tend to agree with you that we should extend the meaning
>of end-to-end to mean user-to-user, instead of device or
>token-to-token.
I'm not sure what this means.
If we get really specific, then a transaction between me and
a small used-book seller consists of a transaction between
individual humans, but my transactions with Amazon involve
an abstract entity represented by teams of humans. Presumably
my latest transaction still proceeds even if the first person
to process it at Amazon quits before the package is shipped.
That's not so clear if the bookseller drops dead.
If we look at authentication as an engineering problem, then
you can only 'authenticate' between entities that share some
fairly complex secret information. Anything else can be spoofed
pretty easily. I don't think it's practical to speak of strong,
network based authentication between 'users' unless we tie them
to physical devices that store those secrets (private keys, etc.).
Of course, this distinction simply illustrates the gap between
our policy objectives (authenticate particular roles and/or
entities) versus the available tools (verify ownership of hard
to forge credentials).
Rick.
smith@securecomputing.com roseville, minnesota
"Authentication" in bookstores http://www.visi.com/crypto/
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
