[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Shared Secret mismatch in AM3/MM5
I have a question for anyone on the list who may know/care:
When two peers are negotiationg a phase 1 SA in shared secret mode, a
disagreement in the shared secret will result in a decryption failure in the
first encrypted message -- MM5 or AM3 (which we choose to encrypt).
The decryption failure usually results in one of the following errors:
Invalid Payload Type, Invalid Id Info, or Payload Malformed. Of course, a
sophisticated implementation can infer that the decryption failure was the
result of a shared secret mismatch and report this to the user...
But it makes troubleshooting difficult. It is hard to distinguish between a
deliberate attack, a user mistyping his password, and a misbehaving
implementation.
So I was wondering about the underlying reasons why we get this error. There
seems to be two causes:
1) SKEYID_e is derived from the shared secret.
2) The HASH_I payload comes at the end of the message (after the Id).
So what is the importance of these two design constraints? Why do we base
the encryption key on secret data (other than g^xy) in shared mode, but not
in cert mode; and why do we put the hash at the end of the message in phase
1 but not in phase 2?
My guess is that SKEYID_e is derived from the shared secret because:
a) it increases the entropy of SKEYID and, in particular, the amount of
entropy which could not be guessed by an attacker.
b) it protects against a MitM attack.
However:
a) the cert mode SKEYID doesn't have any unguessable entropy except g^xy (so
presumably this would be sufficient for shared mode as well).
b) HASH_I provides adequate protection against a MitM attack (or else the
encryption of AM3 would not be optional).
My guess is that the HASH_I payload comes at the end of the message because:
a) when not encrypting AM3, the shared key could depend on the id (so id
then hash represents the logical order of processing).
b) the hash contains the id, so to verify the hash you need to have already
parsed the id (so id then hash represents the logical order of processing).
However:
a) there is no absolute requirement that the order of payloads in the
message be the same as the order in which they are processed.
b) if the hash came at the beginning of the message, an implementation could
always return the same error if decryption failed (choosing either Invalid
Hash Info or Authentication Failed). In fact, [IKE] states that in quick
mode, the hash MUST immediately follow the header, presumably for exactly
this reason.
If anyone can find fault with my arguments, or if they know of other reasons
why these constraints have to exist, I would like to hear about it.
Andrew
_______________________________________________
Beauty without truth is insubstantial.
Truth without beauty is unbearable.
Follow-Ups: