Subject: [mobile-ip] RFC3012bis - Comments from ADs (Protocol related)

From: [email-masked]
Date: Thu, 26 Sep 2002 06:15:28 -0500

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.

Non-editorial:
1. The protocol seems to be suject to bogus registration replies.

2. Section 3.1:
   Whenever the Agent Advertisement contains the Challenge extension, if
   the mobile node does not have a security association with the Foreign
   Agent, then it MUST include the Challenge value in a Mobile-Foreign
   Challenge extension to the Registration Request message.  If, on
   the other hand, the mobile node does have a security association
   with the foreign agent, it SHOULD include the Challenge value in its
   Registration Request message.

   Why the "SHOULD"? What breaks if it doesn't include it?
   One would naively assume that it is has a MN-FA SA that there is
   no need for the challenge.

3. Section 3.1 doesn't specify what the MN should do when it receives
   a STALE_CHALLENGE. 
   It also doesn't specify whether the MN should extract a new
   challenge value from a registration reply which has an error in it.

4. If there are multiple FAs on the visited link, is the assumption
   that the MN needs to track which FAs have issued which challenge?
   If so it would make sense to make this clear.

5. Section 3.2
   "attempting to replay a previous advertisement and authentication.  If
   the challenge extension is needed and does not exist, the Foreign"
   What does "needed" mean here? That the FA has a policy knob whether
   or not it is needed? Or something else?

6. The section doesn't talk about what happens when the reply is
   lost between the FA and MN.

7. The Foreign Agent MUST NOT accept any Challenge in the Registration
   Request unless it was offered in last Registration Reply issued
   to the Mobile Node, or else advertised as one of the last
   CHALLENGE_WINDOW (see section 9) Challenge values inserted into the
   immediately preceding Agent advertisements.  If the Challenge is

   This seems suboptimal. If the reply is lost between the FA and MN
   then the MN can't send a new request until it has received a new
   agent advertisement.  Why not have the "keep N+1 challege values"
   apply to the values sent in both advertisements and replies? 

8. "   pending registration request list [7].  Also in this case, the
   Foreign Agent MUST reject any Registration Reply message coming from
   the Home Agent that does not also include the Challenge Extension
   with the same Challenge Value that was included in the Registration
   Request.  The Foreign Agent MUST send the rejected Registration"
   
   This MUST seems to imply that a FA implementing this specification
   is not allowed to interoperate with a HA which does not implement
   this specification. Did I get that right?

9. It seems odd that the Mobile-Foreign challenge is carried between
   the FA and HA. In fact, its use there seems to be different in that
   it seems to be a cookie used to reject bogus registration replies
   from the HA. This odd use then results in having the FA be required
   to replace the challenge it receives from the HA as specified in
   3.3. If there is need for a cookie/challenge between FA and HA,
   that seems to be completely separate from the MN-FA challenge.

10. Section 3.4

    The section doesn't specify what checks the HA does on the received
    registration request; it just specifies what it needs to put in
    the reply. 

11.    Since the extension type for the Challenge extension is within the
   range 128-255, the Home Agent MUST process such a Registration
   Request even if it does not recognize the Challenge extension [7].
   In this case, the Home Agent will send a Registration Reply to the
   Foreign Agent that does not include the Challenge extension.

   I fail to see the utility of sending a reply back without a challenge 
   since the FA is required to reject the reply.

12. Section 5 introduces a subtype but there is no IANA considerations
    mention of this and the rules for assigning new subtype values.

13. Section 8
    The concatentation of fields for MD5 include "length" and "SPI"
    but it isn't clear to me how many bits of length and SPI are fed
    in since these two fields are not fields in the protocol itself as
    I understand it.

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.

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

15.    Section 8 (SPI For RADIUS AAA Servers) defines a method of computing
   the Generalized Mobile IP Authentication Extension's authenticator
   field using MD5 in a manner that is consistent with RADIUS [9].  The
   use of MD5 in the method described in Section 8 is less secure than
   HMAC-MD5 [6], and should be avoided whenever possible.

   How can it be avoided?
   There doesn't seem to be a CHAP_SPI_HMAC_MD5 defined.

16.    -  Foreign agent recommended to include a Challenge in every
       Registration Reply, so that mobile node can re-register without
       waiting for an Advertisement.
       With the side effect of opening up a security hole - bogus
       registration replies must be accepted by the MN.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 26 Sep 2002 10:17:04 -0500

Please see comments inline.

Regards;
Ahmad Muhanna

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

-Chairs.

RFC3344 (3220, 2002) does not talk about it either.

Regards,
Ahmad

---

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

please see my comments inline.

Regards;
Ahmad Muhanna

-Chairs.

Agreed.
I wonder how this passed in the first time (RFC3012).

Regards,
Ahmad