[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKE drfat - draft-ietf-ipsec-isakmp-oakley-08.txt
Let me also note that the issue raised here is, in fact, mentioned
in draft-ietf-ipsec-isakmp-oakley-08.txt (in section 5.4). Characterizing
this as a recently uncovered flaw implies that the author either has not
fully read the draft or is intentionally mischaracterizing the issue for
dramatic effect.
Dan.
On Mon, 27 Jul 1998 06:29:39 PDT you wrote
>
> Hi,
>
> I understand everyone is waiting for the IPsec drafts to advance
> into RFCs. But, I am afraid, a serious flaw was uncoverd in the
> IKE draft recently (late June). I believe, this flaw needs to be
> corrected before the draft is advanced into an RFC. The issue
> came up during a discussion between Bryan Gleeson, Vipul Gupta,
> myself and others.
>
> I mentioned the problem on the ipsec mailing list briefly at that
> time and have been trying to resolve this independently with Daniel
> harkins via private e-mail. But, to no avail. Dan is opposed to
> altering the draft. I would like the IESG to review the problem.
>
> Ref: Section 5.4. Phase I authenticated with Pre-shared-key
>
> Problem: While Main mode of negotiation and pre-shared-key based
> authentication are independently stated as mandatory for
> IKE draft compliance, together they do not work.
> I.e., Pre-shared-key based authentication in Main mode
> does not work or is seriously flawed in the way it is
> stated to work.
>
> Explanantion + A possible fix:
>
> Section 5.4 states that pre-shared-key based authentication
> in main mode requires either party to assume the source IP
> address of the partner (found in IP header) as the ID of partner.
>
> This is because the SKEYID used to encrypt the ID payload is
> based on pre-shared-key. And, the pre-shared-key couldnt be
> known without knowledge of the ID of the partner. Clearly, the
> draft cornered itself into a chicken-and-egg problem.
>
> If IP-Address type was the only valid ID type, we could take the
> IP address in IP header (layer 3) as a replacement for IP address
> in ID payload (layer 4), as the draft says. But, that would be a
> layer violation (assuming layer 3 info in place of layer 4 info).
> Even with the layer violation, this assumption is workable only
> with an IP-address type ID. For an IP DOI, the ID can be many
> different things, including a user-name, device-name, DER encoded
> Distintinguished Name etc. IKE negotiation would simply not work
> with these ID payloads.
>
> Suggestions that we should get around this by using aggressive
> mode or use a different type of authentication mode only enhance
> the argument that the protocol is inadequate for minimally
> compliant IKE implementations(ie, Main mode + Pre-shared-key auth).
>
> One approach I could think of to fix this problem was to
> disassociate authentication mechanism from key derivation
> (SKEYID). I am not a cryptographer and I do not understand
> why SKEYID is evaluated differently based on authentication
> schemes used. I would suggest making derivation of SKEYID
> uniform for all authentications, like
> SKEYID = prf (hash(Ni_b | Nr_b), g^xy)
>
> At a minimum, I would suggest the above SKEYID key derivation
> change to pre-shared-key based authentications. The
> chicken-and-egg problem with pre-shared-key based authentication
> is created because, SKEYID is derived as a function of
> pre-shared-key. For all other types of athentications, SKEYID
> derivation does not require peer ID info.
>
> Authentication based distinctions could be restricted simply
> to the way HASH_I and HASH_R are evaluated. For example,
> HASH_I and HASH_R for pre-shared key authentication could have
> been evaluated differently by concatenating pre-shared key to
> the message argument (i.e., arg2) of prf.
>
> Thanks.
>
> Regards,
> suresh
References: