Subject: RE: [mobile-ip] Comments on 3012bis

From: Pete McCann <[email-masked]>
Date: Tue, 1 Jul 2003 10:34:12 -0500

Hi, Jayshree,

See below.

Jayshree Bharatia writes:
 > Please see my response below:
 > 
 > > -----Original Message-----
 > > From: Pete McCann [mailto:[email-masked]]
 > > Sent: Tuesday, June 24, 2003 5:17 PM
 > > To: [email-masked]
 > > Cc: [email-masked]; [email-masked]
 > > Subject: [mobile-ip] Comments on 3012bis
 > > 
 > > 
 > > Hi, Raj,
 > > 
 > > Here are my comments on 3012-bis.
 > > 
 > > -Pete
 > > 
 > > 
 > > In the abstract:
 > > Propose adding the following sentence at the end:
 > >    This document updates RFC 3344.
 > > [to allow more than one authorization enabling extension to
 > > appear in  a registration request, 
 > [JB]I think it's better to correct this issue in RFC3344 rather than putting
 > text in RFC3012bis. But I am open to other suggestions WG may have on how to
 > resolve this issue.

I believe the document already implicitly allows this.  For example,
see the following paragraph in Section 3.1:

   In either case, the Mobile-Foreign Challenge extension followed by
   one of the above specified authentication extensions MUST follow the
   Mobile-Home Authentication extension, if present.

My point was simply to make this explicit with the "updates" wording
in the abstract, and perhaps one line of text in the body somewhere.

 > > and to allow the MN-AAA 
 > > NOT to be stripped out  by the FA even if it follows MN-HA.] 
 > > [add the text in brackets somewhere in the body if necessary]
 > [JB] I am not sure I understanding your point. Can you clarify this further?

I believe RFC 3344 requires the FA to strip out and process all
extensions following MN-HA.  I believe the current 3012bis allows the
FA to leave the MN-AAA extension in place, even when MN-HA is
present.  I think we should make this explicit.

 > >       stale challenge
 > >                Any challenge that has been used by the mobile node in
 > >                a Registration Request message and processed by the
 > >                Foreign Agent by relaying or generating a corresponding
 > >                Registration Reply message.  The Foreign Agent 
 > > may not be
 > >                able to keep records for all previously used 
 > > challenges,
 > >                but see section 3.2 for minimal requirements.
 > > 
 > > This definition seems incorrect according to the text in 
 > > section 3.2: a challenge is not stale until the Registration 
 > > Reply message has been sent to the MS.  In any case, this 
 > > term does not seem to be used anywhere in the document (only 
 > > the code mnemonic STALE_CHALLENGE is used).  I suggest you 
 > > define "previously used challenge" instead, which is used in 
 > > the document and in the other definitions.  Here is a 
 > > suggested definition:
 > > 
 > >       previously used challenge
 > >                With respect to a given Registration Request, the
 > >                challenge contained therein is previously used if and
 > >                only if the same MN sent the same challenge to the same
 > >                FA in a previous Registration Request, and that
 > >                previous Registration Request passed all FA validity
 > >                checks prior to forwarding to the HA.  The Foreign
 > >                Agent may not be able to keep records for all
 > >                previously used challenges, but see section 3.2 for
 > >                minimal requirements.
 > > 
 > > If you want to define stale challenge, I think this is the appropriate
 > > definition:
 > > 
 > >       stale challenge
 > >                With respect to a given Registration Request, the
 > >                challenge contained therein is stale if and only if the
 > >                challenge is previously used and the Foreign Agent did
 > >                generate a Registration Reply as a result of 
 > > the previous
 > >                use.
 > > 
 > [JB] I don't see any issue with the current definition of Stale Challenge.
 > We have mailing list discussion on this subject in past and as a result, in
 > the 04 version of this draft "Previously Used Challenge" term was removed
 > and the definition of the Stale Challenge was updated. If this is just a
 > terminology change (in section 1.1 only) and no change in the error code, I
 > am fine with replacing "stale challenge" with "previously used challenge".

I think it was a mistake to remove the definition of "previously used
challenge".  That is the term which is actually used in Section 3.2 -
note that the term "stale challenge" isn't used.

The current definition of "stale challenge" is incorrect because it
says "relaying OR generating" when it really should be "relaying AND
generating."  I would prefer to see "previously used challenge"
defined as I gave it above.

 > > On "unused challenge":
 > > 
 > >       unused challenge
 > >                A challenge that has not been already accepted by the
 > >                Foreign Agent challenge in a corresponding Registration
 > >                Reply message -- i.e., a challenge that is neither
 > >                unknown nor previously used.
 > > 
 > > Under the above definition I gave for "previously used" the 
 > > i.e. part is not quite equivalent to the definition: consider 
 > > a known challenge that is previously used, but for which the 
 > > FA has not yet generated a Registration Reply.  This 
 > > challenge satisfies the main definition but not the i.e. part 
 > > (if I am interpreting the main definition correctly: I think 
 > > it contains a typo).
 > > 
 > > Instead this should be simply:
 > > 
 > >       unused challenge
 > >                A challenge that is neither unknown nor 
 > > previously used.
 > > 
 > > Note that a challenge unused only until it is sent to the FA in a
 > > (validated) registration request, not until the Registration 
 > > Reply is returned.
 > >
 > [JB]I agree that current definition of the Unused Challenge has a typo. I
 > have the following recommendation for the text:
 > "unused challenge: A challenge that has not been already accepted by the
 > Foreign Agent from the Mobile Node in the Registration Request, i.e., a
 > challenge that is neither unknown nor previously used."

Ok, this is fine.

...

 > > Also, don't you mean "A Mobile Node registering directly with 
 > > its HA"? A co-located care-of address can still be used with 
 > > an FA, especially one that used the "R" bit in its advertisement.
 > > 
 > [JB] True. If the co-located care-of-address is used with an FA, this
 > document doesn't need any explicit description. My proposed text would be:
 > "A Mobile Node MAY include the Mobile-AAA Authentication extension in the
 > Registration Request when the co-located care-of-address is used without the
 > Foreign Agent. In this case..."

Why not just say "when the MN registers directly with its HA"?
That is the language used in RFC 2002.

 > > I'm not sure I like this paragraph at all---it leaves out too 
 > > much detail and seems to be pointing at a proprietary 
 > > feature.  Perhaps it would be useful to go into more detail 
 > > regarding how to "challenge yourself" in the case there is no 
 > > attendant functionality. Essentially, this would be like 
 > > defining a replay protection mechanism purely for the benefit 
 > > of the AAA.  Perhaps you could just use a timestamp as the 
 > > Challenge value (although you would need to define 
 > > appropriate re-sync procedures upon failure to authenticate).
 > > 
 > [JB] Someone else also proposed earlier on the mailing list to use ID as a
 > challenge. My understanding from that discussion was that if the mobile
 > having the co-located COA (without FA) wants to use ID/timestamp, it can
 > assign that value as a challenge. If the SPI value of CHAP-SPI or
 > HMAC_CHAP_SPI is used, it should use challenge as suggested by this draft.
 > This paragraph (quoted by you) was resulted from our last mailing list
 > discussion on supporting the MN with co-located COA.  

Ok, I can see that this discussion might blow up into something way
too complicated.  I am fine with the current language.

...

 > > Section 3.2, 7th paragraph:
 > >    In the event that the Challenge extension is authenticated through
 > >    the Mobile-Foreign Authentication Extension, the Foreign Agent MAY
 > >    remove the Challenge Extension from the Registration 
 > > Request without
 > >    disturbing the authentication value computed by the Mobile Node for
 > >    use by the AAA or the Home Agent.

 > > If the Challenge extension is not
 > >    removed, it MUST precede the Foreign-Home Authentication 
 > > extension. You can only remove it if it comes after MN-AAA, 
 > > right?  Also, we are not required to use FA-HA 
 > > Authentication, right?  Should be:
 > >
 > >    In the event that the Challenge extension is authenticated through
 > >    the Mobile-Foreign Authentication Extension, and if the 
 > > Challenge extension
 > >    appears after the MN-AAA extension or the MN-AAA extension 
 > > is not present,
 > >    the Foreign Agent MAY
 > >    remove the Challenge Extension from the Registration 
 > > Request without
 > >    disturbing the authentication value computed by the Mobile Node for
 > >    use by the AAA or the Home Agent.  If the Challenge 
 > > extension is not
 > >    removed, it MUST precede the Foreign-Home Authentication extension,
 > >    if a security association is in use between Foreign and 
 > > Home agents.
 > > 
 > [JB] I agree to both your comments but I have some modifications to your
 > proposed text:
 > "In the event that the Challenge extension is authenticated through the
 > Mobile-Foreign Authentication Extension and the Mobile-AAA Authentication
 > extension is not present, the Foreign Agent MAY remove the Challenge
 > Extension from the Registration Request without disturbing the
 > authentication value computed by the Mobile Node for use by the AAA or the
 > Home Agent.  If the Mobile-AAA Authentication extension is present, the
 > Challenge and the Mobile-AAA Authentication extensions MUST precede the
 > Foreign-Home Authentication extension."

Isn't it possible to put MN-AAA prior to the Challenge if the
MN-FA was used to protect the Challenge?  In this case you could
remove the Challenge without bothering the MN-AAA.

You need to keep "If a security association is in use between Foreign
and Home agents," because the FA-HA is not mandatory.

...

 > > Section 3.4, 2nd paragraph:
 > >    If the Home Agent receives a Registration Request with the 
 > > Mobile-AAA
 > >    Authentication extension, it will be handled based on the local
 > >    policy of the Home Agent.  If the Mobile-AAA 
 > > Authentication extension
 > >    is used by the Home Agent as an authorization-enabling extension
 > >    and the verification fails due to incorrect authenticator, the
 > >    Home Agent MAY reject the Registration Reply with the error code
 > >    BAD_AAA_AUTHENTICATION_SET_BY_HA.
 > > Should be:
 > >    If the Home Agent receives a Registration Request with the 
 > > Mobile-AAA
 > >    Authentication extension, and if the Mobile-AAA 
 > > Authentication extension
 > >    is used by the Home Agent as an authorization-enabling extension
 > >    and the verification fails due to incorrect authenticator, the
 > >    Home Agent MAY reject the Registration Reply with the error code
 > >    BAD_AAA_AUTHENTICATION_SET_BY_HA.
 > > 
 > [JB] I don't have issue removing the term "local policy". Since your
 > proposed sentence is too long to follow, I like to propose the following
 > text instead"
 > " The Home Agent MAY receive a Registration Request with the Mobile-AAA
 > Authentication extension.  If the Mobile-AAA Authentication extension is
 > used by the Home Agent as an authorization-enabling extension and the
 > verification fails due to incorrect authenticator, the Home Agent MAY reject
 > the Registration Reply with the error code
 > BAD_AAA_AUTHENTICATION_SET_BY_HA."

Ok, this is fine.

...

 > > In Section 7:
 > >    A list of reserved SPI numbers is to
 > >    be maintained by IANA at the following URL:
 > > 
 >       http://www.iana.org/numbers.html
 > 
 >    From that URL, follow the hyperlinks to [M] within the "Directory of
 >    General Assigned Numbers", and subsequently to the specific section
 >    for "Mobile IP Numbers".
 > This is quite odd.  Is it appropriate to refer to the internal structure of
 > the IANA web pages?  What if it changes someday?
 > 
 > [JB] Let me know if you have better text to replace the current
one.

I would just revert to the previous 3012 text in this section: i.e.,
delete the paragraph beginning with "From that URL, follow the
hyperlinks..."

...

-Pete

---

From: Pete McCann <[email-masked]>
Date: Thu, 10 Jul 2003 14:39:05 -0500

Hi, Jayshree,

Thanks for the proposed changes, you have addressed most of my
concerns.  It looks like we are down to only one point of disagreement
- see below.

Jayshree Bharatia writes:
 > >  > [JB] Based on comments from you and Iris, I like to 
 > > propose the following  > text for section 1.1: "previously 
 > > used challenge: Any challenge that has  > been used by the 
 > > mobile node in a Registration Request message and processed  
 > > > by the Foreign Agent by generating and relaying a 
 > > corresponding Registration  > Reply message. The Foreign 
 > > Agent may not be able to keep records for all  > previously 
 > > used challenges, but see section 3.2 for minimal requirements."
 > > 
 > > This definition is not consistent with the usage of 
 > > "previously used" in Section 3.2.  The key sentence is the following:
 > > 
 > >    In all
 > >    other circumstances, if the Foreign Agent receives a Registration
 > >    Request with a Challenge extension containing a Challenge value
 > >    previously used by that mobile node, the Foreign Agent SHOULD send
 > >    a Registration Reply to the mobile node containing the Code value
 > >    STALE_CHALLENGE.
 > > 
 > > In combination with the previous text, this tells me that a 
 > > "previously used challenge" is previously used as soon as it 
 > > is received by the FA.  I believe the definition I offered 
 > > above is precise and accurate (the one beginning "With 
 > > respect to a given registration request...").
 > [JB] I still think that the current definition is correct. If there is any
 > issue with the received Registration Request as a part of processing, the FA
 > will send rejection with new challenge value. In any case, it won't be
 > possible to reuse the challenge once it is received by the FA.  

No, it is possible to reuse the challenge in a retransmitted
registration request, as outlined in Section 3.2.  Under my reading of
that section a retransmission of a Challenge is still a "previously
used" challenge, even though the Reply has not been sent/received.  Note
that this is different from a "stale challenge" which is one that has
been used in a request, validated by the FA, and for which a Reply
was sent to the MN.  I would like to keep this distinction in the
definitions.  Otherwise, I think you will need to re-write some of the
text in Section 3.2.

-Pete