[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Photuris Security
> Date: Fri, 6 Oct 95 18:51:29 EDT
> From: hugo@watson.ibm.com
> To: karn@qualcomm.com, bsimpson@MorningStar.Com, ipsec@ans.net
>
I remind Hugo that Phil and I are both on the ipsec list, and really
don't need multiple copies of a message to bring it to our attention.
Also, I asked for comments on Chapter 1. You are outside the scope of
the discussion at this point. There will be a "last call" from the IESG
where you are certainly welcome to raise whatever issues that you wish
on the overall document.
> I have many other comments on the draft that I will send in next days.
Please don't, unless they are explicit language improvements, which is
the current discussion. Note the excellent recent comments by Hilary.
> However, Photuris is still an *insecure* protocol as defined.
> ...
> 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.
>
Actually, because there was so little substance, it would have been
irresponsible to pay _any_ credence what-so-ever to the plaints. I was
asked _not_ to respond (by more than one person).
Moreover, although I cannot speak for Phil, I was so turned off by your
incessant rants that I stopped working on Photuris for several months.
I have recently been encouraged by the results of widespread
implementation efforts. I am doing my best to address the issues raised
by these implementors, so that they also are encouraged and satisfied
and work together.
However, the IETF Standards Process requests that we certify that we
have addressed even insignificant objections. When your earlier
messages were sent, we were only asking for Experimental status, and
could safely ignore you. Unfortunately, the WG chairs seem to want to
progress this as a Proposed Standard instead.
Therefore, I will attempt to review these few items, under the
assumption that this will satisfy your curiousity as to _why_ we ignored
them. I have rearranged them more logically, in the order discussed in
the actual Photuris document.
Nota Bene, for the rest of the folks: this is a direct and personal
response, which may be offensive to some, although I have attempted
to keep the sarcasm to a minimum. You have been warned.
----
> > (See my note of April 12)
This was interspersed throughout the message.
Actually, I prefer to _again_ ignore your note of April 12, since it has
so many inaccuracies with respect to Photuris, including its derivation
and the use of its fields. Particularly, you seem to suffer from the
delusion that Photuris is based on STS, and interpret Photuris features
as STS features. This is not correct. We did not learn of STS until
Van Oorschot faxed a copy to Karn in March 95.
Another example is the reference to failure with respect to certain
unnamed stream cyphers, which are nowhere discussed in Photuris. It
would be helpful if, in the future, you did not make up attacks based on
material which is not in the document.
----
> > 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, ...
It would be very helpful if you actually _read_ Photuris, and paid more
attention to the other messages on the IP Sec mailing list.
This is already required to be supported by Photuris.
This is the only currently implemented authentication technique.
Other techniques such as RSA (PKCS, PGP, X.509) are optional, because of
patent and export restrictions. But, they have been reserved and are
described elsewhere in great detail.
The ability to dynamically select which signature method is used has
long been a fundamental principle of Photuris.
> > 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 some unusual use of the word "signature", which is not that same
as I am given to understand in either the English language or
cryptography.
The Signature_Message always has a Signature field. This field can
indeed contain any form of authentication. But the basic specification
requires that it contain a MD5 hash.
There is no separate "MAC field", as referenced above.
----
> > 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)
> >
Early drafts (include -01 which you were so vehemently against) did not
discuss which fields were signed. They did not mention signing the
shared-secret (computed by the D-H exchange). Indeed, the shared-secret
was not signed in Karn's early implementation. Only the public values
were signed.
However, Van Oorschot (as I remember) later noted that an
authentication-only version of the protocol was possible if we signed
the shared-secret. Since an authentication-only version of the protocol
is desirable in amateur radio networks, that is what we have selected.
Only the authentication-only signature form (using MD5) is described in
the base Photuris document. It is clearly indicated as "required to be
supported".
You have not explained to my satisfaction why signing the fields as
described in Photuris in any way "leaks" information about the computed
shared-secret or the trailing secret-key used for MD5 (see Appendix B).
> 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.
Then, it should not be surprising that it is not written in the document.
> For example RSA signature without hashing reveals all of its contents which
> in this case include the shared-secret
Perhaps you make a nice publication record out of reiterating the
obvious, but it does not belong in Photuris.
> (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).
>
It would be helpful if, in the future, you did not make up attacks based
on material which is not in the document.
----
> > 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.
I can find no reference in Photuris (any draft) where _optional_
encryption of the exchange is used for the _requirement_ of proving
possession of the D-H shared-secret.
> > (The latter is needed to avoid some of the attacks described in the
> > Diffie-Van Oorschot-Wiener paper).
> > ...
> > (notice that this is a change relative to the original STS protocol).
> > (See my note of April 12).
> >
Again, you have mistaken Photuris for a derivation of STS. Photuris has
never had this putative STS failing.
It would be helpful if, in the future, you did not make up attacks based
on material which is not in the document.
> About (2): I am willing to explain more on this if you are receptive to the
> need of change in the protocol.
You have not yet given any reason for a change in the protocol.
----
> > 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).
This feature was not in the original Photuris drafts, but was added at
the repeated request of _many_ members of the WG.
I do not understand what you mean by "implied in the draft". Upon
reviewing page 20 of draft -01 (now page 22 of draft -03), the section
is clearly labeled "Session-Key Computation", and clearly and completely
describes the derivation of session keys.
> > 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).
Exchanging _new_ public-values is already an option. "Either party may
initiate an exchange at any time." [page 6].
However, the alternative Change_Message does not exchange the public
values. This results in fewer messages, and avoids overloading the
public-value fields with other "nonce" fields (which I find preposterous).
> > SAID's are not to be
> > used for this purpose.
You have not yet described any cryptographic weakness with the approach.
Until you can, please don't tell me or anyone else what may "be used"!
The SPI _is_ currently used. It is guaranteed to be unique to the party
generating it over the lifetime of the shared-secret, is recommended to
be generated randomly, and is "fresh" in every known cryptographic sense.
Oh yeah, and we avoid the IBM patents, too....
> > Cookies can be used (since cookies must be
> > unpredictable by definition),
You are incorrect. The cookies of subsequent exchanges are _not_
required to change in the Responder direction. Indeed, there is explicit
mention of rapid calculation when the public-values are the same.
> > 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).
Since the parties already share a previous D-H shared secret, this is
already used.
Using a previous session-key instead would be a _SERIOUS_ security flaw,
as it would not ensure Perfect Forward Secrecy.
The cookies are _not_ used as nonces, and therefore not subject to such
"double functionality".
----
> > 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.
> >
This seems very much to be the same issue as (3), except you now want to
eliminate the message altogether.
You have not yet described any cryptographic weakness with the approach.
> About (5): If you believe that a previous (possibly broken) SPI cannot
> be replayed please explain that to me.
>
It is not a matter of belief. This is one of the reasons that
protection of Perfect Forward Secrecy (which you have tried to
"optionally" eliminate in your "variants") is so important.
The session-keys are dependent on the D-H shared secret, the signatures,
the cookies and the SPI. The shared-secret and cookies are in turn
dependent on the Photuris session. The signatures are dependent on the
Photuris session _and_ the long term certificates or secret keys.
Once any of the above have changed, the SPI cannot possibly be replayed.
----
> 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
To date, there has been no posting to this list which describes a
cryptographic weakness in the derivation of the session key for either
DES-CBC or MD5.
Your "proof by assertion" is not acceptable to me.
> (i.e., re-use of same bits for
> DES-CBC and MD5).
>
This "potential weakness" has been discussed from time to time, but no
_actual_ interaction between DES-CBC and MD5 has been described in the
literature to my knowledge. Perhaps you could be more explicit?
While the same SPI and session-key _may_ be used for both ESP and AH, it
is not required. See [page 10]:
Typically, an encryption method is chosen for the primary
attribute of the SPI, and an authentication method is later added
for the same SPI, or as an additional separate SPI.
In any case, since this is a potential limitation of both manual and
automatic key generation, its discussion belongs in the Security
Architecture. Perhaps you should raise this theoretical issue again
when that document goes to Draft Standard.
Moreover, this is less likely with Photuris than with manual key
management. Photuris is quite capable of rapid SPI session-ley
generation, as noted earlier, and will not need to "re-use" keys.
----
Sat, 7 Oct 95 18:58:08 GMT
By the clock, I have now wasted over 3 hours of a nice Saturday morning
and part of an afternoon replying to this message.
I could have been doing many other things, such as actually editing
drafts or working on code, or just plain enjoying the day.
I refuse to expend more time on this particular individual. Certainly
not when he merely repeats previously posted messages, that were roundly
ignored by everyone the first time! Perhaps again in 3 months....
Bill.Simpson@um.cc.umich.edu
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2