[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Security Problems in Photuris #1
In spite of the attempt of Bill to discredit me and my findings about
security holes in Photuris, the issues I brought up are serious and
substantial. They apply to Photuris draft 03 (referred to as
Photuris.03 in the sequel) and several of them were identified long ago (>6
months) and no action was taken. I consider this situation unacceptable:
can we afford defining an insecure key management protocol for IP???
I will try to elaborate on these issues in a few messages to this list.
Ran Atkinson referred to my last note as "impenetrable" and I can't but
agree with him. To understand these issues one needs much more background on
these problems than I have provided to the list. I mainly intended my last
note to the editors of Photuris whom I expect to be more knowledgeable
of the subtle issues involved here, and with whom I had the opportunity to
discuss some of the issues in the past. I hoped that by having the editors
taking care of these changes, my life, and yours, would be easier, and our
convergence to a secure protocol faster.
Since this is not happening I will try to be more explicit about
the Photuris problems. All the issues that I'll mention are related to
Photuris.03 (except if otherwise noted).
The problems fall in different categories, and have varying effect on the
security. Some of these categories are (I will elaborate on the particular
examples in the upcoming messages):
(1) insecure mechanisms. For example, the allowed use of digital signatures to
be applied to secret information, or the derivation of keys for DES-CBC and
keyed-MD5.
(2) insufficient mechanisms. For example, missing defenses against replay
for the Change_Message, or the proposed solution to fast re-key.
(3) language problems. Usually, missing or insufficient specification
of cryptographic requirements or functionality. The specifications for the
certificate field in the signature message is an example.
As a general remark: I will point out to problems, and will suggest
solutions. I am not contributing text at this time since this would increase
too much my wasted time if the editors oppose these changes. In case they
are receptive to the need for change I may try to contribute text as well.
*An important point to stress*: none of the changes I propose require any
radical modification to the protocol, or to ongoing implementations of the
protocol, they are simple to do and are fundamental to the security of the
protocol.
I hope people will read this, and give their feedback (in favor or against
the required changes) to the list.
Waiting for a "last call" to deal with the basic security of the protocol
would be irresponsible. Also from my part. We need to give time to other
people (in particular, other cryptographers) to scrutinize these security
solutions as well.
TO BE CONTINUED
Hugo