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

From: "Steven M. Glass" <[email-masked]>
Date: Thu, 16 Jan 2003 18:12:13 -0500

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

     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 
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: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 21 Jan 2003 08:36:09 -0600

Steve,
Comments in-line.

Regards;
Ahmad

>      Ahmad,
> 
>      Responses in-line.
> 
> On Monday, January 20, 2003, at 10:22  AM, Ahmad Muhanna wrote:
> 
> > >
> > >     ...
> > >
> > >     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 
> > >    - 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?
> 
>      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.
> 

[A.M.]
We probably need to capture this in the draft? 
e.g. under the Security Consideration section.

Regards,
Ahmad