[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Regarding Bill's draft... another Bill's open issues with photuris
> From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
> Here's a follow up on the issues which I raised earlier which Ran
> suggested might not have been addressed.
>
> Please also see Bill Sommerfeld's note to the IPsec list with
> a subject of "Re: IPsec mailing list", date of 9 Oct 1995
> 16:57:19
>
> The crucial part of this (the possibility of using change_message to
> replay the creation of an SPI which was previously deleted) has been
> resolved.
>
Thank you. As I remember, you had privately indicated this was solved
last October (about 5 drafts ago).
On to the new issues:
> I would, however, like to see some text in the draft regarding ways to prevent
> SPI's from significantly outlasting the shared secret initially used
> to create them. I'd prefer to see text requiring the SPI to die when
> the shared secret used to create it expires, but could live with
> something more liberal..
>
Actually, it is a fundamental "feature" of Photuris that the SPIs can
last longer than the exchange value:
When an Exchange-Value expires (or is replaced by a newer value),
the unexpired derived SPIs are not affected. This is important to
allow traffic to continue without interruption during new Photuris
exchanges.
Also, this feature allows Photuris to behave like SKIP (long-term stored
SPIs for authentication lasting past reboot). Perhaps you should argue
with someone else as to whether this latter facility is useful....
> The sender should stop using the SPI immediately when it expires. The
> receiver should allow a grace period of on the order of a minute or
> two to allow for slews in real-time clock frequency between the
> systems and to allow any packets in flight to be received.
>
That's a bit harder to do, and sounds implementation dependent
(as to both clock frequency and packet trip time). A minute seems
rather long, especially when the LifeTime is in seconds.
How is this particular to Photuris? Would that be more appropriate to
the general architecture document discussing LifeTimes?
Certainly, this isn't something you would like to see "negotiated"?
An implementation note already exists as to hold time:
To prevent resurrection of deleted or expired SPIs, implementations
SHOULD remember those SPIs, but mark them as unusable until the
Photuris exchange shared-secret used to create them also expires and
purges the associated state.
Perhaps you are asking for an implementation note that expands this need,
such as:
When an implementation detects an incoming SPI that has recently
expired, but the associated state has not yet been purged, the
implementation MAY accept the SPI. The length of time allowed is
highly dependent on clock drift and variable packet round trip time,
and is therefore implementation dependent.
> and his note subject "Re: Security Problems in Photuris #2" dated
> 12 Oct 1995 15:25:28
>
And again, as already stated above, the suggestion that the
"assumptions" about hashing funtions used as signatures be documented
resulted in the inclusion of Bill's suggested text (4 drafts ago):
The Verification method must not allow "message recovery", to
prevent determination of the shared-secret or any long-term
distributed secret-key (where applicable). More specifically, it
should not be feasible to compute any of the bits of an
authenticated message from the verification value.
In general, where a secret (such as the shared-secret or
session-keys) is involved in any calculation, the algorithms
selected should not reveal information about the secret, either
directly or indirectly.
This was in the Security Consideration for several revisions, and has
now been moved to the Security Analysis document.
> As best I can tell, a number of places in photuris-09.txt require the
> use of the now-known-to-be-vulnerable hash(key | data | key) structure for
> implementing a keyed MAC.
> ...
>
> There are a bunch of places where hash(key, data, key) is used:
> - section 5.4 privacy method key generation.
> - section 5.5 identity verification
> - section 5.6 session key computation
> - section 6.1.7 integrity verification on change_message
>
> The way it's used in the change_message appears to me as if it might
> allow the keyed hash to become a target for chosen-plaintext attacks.
> I think the other uses are less of a risk, but then I'm not really a
> cryptographer.
>
The analysis is faulty.
In both cases, the key is both prefixed and appended in order to provide
additional key mixing over the potentially large amounts of data. That
was a concern raised during earlier drafts, and the drafts were changed
to meet that earlier review. There is no opportunity for an "appending
attack" on these values.
There could not possibly be an "attack" on the key generation. This
creates a secret value, the key.
An attack on the verification is both unlikely and impractical. This
value is encrypted, and therefore also "secret" from an observer.
See the Nov 17 paper by Preneel and van Oorschot:
"Practical attacks often require that a forgery is _verifiable_ ...
Verification of such an attack requires k/m text-MAC pairs."
In this case, the MAC is unknown, and therefore not verifiable.
More importantly, the attack requires a large number of different
chosen-messages. Since it is not possible for an attacker to "choose"
the parameters being verified, this attack is impossible.
Most importantly, the attack requires an incredibly large number of
known-messages, on the order of 2**65 or more! That makes it utterly
impractical (also stated by the authors).
> Recommended high-level changes:
> 1) Redefine the following hash algorithm families as keyed hashes:
> validity-method
> identity-choice
> privacy-method key generation
> SPI session key generation
>
They already are. That is, a hash over the key. MD5 is used in the
base document, but other hashes are possible for other Exchange-Schemes.
(See Extensions draft for details.)
> 2) define the key used for validity-method, privacy-method keygen,
> and SPI session keygen as the shared-secret
>
This is a cryptographically unsound idea.
Disclosure of the key for any one of these would disclose the
shared-secret used to generate all the other keys. That would make it a
serious target. Especially as it is so easy to determine the DES
privacy key.
The shared-secret is _never_ used directly. As stated:
Photuris generation of session-keys involves a cryptographic hash
over the shared-secret. The shared-secret is itself only indirectly
used for creating those keys that actually protect session traffic.
This protects the shared-secret from discovery, and allows repeated
use of the shared-secret for generating multiple session-keys.
Discovery of one such key should not reveal related session-keys.
> 3) define the key used for the identity-choice algorithm as
> the shared secret, concatenated or otherwise combined with the
> authentication secret-key if there was one.
>
Again, an incredibly insecure idea.
Bill.Simpson@um.cc.umich.edu
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Follow-Ups: