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

Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt]



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

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



Follow-Ups: References: