Subject: RE: [mobile-ip] RFC3012-bis: compatibility issues

From: "Ahmad Muhanna"<[email-masked]>
Date: Mon, 8 Apr 2002 16:27:09 -0500

Hello Luca;

> Luca Salgarelli wrote:
> 
>    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>
> 

I think we at least need to apply Charlie suggestion as per Luca text.
I have no problem with this text.

Thanks;
Ahmad

---

From: Luca Salgarelli <[email-masked]>
Date: 09 Apr 2002 11:39:29 -0400

Hello Charlie and Ahmad.

After the discussion with Ahmad, and some more thinking on my part, I
still think that what's now in rfc3012bis is prone to leaving security
holes open. 

However, I do agree with Ahmad that *maybe* this should be just left to
implementors, and we should not impose a strict limit to which
challenges in challenge-window are valid as Charlie suggested.

So what I would suggest is that we modify the text in rfc3012bis as
follows, so that implementors can decide what to do about this problem,
but we are at least sure that no security holes are left open.

What do you think of the following changes:

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

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

What do you think?

Luca

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 09 Apr 2002 08:52:06 -0700

Hello Luca,

I haven't reviewed every one of the e-mails on this subject, but
I do have some comments on the proposed text:

> What do you think of the following changes:

This is fine.

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

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.  So, I would

>>>    Registration Reply with code value STALE_CHALLENGE. </NEW TEXT>

Regards,
Charlie P.

---

From: Luca Salgarelli <[email-masked]>
Date: 09 Apr 2002 12:13:34 -0400

Hello Charlie.

Please see comments inline.

I agree. But:

> 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

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 23 Apr 2002 15:56:49 -0700

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.

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

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.

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.

Finally, regarding that sentence in the definition for "stale challenge":

Ahmad Muhanna wrote:

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

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

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.