Status of Photuris

[hugo@watson.ibm.com]

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.

---

• Prev by Date: Use of signatures vs. encryption (to complement DH in Photuris)
• Next by Date: Last Call: Security Architecture for the Internet Protocol to Proposed Standard
• Prev by thread: Use of signatures vs. encryption (to complement DH in Photuris)
• Next by thread: Last Call: Security Architecture for the Internet Protocol to Proposed Standard
• Index(es):
  • Main
  • Thread