[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt]
On Thu, 13 Jul 2000, D. Hugh Redelmeier wrote:
> | From: Jan Vilhuber <vilhuber@cisco.com>
>
> | > In fact, the replay attack cannot work if the Responder implements the
> | > RFCs. The RFCs stipulate that the Message IDs of Phase 2 exchanges must
> | > be unique.
> |
> | I don't remember for sure, but I thought message ID's were also supposed to
> | be random. So unless a host saved a list of ALL messages ID's ever used or
> | encountered, then you couldn't detect the replay!
>
> As we explain slightly later in the same document, it is only
> necessary to save message IDs used/encountered *within the current
> ISAKMP SA*. When the ISAKMP SA expires (whether or not it is replaced
> by a fresh one), the message-ID memory can be freed. As also noted,
> we have implemented this and the memory consumption has not been a
> problem in practice. Half-measures are not necessary; doing it really
> right is not costly.
>
I disagree. This adds even more memory to internal state that must be kept.
In machines with limited memory, this is an issue.
jan
> It appears you didn't understand what we were trying to say. Could
> you explain what parts aren't clear? We'd like to make it clear.
>
> | I interpret 'unique' as meaning that they are unique in the sender's
> | 'name-space'.
>
> We suggested in the quoted section that "unique within an ISAKMP
> SA" would be sensible and sufficient.
>
> (At one time our implementation used a broader scope of uniqueness
> but the greater burden was still not a problem.)
>
> | It means that I can not send out two quick-modes with
> | message-id == 5 AT THE SAME TIME.
>
> Yes, it means that and more.
>
> | There's nothing from preventing me (or my
> | bad random number generator) from sending out a quick mode with message-id 5
> | now, and then again 10 minutes from now, after I'm long done with the old
> | quick mode that used 5 (and completely oblivious to it, too, unless I keep a
> | list of all previously used message-ids).
>
> I see nothing in the RFC to bound the time the way you seem to. So
> yes, there is something preventing you: you are not following the RFC
> if the Message ID is not unique. And you won't interoperate with my
> implementation which is following the RFC.
>
> | Can you elaborate on this some more?
> |
> | Bottom line is that I don't think the intent of the message-id was to prevent
> | replay attacks.
>
> I'm not arguing about intent, only about following the specifications.
> The specs say "unique", and that gives a wonderful property. Are you
> suggesting we change the specs to remove this property?
>
> | It's simply an identifier to match up requests and replies.
> | The Nonces fulfill the replay requirement, but if you use "Responder
> | Pre-Set-Up", then you're not waiting to get QM3 (that proves that the remote
> | has the right key) before setting up your SA and accepting traffic on it.
>
> We are preventing replay. Given that, plus authentication, it does
> not appear to us that this proof is required at this point. Have we
> overlooked something?
>
> | So I believe Tim is right in that there is a security hole here.
>
> If we are preventing replay, do you think there is still a hole?
>
> Hugh Redelmeier
> hugh@mimosa.com voice: +1 416 482-8253
>
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
References: