[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-ietf-ipsec-ike-01.txt
Dan,
indeed the definition of HASH_I and HASH_R as described in the IKE
documents
HASH_I = prf(SKEYID, g^i | g^r | CKY-I | CKY-R | SAi_b | ID_i1_b)
HASH_R = prf(SKEYID, g^r | g^i | CKY-R | CKY-I | SAi_b | ID_r1_b)
is wrong. The repetition of SAi_b in both HASHs seems like an
*unfortunate typo*.
The intention is that in HASH_I the initiator authenticates the
information that I sends, and in HASH_R the recipient authenticates the
information that R sends.
Therefore the correct form should have been
HASH_I = prf(SKEYID, g^i | g^r | CKY-I | CKY-R | SAi_b | ID_i1_b)
HASH_R = prf(SKEYID, g^r | g^i | CKY-R | CKY-I | SAr_b | ID_r1_b)
^^^^^
In this way every party authenticates the information it sends which is
the main purpose of authentication. In particular this prevents the problem
pointed out by Dr. Zhou. (As pointed out by Tero, ZHou's suggestion to
have SAr_b in both HASHs is wrong as it allows an attacker to "degrade"
I's offer).
The above correction is really necessary in my view.
If this is done I would support to go to the more comprehensive change
suggested by Tero, namely, incorporating under the prf computation all
information sent by the corresponding party.
And, well, if we are going to change "the bits in the wire" with
such modification then I ask to do two more changes that I suggested in
the past but did not make it to the final spec:
1) In the computation of HASH_I prepend a byte = 0x00 to the input (i.e..
before g^i), and in the computation of HASH_R prepend a byte = 0x01 to the
input (i.e. before g^r). The goal is to make the two prf computations
necessarily different. Otherwise, in theory (but maybe also in practice?)
an attacker that impersonates R could choose all the values identically to
I and just resend HASH_I as the value of HASH_R (note that this would require
ID_i and ID_r to be the same but even this could be possible under some
scenario).
If you can get convinced that such a "reflection attack" will never be
practical then we may forget this, but otherwise the cost of this change
is small enough to justify it.
2) Add to HASH_I the value ID_r1_b and to HASH_R the value ID_i1_b.
You once had some problem in doing this and I do not remember why,
but this lack of authentication of the destination of a message may well
open sources of attack.
Another minor change would be to rename HASH_I/HASH_R as AUTH_I/AUTH_R.
These are not just hashes, they are authenticators (except, maybe,
for the signature mode) and it is better to have the notation consistent
with the functionality.
Hugo
On Tue, 22 Jun 1999, Dan Harkins wrote:
> Dr. Zhou has forwarded me the paper and I'll try to summarize:
>
> The Initiator offers two transforms, T1 and T2 to the Responder
> who chooses T2 and sends it back. This is intercepted by the
> attacker and changed to be T1 before being forwarded on to the
> Initiator. Now the Initiator thinks T1 was accepted and the
> Responder thinks T2 was accepted. It's noted in the paper (and
> was pointed out by Kivinen on the list) that the only difference
> between the two can be the lifetime. The attacker has to send
> back a transform that the Initiator sent in the first place
> and if the difference between T1 and T2 is more than just the
> lifetime the exchange will fail due to various errors (decryption
> failed, authentication failed, etc).
>
> The paper goes on to suggest changing SAi_b in the authenticating
> hash calculation to SAr_b. But this will allow an attacker to modify
> the Initiator's offers and remove certain offers-- for instance the
> offer is [(3DES, group 5, etc) || (CAST, group 5, etc) || (DES, group 1,
> etc)] and it becomes a single offer of [(DES, group 1, etc)].
>
> The suggested change is flawed but if the working group thinks this
> attack is serious we can include both SAi_b and SAr_b in the hash
> calculations to prevent this.
>
> Dan.
>
> On Tue, 22 Jun 1999 17:27:25 +0800 you wrote
> > There was a security flaw in RFC 2409.
> >
> > When SAi_b is used in HASH_I and HASH_R, an attack is possible so that
> > at the end of Phase 1 negotiation, the SA being negotiated may not be
> > authenticated. (The problem also exists in the new draft.)
> >
> > To avoid the attack, simply replace SAi_b with SAr_b. (The full paper
> > is available by request.)
> >
> > Jianying
> > ---------------------------------------------------------------------
> > Dr. Jianying Zhou | Tel: +65-8742585
> > Kent Ridge Digital Labs | Fax: +65-7744990
> > 21 Heng Mui Keng Terrace | Email: jyzhou@krdl.org.sg
> > Singapore 119613 | WWW: http://homex.s1.net.sg/user/jyzhou/
> > ---------------------------------------------------------------------
> >
>
References: