Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5

From: "Jayshree Bharatia" <[email-masked]>
Date: Wed, 3 Sep 2003 10:26:06 -0500

Hi Pete,

Please see my comments inline.

Regards,
Jayshree

> -----Original Message-----
> From: Pete McCann [mailto:[email-masked]] 
> Sent: Friday, August 29, 2003 11:56 AM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: [email-masked]'
> Subject: [Mip4] RFC3012bis: Proposal for Issue2-Change5
> 
> 
> 
> Hi, Jayshree,
> 
> I am reorganizing all the text proposals into this one note 
> for easier reference.  See comments below, and let me know if 
> I missed one of your notes.
> 
> 
> [note chair hat is off for the remainder of this message]
> 
> 
>  > The current proposal for issue 1 is to use "previously 
> unused challenge" in  > section 2 for all multicast and 
> unicast Agent Advertisements. 
> 
> I am not sure what you mean by this.  Can you give a specific 
> text proposal, and a location for it in the draft?
> 
[JB] Proposed text for section 2.
From:
The Challenge extension, illustrated in figure 1, is inserted in the Agent
Advertisements by the Foreign Agent, in order to communicate the latest
challenge value that can be used by the mobile node to compute an
authentication for its next registration request message.  The challenge is
selected by the foreign agent to provide local assurance that the mobile
node is not replaying any earlier registration request.  

To:
The Challenge extension, illustrated in figure 1, is inserted in the Agent
Advertisements by the Foreign Agent, in order to communicate a previously
unused challenge value that can be used by the mobile node to compute an
authentication for its next registration request message.  The challenge is
selected by the foreign agent to provide local assurance that the mobile
node is not replaying any earlier registration request.  

>  > In addition to this, Henrik proposed a new text for a new 
> subsection 2.1. 
>  > 
>  > 2.1 Handling of Solicited Agent Advertisements
>  >
>  > When a foreign agent generates an Agent Advertisement in 
> response to a  > Router Solicitation [4], some additional 
> considerations come into play.  > According to the Mobile IP 
> base specification [7], the resulting Agent  > Advertisement 
> may be either multicast or unicast.  > 
>  > If the solicited Agent Advertisement is multicast, it MUST 
> NOT generate a  > new Challenge value and update its window 
> of remembered advertised  > Challenges. It must instead 
> re-use the most recent of the CHALLENGE_WINDOW  > 
> Advertisement Challenge values.  > 
>  > If the agent advertisement is unicast back to the 
> soliciting mobile node  > MUST be handled as follows: If the 
> challenge most recently unicast to the
>   ^ insert the word "it"
> 
>  > soliciting mobile node has not been previously used (as 
> defined in Section  > 1.1), in SHOULD  > be repeated in the 
> newly issued unicast agent advertisement, otherwise a new  > 
> challenge MUST be generated and remembered as the most recent 
> challenge  > issued to the mobile node. (For further 
> discussion of this, see Section 12.)
> 
> I agree with this so far.
> 
>  > A foreign agent SHOULD NOT respond arbitrarily often to 
> agent solicitations,  > in order to limit processing load, 
> especially in the face of hostile nodes  > soliciting at a 
> very high rate. The rate of solicited agent advertisement  > 
> responses SHOULD at most be 50 per second.
> 
> I am not sure we need the last paragraph.  Overload control, 
> especially the choice of which solicitations to discard, is a 
> tricky subject.  I don't know that we will come to any 
> agreement on a maximum rate (cf. previous discussions on the 
> Mobile IP list regarding multicast agent advertisement rates).
> 
> 
>  > The original proposal from Henrik was to mandate a 
> challenge in a  > Registration Reply. After few email 
> exchanges, it was decided that the  > current text in section 
> 3.3 (RFC3012bis (version 05) ) is ok. In addition to  > the 
> current text, Henrik proposed the following text to be used 
> as a  > guidance/background:  > 
>  > (section 3.3)
>  > One example of a situation where the Foreign Agent MAY 
> omit the inclusion of  > a Mobile-Foreign Challenge Extension 
> in the Registration Reply would be when  > a new challenge 
> has been multicast recently. The Foreign Agent could then  > 
> assume that the mobile node with high likelihood has received 
> and can use  > the multicast challenge. A mobile node MUST be 
> prepared to use a multicast  > challenge in lieu of one 
> returned in a Registration Reply, and MUST solicit  > for one 
> if it has not already received one in a Registration Reply or 
> Agent  > Advertisement.
> 
> This is good, but it doesn't seem quite strong enough, i.e., 
> we still have a SHOULD on the inclusion of the previously 
> unused challenge.  It seems to me we should require (with a 
> MUST) the inclusion of a challenge in the registration reply 
> if something like the condition above isn't met, and 
> similarly should require (with a MUST) the inclusion of a 
> challenge in responses to Agent Solicitations if the 
> condition isn't met.  This is the only way to guarantee 
> progress on a link where advertisements may be lost and where 
> there is a long interval between unsolicited advertisements.
> 
> 
[JB] This is the mechanism where the FA provides an unused challenge to the
MN so that the MN can use this challenge in the subsequent request. If
advertisements are lost or their interval is long enough, the MN can always
request a challenge by sending Agent Solicitation. I would think that this
type of guideline adds more confusion. By the way, the current text in
section 3.3 is: "The Foreign Agent SHOULD include a new Mobile-Foreign
Challenge Extension in any Registration Reply, successful or not. "

