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

[Pete McCann <mccap@lucent.com>]

Hi, Jayshree,

Jayshree Bharatia writes:
 > > 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.

Are you saying to include a challenge in every registration reply or
agent advertisement?  Well, that would be ok with me, but we got
pushback from Charlie on this.  I don't want to put words in his
mouth, so go back and re-read his posts from the archive.  I think he
felt that an always MUST was too strong, as there were conditions
where it could be left out.  We were trying to pin down those
conditions, which I think my suggested text does.

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

There is no way to guarantee that the challenge in the registration
request has anything to do with the stored state at the FA, unless
your clarification includes checking it against that stored state.
And why would you restrict the FA from sending other challenges in the
stored state, as long as they are previously unused?  Doesn't that
restrict implementation choice?

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


_______________________________________________
Mip4 mailing list
Mip4@ietf.org
https://www.ietf.org/mailman/listinfo/mip4