[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Photuris Security
Bill wants to finalize Photuris. Me too.
However, Photuris is still an *insecure* protocol as defined.
(It also contains several ambiguiites and
lacks some basic -IMHO- functionality but that's a subject
for another message).
I have raised more than 6 months ago several issues related to
Photuris security holes for which I never got a response from the editors.
Needless to say, these comments were never reflected in the protocol.
I have brought up these issues several times in these months both in
the list, and personally (in Danvers) with the editors.
I know that Phil is very busy with other stuff, and I can't blame him
for that (I am busy too). However, this cannot be a justification
to have a buggy key management protocol for IP.
I am appending a message I sent to this WG list on June 12th on these issues.
I'd like to know how the editors dealt with these comments;
I cannot imagine they just ignored them, that's too much irresponsibility
especially with those comments that touch the basic security of the scheme.
Points (1), (2), and (5) in the attached message are the most critical
for security. (As for (5) the comment now applies to the "Change_Message"
in pg 24 of draft 03).
In partricular can you please let me know:
About (1): do you have a requiremnet that the signature transform hides the
contents of the signed information? This is not written in the document,
and is *not* the property of signatures in general.
For example RSA signature without hashing reveals all of its contents which
in this case include the shared-secret
(as an example, hashing may not be applied if the total information length
is less than the RSA modulus length, a perfectly possible case when the
DH is based on 155-bit Elliptic Curve).
About (2): I am willing to explain more on this if you are receptive to the
need of change in the protocol. In particular, MAC-ing as I suggest solves
both the shared-secret leakage problem of (1), and prevents the [DOW92]
attacks that motivated the signing of K.
About (5): If you believe that a previous (possibly broken) SPI cannot
be replayed please explain that to me.
In addition: the way keys are derived for data-transforms (e.g., DES-CBC,
MD5) from a session key as described in the draft (Appendix B) is unacceptable
as already posted in this list (i.e., re-use of same bits for
DES-CBC and MD5).
I have many other comments on the draft that I will send in next days.
However, the above seem to be the most critical for security.
Hugo
Appended (historical) message:
> Date: Mon, 12 Jun 95 20:40:43 EDT
> From: hugo at watson.ibm.com
> To: KARN@QUALCOMM.COM
> Cc: IPSEC@ans.net
> Subject: Status of Photuris
>
> Phil,
>
> Stockholm is approaching and we have not heard about the
> developments with Photuris since Danvers. I would like to know the status
> of the following important issues on which I have had objections and/or
> recommendations.
>
> 1) The DH key (or "session key" SK) must not be signed. Signing SK is
> unnecessary and, even worst, it is insecure. (See my note of April 12)
>
> 2) Encryption of the signature messages is needed for privacy (anonymity).
> However, it is *not* the right solution for proving possession of the DH key.
> (The latter is needed to avoid some of the attacks described in the
> Diffie-Van Oorschot-Wiener paper).
> A right (and necessary!) solution is to have, in addition of the
> signature, a MAC (message authentication code, e.g., key-ed MD5) keyed
> with the DH key and applied to the same information that the signature
> is applied to (or to the signature itself). In particular,
> the MAC must be mandated even if the signature is encrypted for privacy
> (notice that this is a change relative to the original STS protocol).
> (See my note of April 12).
>
> 3) A fast re-key mechanism is to be provided for key refreshment based on
> symmetric key techniques (as opposed to DH and/or PK techniques). This
> is to be done by refreshing the key by means similar to those implied in the
> draft (page 20). However, the necessary nonces for freshness
> guarantee should be provided explicitly (e.g., by replacing the DH-exponent
> fields of the DH-exchange message with a fresh nonce). SAID's are not to be
> used for this purpose. Cookies can be used (since cookies must be
> unpredictable by definition), however, I would still recommend using special
> purpose nonces, to avoid the double functionality of cookies against denial
> of service attacks and nonces (in particular, cookies may be unncessary if
> the parties already share a previous key since then verifying a MAC is very
> fast, actually as fast as generating a cookie).
> One simple and secure solution to this fast re-key is presented in the
> IKMP draft (Usenix conference version also available); this solution is
> compatible with the basic Photuris format.
> (See exchange of notes with Phil at end of March).
>
> 4) The protocol should support a DH exchange that is authenticated by means
> of a previously shared key between the parties. This provides for a secure
> solution in many important scenarios, including the cases of
> * parties with manually installed long-lived master keys,
> * parties that get a common key from a key distribution center (a la
> Kerberos), or
> * parties that use a previously shared DH key for refresh via a new
> DH exchange.
> In these cases, signatures can be replaced MAC w hich is beneficial
> both for efficiency and privacy.
> For the purpose of this exchange the basic DH flows of Photuris remain
> unchanged except that
> a) signature is omitted
> b) the MAC field is used to authenticate the information that is
> otherwise signed, but the MAC is computed using the previously shared key
> (e.g., the shared Kerberos key, etc).
> [This is a basic functionality provided by my "Photuris variant" but which
> is easily adaptable to the basic Photuris. This was described and discussed
> with Phil in Danvers]
>
> 5) The non-interactive key refreshment in page 26 of the draft (re-key message)
> needs to be eliminated. If there is a good reason to keep it, it needs
> to be re-designed to avoid replay attacks (e.g., via a shared counter).
> The way it is designed now it is vulnerable to replay and then insecure.
>
>
> Hugo
>
> PS: Hope this time a revised draft will be available well before Stockholm.
>
>