Subject: RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol related) (ISSUE No. 14)

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 26 Sep 2002 12:01:08 -0500

please see comments inline.

Regards;
Ahmad Muhanna

Non-editorial comments associated with RFC3012bis:

Please post your comments with the appropriate issue number in the subject
line (instead of simply replying to this email).

-Chairs.

14. Section 12 
   Whenever a Foreign Agent updates a field of the Registration Reply
   (as suggested in section 3.2), it invalidates the authentication
   data supplied by the Home Agent in the Mobile-Home Authentication
   extension to the Registration Reply.  Thus, this opens up a security
   exposure whereby a node might try to supply a bogus Registration
   Reply to a mobile node that causes the mobile node to act as if its
   Registration Reply were rejected.  This might happen when, in fact, a
   Registration Reply showing acceptance of the registration might soon
   be received by the mobile node.

   The section reference should be 3.3.
<<Ahmad>> agreed.

   More importantly, is there no way to ameliorate this?
   It seems like a serious technical definiciency.

<<Ahmad>>
I think this paragraph needs to be modified. It is somewhat confusing and I
am not sure
if it is accurate.

In section 3.3., the FA inserts the MN-FA Challenge extension which is after
the MN-HA
authentication extension. This does not invalidate the authentication data
supplied by 
the Home Agent in the Mobile-Home Authentication extension in the
Registration Reply.

On the other hand, If a Registration Reply with error code is generated by
the Foreign
Agent, Only this scenario is vulnerable to bogus attack. More explanation in
the following example:

1. A MN1 sends a RRQ1 message to FA1 with challenge FAC1.
2. FA1 process the RRQ1 and relay the RRQ1 to the specified HA1.
3. FA1 starts a timer to receive a RRP1 message from HA1.
   3.1. Now: there is a possibility of a malicious node CN2 which has
captured
        the information from the RRQ to build a RRPx message and send it to
        MN1 with an FA generated error code "ONLY FA error code may work
here"

   3.2. If CN2 is able to build and send this RRPx message before the MN1
receives 
        a RRP1 from FA1, there a possibility that MN1 will think its
Registration
        Request has been denied by FA1. Although, MN1 will receive RRP1
later on, but
        it is too, late.

4. This only happens if there is no Security Association between MN1 and
FA1.

With this limitation in mind, I suggest this paragraph be replaced by the
following:
"
   Whenever a Foreign Agent updates a field of the Registration Reply
   (as suggested in section 3.3), it does not invalidate the authentication
   data supplied by the Home Agent in the Mobile-Home Authentication
   extension to the Registration Reply.  However, if there is no security 
   association between the mobile node and the Foreign Agent, a malicious
   node might try to supply a bogus Registration Reply to a mobile node 
   that causes the mobile node to act as if its Registration Reply has been 
   rejected by the Foreign Agent. This might happen when, in fact, a
Registration 
   Reply showing acceptance of the registration might soon be received by 
   the mobile node.
"

The original paragraph itself hint to a possible solution:
Ether the Mobile Node wait for a RRP message with the same ID as its RRQ
message
with a code generated by its Home Agent, or reissue a new RRQ message.

Regards,
Ahmad

---

From: "Fredrik Johansson" <[email-masked]>
Date: Fri, 27 Sep 2002 09:10:40 +0200

See comments inline
/fredrik

> I think this paragraph needs to be modified. It is somewhat confusing and
I am not sure
> if it is accurate.
> In section 3.3., the FA inserts the MN-FA Challenge extension which is
after the MN-HA
supplied by
Registration Reply.
the Foreign
> Agent, Only this scenario is vulnerable to bogus attack. More explanation
captured
here"
receives
Registration
later on, but
FA1.
Registration
message

It allways have to do this, at least the low-order 32 bits of the
identification field
From 3344 section 3.6.2.1

"In addition, the low-order 32 bits of the Identification field in the
   Registration Reply MUST be compared to the low-order 32 bits of the
   Identification field in the most recent Registration Request sent to
   the replying agent.  If they do not match, the Reply MUST be silently
   discarded."

But this doesn't prevent the attack you mention above.
/Fredrik