I like to see use of term "previously unused challenge" instead of "new".
> 
>  > The current proposal from Pete is to reuse the challenge 
> in the Registration  > Reply of the Registration Request for 
> which the authentication fails at the  > FA. This challenge 
> sent in the Registration reply will be same as the  > 
> challenge received in the Registration Request for which the 
> reply is sent.  > 
>  > To reflect this point, the following changes are proposed 
> by Jayshree:  > 
>  > (change 2.1-Section 3.2)
>  > From:
>  > If the registration message contains a Mobile-Foreign 
> Authentication  > extension with an incorrect authenticator 
> that fails verification, the  > Foreign Agent MAY send a 
> Registration Reply to the mobile node with Code  > value 
> BAD_AUTHENTICATION (see Section 10). 
>  > 
>  > To: (Added last statement) 
>  > If the registration message contains a Mobile-Foreign 
> Authentication  > extension with an incorrect authenticator 
> that fails verification, the  > Foreign Agent MAY send a 
> Registration Reply to the mobile node with Code  > value 
> BAD_AUTHENTICATION (see Section 10). In this case, if  the 
> Mobile Node  > is currently registered, the challenge 
> included in the  Registration Reply  > by the Foreign Agent 
> MUST be the same as the one received in the  > Registration 
> Request.  >  >  > (change 2.2-Section 3.2)  > From:  > If the 
> registration message contains a Mobile-AAA Authentication 
> extension  > with an incorrect authenticator that fails 
> verification, the Foreign Agent  > MAY send a Registration 
> Reply to the mobile node with Code value  > 
> BAD_AAA_AUTHENTICATION_SET_BY_FA. 
>  > 
>  > To: (Added last statement)
>  > If the registration message contains a Mobile-AAA 
> Authentication extension  > with an incorrect authenticator 
> that fails verification, the Foreign Agent  > MAY send a 
> Registration Reply to the mobile node with Code value  > 
> BAD_AAA_AUTHENTICATION_SET_BY_FA. In this case, if  the 
> Mobile Node is  > currently registered, the challenge 
> included in the Registration Reply by  > the Foreign Agent 
> MUST be the same as the one received in the Registration  > 
> Request.  > 
>  > (change 2.3-Section 3.5)
>  > From:
>  > BAD_AAA_AUTHENTICATION_SET_BY_FA: This error is sent by 
> the Foreign Agent if  > the Registration Request contains a 
> Mobile-AAA Authentication extension with  > an incorrect 
> authenticator that fails verification.  A Mobile Node that  > 
> receives a  > BAD_AAA_AUTHENTICATION_SET_BY_FA MUST use a new 
> Challenge value in any new  > registration, obtained either 
> from an Agent Advertisement, or from a  > Challenge extension 
> to the Registration Reply containing the error.  > 
>  > To: (Replaced "new Challenge" to "Challenge")
>  > BAD_AAA_AUTHENTICATION_SET_BY_FA: This error is sent by 
> the Foreign Agent if  > the Registration Request contains a 
> Mobile-AAA Authentication extension with  > an incorrect 
> authenticator that fails verification.  A Mobile Node that  > 
> receives a  > BAD_AAA_AUTHENTICATION_SET_BY_FA MUST use a 
> Challenge value in any new  > registration, obtained either 
> from an Agent Advertisement, or from a  > Challenge extension 
> to the Registration Reply containing the error.
> 
> I don't support the text changes above, although I may have 
> proposed the principle of "repeating challenges."  Perhaps we 
> don't need to make any text changes in this section, but can 
> confine the new text to the security considerations (see my 
> proposal below).
> 
> 
[JB] I don't have any problem removing these changes. The proposed text does
what was intended and that is, allowing repetition of challenges when
authentication fails. 

>  > This change further extends point mentioned in change 1 
> for issue 2. The  > proposal from Henrik was to clarify the 
> use of challenge. This text is  > intended as a new paragraph 
> in section 3.3. 
>  > 
>  > "If the challenge most recently issued to the soliciting 
> mobile node has not  > been previously used (as defined in 
> Section 1.1), the most recent challenge  > unicast to the 
> mobile node through a registration reply or a unicast agent  
> > advertisement SHOULD be repeated in the registration reply."  > 
>  > This proposal was further modified by Pete differentiating 
> the processing at  > the FA for the registered and 
> unregistered users:  > 
>  > "When responding to an unregistered MN with an 
> unsuccessful Registration  > Reply, the FA SHOULD include the 
> same challenge that was last included in a  > multicast Agent 
> Advertisement.  When responding to a registered MN with a  > 
> successful or unsuccessful Registration Reply, the FA SHOULD 
> include the  > same challenge that was last included in a 
> multicast Agent Advertisement,  > when that challenge is 
> previously unused by the MN.  Otherwise, the FA  > SHOULD 
> include the same challenge that was previously unicast to the 
> MN in a  > Registration Reply or Agent Advertisement, unless 
> that challenge was  > previously used.  In that case, the FA 
> SHOULD create a new challenge and  > return it to the MN, 
> storing a copy of it with the visitor list entry for  > that MN."
> 
> Based on the subsequent discussion, I don't think we need the 
> text changes above.  See the security considerations:
> 
> 
[JB]OK

