[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: signture mode and non-repudiation



Hugo,

>Stephen Kent wrote:
>
>  > Well, not all signatures are intended to be non-repudiable!
>  > Sometimes we sign things purely for authentication.  As we have
>  > discussed extensively on the PKIX list, one should exercise care in
>  > setting the key usage bits, to distinguish the intent of signing as
>  > repudiable or non-repudiable. So, IF one wished to use
>  > signature-based authentication with IKE, and wished to avoid any
>  > connotation of non-repudiation, it is feasible to do that.
>
>Even if a user U insists that his use of the signature mode does not
>provide non-repudiation (by usage bits or whatever means) still a person
>holding U's signature on the establishment of an ipsec SA can prove to
>a third party that U established that SA. This is not a issue of legal
>binding provided by the signature (and accepted by the signer) but a
>privacy or confidentiality issue of leaving your "fingerprints" in the
>places you visited in Internet.

>In general, I recommend to talk here about "deniability" (or
>undeniability) rather than non-repudiation (which has stronger legal
>connotations).
>
>In this context it is important to remark that providing non-repudiation
>of SA establishment is NOT a requirement of ipsec. To the contrary,
>it is to some extent a drawback of the signature mode (encryption mode
>deals better with this issue).

I agree that we should separate legal from technical issues here. 
However, my point was precisely that if we adopt technical measures 
suitable for authentication, but NOT suitable for non-repudiation, 
then we can avoid this perceived problem.

>Moreover, the signature mode of IKE has been designed to minimize the
>``non-repudiation effect''.
>How? By letting the user of this mode (the signer) to find collisions in
>the input to the signature function. This is possible under certain
>instantiations of the prf function.
>To see this note that the values HASH (_I and _R) over which the signature
>is computed are the result of applying a prf to some data.
>A good choice of a prf could be, for example, 3DES in CBC-MAC mode.
>This would serve very well the purpose of the signature mode
>(i.e., as a strong authentication of the key-exchange) but will also
>allow the signer to claim that she signed a different message than the
>one she really did. (This is a good crypto class exercise: the user that
>knows the 3DES key used to produce HASH can easily find a different message
>that maps to the same output of the prf!)

Yes, as first shown in a paper by Gligor and a grad student a number 
of years ago, when they noted that DES-MAC made a poor hash function 
in an early version of PEM.

>
>A collision like this may not be sufficient for the user to convince a
>journalist that he did not talk to some dubious party over the Internet,
>but will be enough to invalidate a legally acceptable 
>non-repudiation property.
>
>On the other hand, if anyone insists in using the signature mode for
>non-repudiation purposes (I do not recommend that) then he can use
>a prf which is also collision resistant (e.g. HMAC-SHA1).

I would go beyond this to suggest that we standardize on a function 
for the signed data that is intentionally not collision resistant, 
without worrying about the implications for the PRF re key selection 
in general. That way we could avoid unintentional NR "features" of 
signature-based IKE authentication.

Steve



Follow-Ups: References: