Subject: RE: Proposed changes to rfc3012bis [was: RE: [mobile-ip] RFC3012 -bis:compatibility issues]

From: "Ahmad Muhanna"<[email-masked]>
Date: Thu, 25 Apr 2002 09:02:42 -0500

Hello Charlie;

Please see my comments inline.

Regards;
Ahmad Muhanna

> 
> Hello Luca and Ahmad,
> 
> I guess it's about time to send out rfc3012bis if possible.
> 
> I think the text should be written to improve scalability,
> according your original observations, and yet maintain the
> most reasonable flexibility for mobile nodes.  I think we
> can mandate that mobile nodes MUST NOT use old challenges.
> On the other hand, I think we should encourage implementors
> to build CHALLENGE_WINDOW always at least 2.  That would
> eliminate many failures caused if a mobile node happens to
> use a challenge just after the foreign agent changed to a
> new challenge.
> 
> >    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
> >    not one of the recently advertised values, the foreign Agent SHOULD
> >    send a Registration Reply with Code value UNKNOWN_CHALLENGE (see
> >    section 10). <NEW-TEXT>The Foreign Agent SHOULD keep records for all
> >    challenges used by a Mobile Node that are still in the valid
> >    CHALLENGE_WINDOW. In the event that a Foreign Agent cannot keep
> >    records for all such previously used challenges, the Foreign Agent
> >    MUST set its CHALLENGE_WINDOW to 1.</NEW-TEXT>
> 
> I would replace the <NEW-TEXT> block as follows:
> 
>      The Foreign Agent MUST maintain the last challenge used by
>      each Mobile Node that has successfully registered using
>      any one of the last CHALLENGE_WINDOW challenge values.
>      This last challenge value can be stored as part of the
>      mobile node's registration records.
> 

I believe that the part of the <NEW TEXT> Luca proposed and I mentioned 
earlier is more than sufficient to eliminate any security threat. 
I still support that text as follows:

          <NEW TEXT> The Foreign Agent SHOULD keep records for all
          challenges used by a Mobile Node that are still in the valid
          CHALLENGE_WINDOW.<NEW TEXT>

Now how user would like to achieve this is up to the user himself. 
What about if some implementors want to choose a 
CHALLENGE_WINDOW of 3 or 1. It is OK. The standard offers flexible
way for the Mobile Node to get good CHALLENGES. 
If a CHALLENGE is used and is no longer valid MN will receive a 
Registration Reply with a valid CHALLENGE which can be used
or it can solicit.

> This uses the knowledge that mobile nodes MUST NOT use
> previous challenges.  To this end, I would add the following
> restriction at the end of section 4:
> 
>      Suppose the Mobile Node has successfully registered using one of
>      the Challenge Values within the CHALLENGE_WINDOW values advertised
>      by the Foreign Agent.  In that case, in any new Registration
>      Request the Mobile Node MUST NOT use any Challenge Value which was
>      advertised by the Foreign Agent before the Challenge Value in its
>      last successful Registration Request.
> 

No problem, BUT may I suggest a slight change here, We need to eliminate 
the successful concept here:

      Suppose the Mobile Node has used a Challenge Value of the 
      CHALLENGE_WINDOW values advertised by the Foreign Agent
      in its last Registration Request.  In that case, in any subsequent 
      Registration Request the Mobile Node MUST NOT use any 
      Challenge Value which was advertised by the Foreign Agent before 
      the Challenge Value in its last Registration Request.

> With these two mandates, the total storage required by the foreign
> agent for all Challenge Values amounts to (2N + CHALLENGE_WINDOW),
> where N is the number of mobile nodes currently being served by
> the Foreign Agent.  N of the stored values are for the "last
> challenge used", and the other N may have come from Registration
> Reply messages.  It shouldn't be any problem at all to have
> the CHALLENGE_WINDOW > 1 (i.e., >= 2).
> 
> The foreign agent can use the following algorithm:
> 
> current_chal := RegistrationRequest.challenge_extension_value
> last_chal := mobile_node_record.last_chal
> 
> if (current_chal == mobile_node_record.RegReply_challenge) {
> 	update (mobile_node_record, current_chal)
> 	return (OK)
> }
> else if (current_chal "among" VALID_CHALLENGES[]{
> 	if (last_chal "among" VALID_CHALLENGES[]) {
> 		if (current_chal is "before" last_chal) {
> 			send_error(INVALID_CHALLENGE)
> 			return (FAILURE)
> 		}
> 		else {
> 			update (mobile_node_record, current_chal)
> 			return (OK)
> 		}
> 	}
> 	else {
> 		update (mobile_node_record, current_chal)
> 		return (OK)
> 
> 	}
> }
> else {
> 	send_error(UNKNOWN_CHALLENGE);
> }
> 
> What this says, is that the challenge used by the Mobile Node
> has to either be the one in the previous Registration Reply, or it
> has to be in the set of valid challenges, but not one of the
> valid challenges which was advertised previous to the "last"
> challenge used by the mobile node.
> 
> If you like this algorithm, then I need to create a terminology
> for "invalid challenge" and an error message to go with it.
> If you _really_ like it, I can include it in an appendix, along
> with any bug fixes or revisions you may suggest.
> 

I am not sure if it is necessary to include this algorithm.

> Finally, regarding that sentence in the definition for "stale 
> challenge":
> 
> Ahmad Muhanna wrote:
> 
> >> --------------
> >> Page 2: Delete sentence.
> >>
> >>       stale challenge
> >>                Same as "previously used challenge".  The 
> Foreign Agent
> >>                may not be able to keep records for all stale
> >> challenges.
> >>
> >>
> >> Delete last sentence. Text becomes:
> >>
> >>       stale challenge
> >>                Same as "previously used challenge".
> >>
> >
> > I do not see why we need to remove this line. This 
> addresses all kinds of
> > stale challenges including those which are sent in the unicast
> > advertisement and the Registration Reply.  The most 
> important point, I do
> > not see any contradiction by leaving this line and your 
> proposed text below.
> > Basically, the below text allows what the deleted line 
> suggest BUT put
> > some restriction to avoid any security holes for one kind 
> of challenges.
> > 
> > What do you think?
> 
> How about if we put the sentence in question somewhere after the
> list of terms in section 1.1?  That way, at least the observation
> would not be construed to apply unequally between "stale challenge"
> and "previously used challenge".
> 

Well, this brings me back to the very old text I proposed and you did not
like.
What about replacing the stale challenge with the following:

stale challenge 
               
        Same as "previously used challenge" and the Foreign Agent still has
a record of.

> By the way, I guess up until now nobody mentioned that the
> following text in section 1.1 was an incomplete sentence:
> 
>    The following additional terminology
> 
> In fact, it looks like to me that the section is not finished,
> and that there always needed to be a definition for a "valid
> challenge".
> 

I think unused challenge is enough. The only thing which is not mentioned
but
explained in the text is the timestamp concept on the Challenge-Window 
challenges.

> 
> If this is good enough to close these issues, and if there are no
> other issues, I would like to send out rfc3012bis this week.
> I do not have any records about other issues that I can find.
> If this is O.K., then I think the revised draft will probably
> be ready for Last Call.
> 
> Regards,
> Charlie P.
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 25 Apr 2002 08:48:31 -0700

Hello Ahmad,

Thanks for your comments.  I hope this note will help to
finally resolve the remaining issues.

> Registration Reply with a valid CHALLENGE which can be used

O.K.  Then, would you be willing to propose two sentences for
inclusion in the Security Considerations that describe the
vulnerability when the Foreign Agent does NOT maintain sufficient
records?

Also, I am curious to find out if you think that (2*N + X) is too
much information for the foreign agent to maintain, or if you
think that it is more than (2*N + X).  Here, N == # of mobile_nodes
and X = CHALLENGE_WINDOW.

>> restriction at the end of section 4:
                    ..........
>                .............             We need to eliminate

Do you then suggest that the foreign agent SHOULD supply a
Challenge in the Registration Reply containing the rejection
indication?

>> The foreign agent can use the following algorithm:

                .......

> I am not sure if it is necessary to include this algorithm.

Well, if the algorithm is correct, then it seemed to me that
others might find it useful, who had not had the benefit of this
fairly extensive discussion.  But if you don't think so, or if
you think it is not useful for other reasons, I will keep it out
of the specification.

> Well, this brings me back to the very old text I proposed and you did not like. 
>         Same as "previously used challenge" and the Foreign Agent still has a
> record of.

This is fine with me.  I would reword it as:

 stale challenge
 
         A previously used challenge that is still identifiable
         as such by the Foreign Agent.

> I think unused challenge is enough. The only thing which is not mentioned but

Shall I define "valid challenge" to be the same as "unused challenge",
or alternatively change instances of "valid challenge" to be
"unused challenge" in the text?

Can you suggest what I need to do to fix the problem with the timestamp?

Regards,
Charlie P.