Subject: [mobile-ip] RE: Tuning a better revocation replay mechanism

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 20 Jan 2003 09:22:34 -0600

Hello Steve,
Sorry for the late response.
Please see my comments inline.

Regards,
Ahmad

> 
> 
> 
>      With thanks to Ahmad Muhanna for his initial input to tuning the 
> revocation replay mechanism in draft-ietf-mobileip-regrevok-04.txt, 
> I've changed the replay mechanism to work around a single DOS attack 
> that occurs should an agent loose state after a MN has a binding 
> revoked in which that old revocation is replayed against the agent 
> which lost it's state (if you'd like more details, I'll 
> supply them).  
> His recommendation was to use the ID fields from the 
> registration being 
> revoked, and in the case where multiple bindings are being revoked 
> simultaneously to use the ID field from any of said bindings.  First, 
> here's the proposed change to section 3.4 (note the removal 
> of the 'A' 
> bit in the packet format as taken from the changes to 
> sections 3.2 and 
> 3.3), followed by some thoughts.
> 
>     3.2  Revocation Message
> 
> The format of revocation message is analogous to registration request 
> and registration reply messages from [1].
> 
>     ...
> 
>     The UDP header is followed by the Mobile IP fields shown below
> 
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |     Type      |     Mask      |I|          reserved           |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                          Home Address                         |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                     Foreign Domain Address                    |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                       Home Domain Address                     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                                                               |
>     +                     Revocation Identifier                     +
>     |                                                               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>     ...
> 
>     3.3  Revocation Acknowledgment Message
> 
> The format of revocation acknowledgment message is analogous to the 
> revocation message.
>     ...
> 
>     The UDP header is followed by the Mobile IP fields shown below:
> 
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |     Type      |     Length      |I|         reserved          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                                                               |
>     +                     Revocation Identifier                     +
>     |                                                               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>     ...
> 
>     3.4 Replay Protection
> 
> As registration revocation messages are designed to terminate service 
> for a mobile node, replay protection is crucial to prevent denial of 
> service attacks by "malicious repeaters" - those who store datagrams 
> with the intent of replaying them at a later time, or by "malicious 
> reflectors" - those who reflect packets back at their original source 
> (both a form of "man-in-the-middle" attack).  See Section 7 for a 
> discussion of these security considerations.
> 
> Replay protection is handled in analogy with the mechanism defined by 
> [1], through two 32-bit identifier fields in the registration 
> revocation message and revocation acknowlegement messages.
> 
>    - The agent revoking a registration sets the Revocation 
> Identifier to 
> the value contained in the Identification field in the last approved 
> registration reply for this binding.  This is done by copying 
> the value 
> in the Identification field as a 64-bit value.
  
[A.M]
Do you think doing so will prevent any malicious reflectors.
i.e. in the case that some one returning the same registration revocation
back the agent sending it.
I know that the agent sending it probably has revoked the registration
anyway.

Your thoughts please?

>If multiple bindings 
> are being revoked, the revoking agent MUST choose the Replay 
> Identifier 
> of one of the bindings being revoked.
> 
>      - Upon receipt of an authenticated revocation message, the 
> receiving agent MUST check the value in the Revocation Identifier to 
> make sure it matches the value appearing in the 
> Identification field of 
> the last successful registration reply for this binding, 
> comparing the 
> fields as a single 64-bit value.  If the value of the Revocation 
> Identifier does not match the value in the Identification 
> field of the 
> last successful registration reply, the receiving agent MUST silently 
> discard the revocation message.  If multiple bindings are being 
> revoked, the revoking agent MUST make sure the value appearing in the 
> revocation identifier matches one of the binding being 
> revoked.  If the 
> value in the revocation message does not match the value in the 
> Identification field of the last successful registration 
> reply from any 
> of the bindings implicitly revoked in the revocation message, the 
> receiving agent MUST silently discard the revocation message, 
> and MUST 
> NOT revoke any of the applicable bindings.
> 
>      - When building a revocation acknowledgment message, the 
> acknowledging agent MUST copy the Identifier of the 
> revocation message 
> into the Identifier of the revocation acknowledgment as a 
> 64-bit value.
> 
>      - Upon receiving a valid revocation acknowledgment, the revoking 
> agent MUST check the Revocation Identification field to make sure it 
> matches the Revocation Identification field of the revocation message 
> it sent.  If not, the revocation acknowledgment MUST be silently 
> discarded.
> 
> 
>      Thoughts:
> 
>      1  Nonces are patented.  My concern is that by copying a 
> replay ID 
> which happens to be a nonce, that legal folks would argue that the FA 
> is using the nonce.  While technically I disagree with this argument, 
> because it's just data being copied, I'm overly paranoid 
> about what may 
> deter implementors.
>
[A.M]
I am not a lawyer BUT I definitely agree with your opinion.
We need to be careful as you mentioned above to refer to it as
the ID of the last registration reply. This makes it clear that
the agent is not generating any new ID (neither timestamp nor nonce)

My two cents.
 
>      2  There is a fundamental problem with the way nonces 
> are used in 
> replay protection.  RFC3344 states that nonces must be unique from 
> registration to re-registration during the same session.  This means 
> that in new sessions some nonces can be repeats of nonces in old 
> sessions (which is primarily because a MN may simply not have a means 
> of remembering all the nonces it's ever used.  Unfortunately, though, 
> this means that once a session has ended, ANY of the MN's previous 
> registrations can be replayed on the home agent (via any FA).  As a 
> result, should a MN repeat a nonce value that was used in an old 
> session, and for which a revocation message was issued, that 
> revocation 
> message can be replayed, thereby revoking this MN's binding, and any 
> others which were revoked by that revocation message, 
> potentially *ALL* 
> MNs bound through that FA or HA.  I personally see this as an 
> inherent 
> weakness when using nonces, and is outside the scope of the 
> revocation

[A.M]
I agree.
I think nonce is dependant on the strength of the random number generator.
If a strong random number generator is used, the possibility of the weakness

you highlighted becomes very minimal.
 
> draft, though I plan on pointing it out in -05 (though it more 
> appropriately belongs in my now expired security issues 
> draft, which I 
> now have more motivation to resurrect).

>      Please provide feedback!
>                                Cheers,
>                                    Steve

---

From: "Steven M. Glass" <[email-masked]>
Date: Tue, 21 Jan 2003 00:35:20 -0500

Ahmad,

     Responses in-line.

> I know that the agent sending it probably has revoked the registration 

     As long as the ID being used is one for which a binding is being 
revoked, then I don't see the threat.

     This is another reason why we the revoking agent can't keep the 
binding open until the receiving agent acks the revocation message - 
the revocation message can be reflected, and the sending agent can only 
assume that coincidentally the other side is revoking at the same time, 
and will ACK and kill the binding.

> the agent is not generating any new ID (neither timestamp nor nonce)

     Another possibility is that paranoid FA implementors may choose to 
not revoke bindings in which nonces are being used.

> you highlighted becomes very minimal.

     I don't agree.  It would seem the best random number generator 
yields a probability of .5 of duplicating a previously chosen nonce 
when the nonce number space is 1/2 exhausted.  If so, it would seem 
generators which cover the nonce space are best.  Although using a 
generator would seem to be a problem since it increases the chances of 
the next value being predicted, it really doesn't because the value is 
used for replay, and protected by the SA, so the SA still has to be 
compromised to fake "the next" registration message (which is only an 
advantage because it's guaranteed to contain an unused nonce, and so a 
bad guy doesn't necessarily have to be a man in the middle).  While I 
agree it's a lot of overhead, the best protection here is for the HA to 
remember all the values that have been used in every registration, and 
either use the resynchronizing mechanism in the core draft to prevent 
any duplication leading to a 'valid' registration, or more simply, just 
not use the same nonce in it's response that it used the first time the 
MN used that nonce, e.g.:

     Session 1:  MN registration request nonce = A
                 HA registration reply nonce = B --> replay field 
contains AB.

     Session 2:  MN registration request nonce = A (duplicate)
                 HA registration reply nonce = C --> replay field 
contains AC
                     and a revocation message containing AB can't be 
replayed.

                               Cheers,
                                   Steve