[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Shared Secret mismatch in AM3/MM5



Rick,

I don't know what the designers were thinking, but consider
man-in-the-middle for a minute. In order to defeat it, the IKE
authentication proof has to demonstrate the peer's knowledge of both the
shared secret and the negotiated Diffie-Hellman keying material. The design
of IKE does this quite effectively by binding the two together in a single
hash. If you remove the binding, then you reenable man-in-the-middle if you
don't introduce some other means to tie them together.

-- Jesse

-----Original Message-----
From: Ricky Charlet [mailto:rcharlet@redcreek.com]
Sent: Thursday, October 28, 1999 10:58 AM
To: ipsec@lists.tislabs.com
Cc: Andrew Krywaniuk
Subject: Re: Shared Secret mismatch in AM3/MM5


Andrew Krywaniuk wrote:
> 
> I have a question for anyone on the list who may know/care:


I care but don't know :-( All I'm doing in this post is basically
re-itterating one of Andrews questions which is currently on my 'must
research' list: Why is SKEYID defined that way? What were the
modivators? And specifically why is SKEYID not some direct derivation of
g^xy in all cases? Are there pointers to reference material? 

Thanks in advance...
Ricky Charlet
rcharlet@redcreek.com
(for my sig line quotable quote, please see Andrew's sig line since I
like it very much.)


> 
> 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: