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:07:29 -0500

Hello Luca;
Excellent.

I think it is great and I agree with the text.
However, please see the comment below.

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

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

Perfect!!
I agree.

> 
> What do you think?
> 
> Luca
> 
> On Mon, 2002-04-08 at 17:27, Ahmad Muhanna wrote:
> > 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
> 
> 
>