[15175] in cryptography@c2.net mail archive
Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
daemon@ATHENA.MIT.EDU (Anne & Lynn Wheeler)
Fri Jan 9 10:22:50 2004
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Wed, 07 Jan 2004 10:28:34 -0700
To: Jerrold Leichter <jerrold.leichter@smarts.com>
From: Anne & Lynn Wheeler <lynn@garlic.com>
Cc: Cryptography <cryptography@metzdowd.com>
In-Reply-To: <Pine.GSO.4.58.0401070950320.16018@frame>
At 10:14 AM 1/7/2004 -0500, Jerrold Leichter wrote:
>Now that we've trashed non-repudiation ... just how is it different from
>authentication? In both cases, there is a clear technical meaning (though as
>with anything in mathematics, when you get right down to it, the details are
>complex and may be important): To produce an authenticator/non-repudiable
>signature, you must have access to the secret. There isn't, at this level,
>even any difference between the requirements for the two. Where we get into
>trouble is in attempting to bind the real world to the mathematics. In each
>case, the receiver wants to be able to say:
lets say they are somewhat different threat models (but may have some
partial overlap).
it would be possible to give a dozen people the same passprhase and have
some degree of confidence that only the permitted entities entitled to do
something were authenticated. however, if one of them claimed that they
didn't do some specific thing ... there would be difficult to differentiate
between the different entities as to which entity had been authenticated at
any specific time. some of the best practices security guidelines for
authentication (like not sharing passwords) have more to do with
non-repudiation ... than straight authentication.
key-escrow can be considered mandatory for encryption keys under the
non-single-point-of-failure and availability best practices. At the same
time there may be mandatory requirements for NOT having key-escrow for
authentication keys under non-repudiation best practices (even when the
cryptographic technology is identical ... the issue of key-escrow policy is
exactly opposite depending on whether the business use is encryption of
authentication).
a straight-forward authentication issue might be whether a particular
message originated from a specific entity. That would not necessarily
include the sense that the entity agreed with the terms and conditions
described in the body of the message (say a financial transaction). This is
somewhat akin to various EULA agreements that have people clicking on
various buttons .... which is not an issue of authentication but of
agreement; aka *repudiation* can include things that are outside the scope
of authentication (not whether the message originated from me ... but do i
fully agree with what is included in the body of the message). neither
identification nor authentication by itself can necessarily include the
concept of agreement. repudiation can include a number of items outside the
sense of identification and authentication (like aggreement).
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
