[Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]

[Anne & Lynn Wheeler]

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 at metzdowd.com