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

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 27 Sep 2002 09:26:32 -0500

Hi Fredrick,
Please see comments inline.
Regards;
Ahmad Muhanna

> See comments inline
> /fredrik
> 
> > please see comments inline.
> > Regards;
> > Ahmad Muhanna

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

Well, If the Mobile Node already received a RRPx message from the attacker,
I assume that the attacker used the correct ID in RRPx. This means that the
Mobile Node already received a RRP message with a matching ID for its RRQ1
message.

Usually, the Mobile Node will react in response to the attacker RRPx. 
Either build a new RRQ message (RRQ2) and send it again and now the MN
tracks the ID of RRP2 not RRP1. In other words, if the Mobile Node
receives RRP1, it will discard it.

However, if MN waits "?? How long??" after receiving a RRP message with
error code from the
FA to check if another RRP with the same ID is coming from the HA, it
probably counter
attack this scenario.

Also, I am not saying that this is the best solution either.

> But this doesn't prevent the attack you mention above.
> /Fredrik
> 
> > with a code generated by its Home Agent, or reissue a new 
> RRQ message. 
> > Regards, Ahmad
> 
>