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

From: "Ahmad Muhanna"<[email-masked]>
Date: Tue, 9 Apr 2002 11:28:40 -0500

Hello Charlie and Luca;

I am sorry for my earlier email. I did send it before reading Charlie
comments.
I although agree with Charlie about deleting the last sentence of the
proposed
text by Luca.

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

I believe including the above text alone is what we need. This is good to
prevent
any security holes. 
Now: implementors are free to comply with this restriction the way they find
fit.

My previous comments is still valid for keeping the following text intact.
	
      stale challenge
               Same as "previously used challenge".  The Foreign Agent
               may not be able to keep records for all stale challenges.

What do you think?

Ahmad

> 
> 
> Hello Charlie.
> 
> Please see comments inline.
> 
> > > Page 6: Add new text.
> > >    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 MUST 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>
> > 
> > This says that the foreign agent MUST do something.  And 
> then it says
> > that if the foreign agent cannot do that thing, it MUST do something
> > else.
> > 
> > I prefer that the wording say exactly what the foreign 
> agent MUST do.
> > The mandate can be conditional, but we should not include language
> > that describes what is to be done if a mandate is not met.  That's
> > contradictory, and opens up to question what is to be done if other
> > mandates are not met.
> 
> I agree. But:
> 
> > If mandates are not met, there is no repair.  The 
> implementation just
> > is not compliant.
> > 
> > In this case, I think the last sentence should be deleted.  
> In subsequent
> > text, it can be explained that setting CHALLENGE_WINDOW to 
> 1 makes it
> > easier to keep track of all "relevant" challenges.  However, I would
> > prefer that the window be typically set to at least 2 (not 
> 1), because
> > that will allow for much "better" protocol operation.
> > 
> > Lastly, I don't think it is so bad to use the ordering property in
> > order to limit storage requirements, but here is where I should go
> > read the past e-mails to figure out all the issues. 
> 
> The issue Ahmad brought up, and that made me think more, is 
> that we are
> not sure that somebody will not find a way of keeping track of all the
> relevant challenges in a scalable way, so this should be 
> really left to
> implementors.
> 
> In addition, re-thinking about the implementation of your suggested
> mechanism, I think it could become relatively expensive as well, since
> its computational complexity grows with increasing 
> CHALLENGE_WINDOW. And
> the problem is that the text I originally proposed would mandate that
> for everybody.
> 
> How about this variant of my 2nd text:
> 
>     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>
> 
> Again, this would leave the door open to implementors to decide which
> road they want to take, without limiting everybody to put a 
> limit on the
> order in which clients have to use challenges.
> 
> Luca
> 
> > So, I would
> > actually prefer this previous version:
> > 
> > >>>    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
> > >>>    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> In addition, if the 
> Challenge is one of
> > >>>    the recently advertised values, but was issued 
> before a Challenge
> > >>>    already used by the Mobile Node, the Foreign Agent 
> SHOULD send a
> > >>>    Registration Reply with code value STALE_CHALLENGE. 
> </NEW TEXT>
> > 
> > Regards,
> > Charlie P.
> 
>

---

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

Hello Charlie;

Please see my comments inline.
I reposting this. It seems the first one did not go through.

Regards;
Ahmad Muhanna

> 
> Hello Luca and Ahmad,
> 
> I guess it's about time to send out rfc3012bis if possible.
> 
> 
> 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).
> 

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