 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
Hi Pete,
Please see the response inline.
Thanks,
Jayshree
> -----Original Message-----
> From: Pete McCann [mailto:mccap@lucent.com]
> Sent: Wednesday, September 03, 2003 5:03 PM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: 'mip4@ietf.org'
> Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5
>
>
>
> Hi, Jayshree,
>
> Jayshree Bharatia writes:
> [...]
> > > > [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.
> > >
> > > 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?
> > [JB] Not sure how much we can rely on the assumption of FA
> regarding > receiving the challenge at the mobile node since
> there is no guarantee on > the timing on when the MN may
> receive unsolicited multicast advertisement.
>
> I would be fine if we deleted the one sentence "The Foreign
> Agent could then assume..." from the above (it has no
> normative value anyway).
>
[JB] I rather have just "MUST" instead of "SHOULD" in the current text without any further conditional text if it solves all your concerns.
[...]
>
> > > > > > 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. > >
> > > I think it is important to emphasize that the FA is not
> > > allocating additional storage.
> > [JB] My point is, if the challenge is "previously unused
> challenge", it is > implicit that the storage is already existed.
>
> Not necessarily - one possible interpretation of your
> suggested text is for a new "previously unused" challenge to
> be created.
>
[JB] In the current context, I would think that repeating the challenge (used in the Registration Request which failed authentication) is more appropriate since this challenge is still "previously unused challenge". Hence, it is safe to assume that storage already exists in this case. I think we need to clarify "repetition of challenge" more clearly in the proposed text.
> > Anyway, this is implementation specific also.
>
> Yes, as is all of Appendix E, which is an example of what
> kind of data structures/pseudocode might be used. Handing
> out an "already stored, previously unused" challenge is a way
> to meet the security requirements. If we change the text to
> say only "previously unused" then we open the door to the
> creation of new challenges, with the possibility of
> invalidating old ones given the data structure and pseudocode
> in Appendix E. For that reason, it is important to say
> explicitly that the "previously used" challenge is also
> "already stored."
>
> -Pete
>
>