>  > The following text was proposed to be added in section 12. 
> This is a  > modified version of the text proposed by Henrik 
> on the mailing list earlier.  > 
>  > (section 12)
>  > Note that an active attacker may try to prevent successful 
> registrations by  > sending a large number of Agent 
> Solicitations or bogus Registration  > Requests, each of 
> which could cause the FA to respond with a fresh  > 
> challenge, invalidating the challenge that the MN is 
> currently trying to  > use.  To prevent such attacks, the FA 
> SHOULD repeat the same challenge value  > in successive 
> unicast responses to Agent Solicitations or in Registration  
> > Replies to Requests that did not contain valid MN-AAA or 
> MN-FA  > authentication extensions.  Note that each challenge 
> returned to an MN MUST  > be previously unused by that MN.
> 
> Based on subsequent comments from Ahmad, maybe we can make 
> the requirement more generic here, and give a specific 
> example in Appendix E.  For here, how about:
> 
> Note that an active attacker may try to prevent successful 
> registrations by sending a large number of Agent 
> Solicitations or bogus Registration Requests, each of which 
> could cause the FA to respond with a fresh challenge, 
> invalidating the challenge that the MN is currently trying to 
> use.  To prevent such attacks, the FA MUST NOT invalidate 
> previously unused challenges when responding to 
> unauthenticated Registration Requests or Agent Solicitations. 
>  In addition, the FA MUST NOT allocate new storage when 
> responding to such messages, because this would also create 
> the possibility of denial of service.
> 
[JB] Can we explicitly write "new challenge" instead of "new storage"?
> 
> 
> 
>  > It was decided that challenges sent in unicast Agent 
> Advertisements and sent  > in Registration Reply messages 
> should be treated same at the FA. For this,  > the following 
> text is proposed by Henrik and Pete:  > 
>  > (change 5.1-Section 3.2)
>  > From:
>  > 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.  > 
>  > To:
>  > The Foreign Agent MUST NOT accept any Challenge in the 
> Registration Request  > unless it was offered in the last 
> Registration Reply or unicast Agent  > Advertisement sent 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.  > 
>  > (change 5.2-Appendix E)
>  > From:
>  > In the program fragment, it is presumed that the foreign 
> agent keeps an  > array of advertised Challenges 
> ("VALID_ADV_CHALLENGES"), a record of the  > last advertised 
> challenge used by a mobile node, and  > also a record of the 
> last challenge provided to a mobile node in a  > Registration 
> Reply.  > 
>  > To:
>  > In the program fragment, it is presumed that the foreign 
> agent keeps an  > array of advertised Challenges 
> ("VALID_ADV_CHALLENGES"), a record of the  > last advertised 
> challenge used by a mobile node, and also a record of the  > 
> last challenge provided to a mobile node in a Registration 
> Reply or unicast  > Agent Advertisement.
> 
> After that, we could add, "To meet the security obligations 
> outlined in Section 12, the FA SHOULD use one of the already 
> stored, previously unused challenges when responding to an 
> unauthenticated Registration Request or Agent Solicitation."
> 
[JB] I would think that "already stored" is redundant here.
> -Pete

---

From: Pete McCann <[email-masked]>
Date: Wed, 3 Sep 2003 11:20:36 -0500

Hi, Jayshree,

Jayshree Bharatia writes:
[...]
 > node is not replaying any earlier registration request.  

Ok, looks good.

 > request a challenge by sending Agent Solicitation.

But then we need to mandate that a previously unused challenge will
appear in the solicited Agent Advertisement, unless an unsolicited
advertisement with a challenge is sent immediately before or after.
This is the only way to guarantee progress.

How about this for a specific text proposal:

   The FA MUST include a previously unused challenge in each
   Registration Reply or solicited Agent Advertisement, unless an
   unsolicited multicast advertisement containing a previously unused
   challenge is sent immediately before or after (e.g., within 1
   second of) the Reply or solicited Advertisement.  The Foreign Agent
   could then assume that the mobile node with high likelihood has
   received and can use the multicast challenge.  A mobile node MUST be
   prepared to use a multicast challenge in lieu of one returned in a
   Registration Reply, and MUST solicit for one if it has not already
   received one in a Registration Reply or Agent Advertisement.

[Henrik, I also saw your text proposal on this, but I think it may be
a bit too wordy.]

 > I would think that this
 > type of guideline adds more confusion.

What do you think of the text above?

 > By the way, the current text in

Makes sense.

[...]
 > what was intended and that is, allowing repetition of challenges when

Agreed.

[...]
 > [JB] Can we explicitly write "new challenge" instead of "new storage"?

Well, it is really the storage allocation that leads to a depletion of
resources at the FA.  I was trying to allow for super-smart
implementations that perhaps could figure out some way to allocate new
challenges without allocating new storage (perhaps some sort of
embedded cookie mechanism).  I thought this was the implementation
flexibility that you and Ahmad were asking for.

 > [JB] I would think that "already stored" is redundant here.

I think it is important to emphasize that the FA is not allocating
additional storage.

-Pete

_______________________________________________
Mip4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip4