[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on ISAKMP/Oakley - 04
Hi Michael,
> I have the following comments/questions on the new version of
> ISAKMP/Oakley:
>
> 1) Main and Aggressive Modes authenticated with public key
> encryption
> - On page 4 it is stated that PFS is provided for both keys and
> identities, but how do the modes authenticated with public key
> encryption provide PFS for the identities?
Authentication with public key encryption doesn't provide PFS of the
identities (but it can provide PFS of keys). The draft states that PFS of
identities is "provided by this protocol." It doesn't state that every
possible mode and authentication combination provides PFS. If you want PFS
of identities don't use public key encryption to authenticate (and don't
use aggressive mode).
> - The initiator optionally sends HASH(1) to tell the responder
> which public key was used.
> Why doesn't the responder send a corresponding HASH
> when the initiator has more than one certificate?
Because the responder has already decrypted the initiator's identity and
will use the public key from the certificate that corresponds to this
identity to encrypt his response.
> - Both initiator and responder encrypt nonces and identities
> (<ID>PubKey, <N>PubKey) in two steps.
> An attacker could intercept the messages and insert
> the own identity. Currently, I don't know how to build a
> successful attack based on this 'weakness', but I propose to
> resolve this potential weakness by encrypting the concatenation
> (<ID || N>PubKey) instead.
If he inserts his own identity then he is basically just initiating a new
ISAKMP request to the responder. The fact that he's preventing another
party from doing likewise is separate and no protocol can prevent that.
(It's basically what a firewall does, prevent packets from reaching their
intended destination). The thing is, the _real_ initiator (as opposed to
the new initiator who is the "attacker") would never complete the exchange.
He'd be left hanging. A real attack would make each side think everything
is hunky-dory but leave the keys in the attacker's hands. This isn't happening.
Note that there's typo in the public key authentication with aggressive mode
example: the responder replies with <Nr>PubKey_i, not <Nr>PubKey_r. This,
a few other things (mostly spelling mistakes), will be corrected shortly.
> 2) The hash values HASH_I and HASH_R for authentication are
> computed over SAp, ...
> SAp is defined as the entire body of the SA payload offered
> by the initiator. Is it a misprint or why is HASH_R computed
> over the initiator and not over the responder SA payload?
Forcing the responder to hash the initiator's original offer(s) prevents
a man-in-the-middle attack. Imagine you want to communicate with some entity
and [insert your favorite bogeyman here] wants to evesdrop on all
conversations to that entity. You could make an offer that includes strong
encryption (which may be preferred) and less-than-real-strong encryption
(which may be the regrettable last choice). The bogeyman can modify your
offer in flight to be a single offer of the less-than-real-strong encryption
which he may have experience in cracking. The entity may regrettably agree;
he would've preferred your other offers but he never received them. Neither
you nor the entity know this occured. By having the responder include the
entire suite of offers in the authenticating hash, this attack is prevented.
regards,
Dan.
References: