Subject: Re: [MOBILE-IP] Challenge/Response

From: Woo-June Kim <[email-masked]>
Date: Tue, 19 Dec 2000 09:58:53 +0900

Hi,

Here's my 2 cents...

>1) There seems to be some inconsistency in different sections of the RFC,
>see below for each section.
>    and by the way what's the meaning of sending a new Challenge extension
>in a non successful registration reply if it can not be accepted by the
>foreign agent?
>

One case that I can think of, would be for cases such as when the user gets a STALE_CHALLENGE reply. The user should be notified of a new challenge value to use, that sending it as an extension would be one way. 

Other cases would be the MISSING_CHALLENGE case and the UNKNOWN_CHALLENGE case. 

I am not sure about what you mean by the inconsistency below. Could you elaborate ? (I agree the wording seems to be a bit ambiguous in places.)

>Section 3.1
>"A successful Registration Reply from the Foreign Agent MAY include
>   a new Challenge value (see section 3.3).  The Mobile Node MAY use
>   either the value found in the latest Advertisement, or the one found
>   in the last Registration Reply from the Foreign Agent.  This approach
>   enables the Mobile Node to make use of the challenge without having
>   to wait for advertisements."
>
>Section 3.2
>"The Foreign Agent MUST NOT accept any Challenge in the Registration
>   Request unless it was offered in last successful 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."
>
>Section 3.3
>"The Foreign Agent MAY include a new Challenge extension in any
>   Registration Reply, successful or not."
>
>2) Say that a foreign agent allow for a Challenge window of 3, i.e. it will
>allow registrations to pass which contain one of the last three challenges
>that were sent out from the foreign agent. That means that the foreign agent
>need to save the last three challenges it sent on that interface. It also
>need to store the challenge it receives in registration request in order to
>prevent a mobile to use the same challenge twice. This means at least
>one/mobile that tries to register. If the foreign agent also chose to send a
>Challenge in the registration reply to a mobile, it has to store one extra
>Challenge / mobile it sends a reg reply to. Is it reasonable that a foreign
>agent should store and process that many challenges?
>

I think it depends on how you understand the above statement. 

The FA has to keep the challenge values that had been sent out in the previous CHALLENGE_WINDOW agent advertisements.

The FA has to keep N_stale challenge / mobile, containing the previous challenge that had been used by the mobile in its last N_stale successful RRQ . The number N_stale will depend on how the STALE_CHALLENGE will be configured. My understanding is that N_stale = 1 should be enough. (All other cases can be taken care of as UNKNOWN_CHALLENGE)

The FA has to keep the last challenge sent out in the RRP to the MN.While it is possible to use separate challenges for each user, I do not think the RFC requires that this must be the case. i.e. The FA may use a single challenge for all MNs. In such a case this would most likely result in one more challenge value that has to be kept globally in the FA.

I think this is more in keeping with the original philosophy of using the (multicast) Agent Advertisements for the initial challenge value announcement. 

So to wrap up, it seems the FA needs to keep CHALLENGE_WINDOW + 1 challenge values globally, and N_stale (probably 1) challenge per MN (which can be kept with the visitor list database).

This is probably what Kory Keith meant below in his short reply. Sorry for my verbous explanation if you already understood from Kory's message.

Kory Keith's reply :
"....
I understand section 3.2 to say that the FA needs to
store (CHALLENGE_WINDOW + 1) challenges to protect
against unknown challenges, but it does not define how
many to store to protect against STALE_CHALLENGE (sec.
3.2 previous paragraph).
..."

cheers

Woojune Kim

---

From: Fredrik Johansson <[email-masked]>
Date: Tue, 19 Dec 2000 10:36:36 +0100

Hi,
thanks for the reply.

What I mean by inconsistency is that,

in paragraph 3.1 it is stated that "A successful Registration Reply from the
Foreign Agent MAY include a new Challenge value ..."

in paragraph 3.2 it is stated that "The Foreign Agent MUST NOT accept any
Challenge in the Registration Request unless it was offered in last
successful Registration Reply..."

and in paragraph 3.3 it is stated that "The Foreign Agent MAY include a new
Challenge extension in any Registration Reply, successful or not."

I.e. A FA may send a new Challenge in any registration reply, but it will
only accept registrations containing challenges sent in successful
registration replies.

So what is the meaning of sending new Challenges in unsuccessful
registration replies?

Another problem that is caused by this is that when a MN register for the
first time, its timestamp will most likley be wrong, so the HA will deny the
registration. Now the MN has to wait for it to receive another challenge
before it can register again.

Regarding the number of challenges you need to keep, I believe that it will
be more than CHALLENGE_WINDOW + 1 since you have to keep the challenge sent
in a registration reply until the time for the registration expires or a new
registration reply is sent. I agree that sending the same challenge to all
MNs might reduce the number of challenges that are necessary to save.
However, it is still more than CHALLENGE_WINDOW + 1.

Say that you your CHALLENGE_WINDOW = 3
you send Challenge C1, C2 and C3 as broadcast in advertisments
you also have a Challenge C4 that are sent to mobiles in registration
replies

MN_A and MN_B both register and receive C4 in the RRP, now you have stored
C1, C2, C3 and C4
after a while MN_B re-register using C4, in the RRP you now send a new
challenge C5. You now have to save C1, C2, C3, C4, C5 since MN_A can still
use C4. Thus, I don't agree that CHALLENGE_WINDOW + 1 is enough. This number
will increase for every MN that re-register. C4 can not be removed until all
MNs that have recieved it in a RRP has re-registed or their registration has
expired.

/Fredrik
>One case that I can think of, would be for cases such as when the
>user gets a STALE_CHALLENGE reply. The user should be notified of
>a new challenge value to use, that sending it as an extension
>would be one way.
>
>I am not sure about what you mean by the inconsistency below.
>Could you elaborate ? (I agree the wording seems to be a bit
>ambiguous in places.)
>
>>Section 3.1
>The FA has to keep the challenge values that had been sent out in
>the previous CHALLENGE_WINDOW agent advertisements.
>
>The FA has to keep N_stale challenge / mobile, containing the
>previous challenge that had been used by the mobile in its last
>N_stale successful RRQ . The number N_stale will depend on how the
>STALE_CHALLENGE will be configured. My understanding is that
>N_stale = 1 should be enough. (All other cases can be taken care
>of as UNKNOWN_CHALLENGE)
>
>The FA has to keep the last challenge sent out in the RRP to the
>MN.While it is possible to use separate challenges for each user,
>I do not think the RFC requires that this must be the case. i.e.
>The FA may use a single challenge for all MNs. In such a case this
>would most likely result in one more challenge value that has to
>be kept globally in the FA.
>
>I think this is more in keeping with the original philosophy of
>using the (multicast) Agent Advertisements for the initial
>challenge value announcement.
>
>So to wrap up, it seems the FA needs to keep CHALLENGE_WINDOW + 1
>challenge values globally, and N_stale (probably 1) challenge per
>MN (which can be kept with the visitor list database).
>
>This is probably what Kory Keith meant below in his short reply.
>Sorry for my verbous explanation if you already understood from
>Kory's message.
>
>Kory Keith's reply :
>"....