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

From: "Jayshree Bharatia" <[email-masked]>
Date: Fri, 27 Jun 2003 13:43:55 -0500

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.

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

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

> 
> 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."
 
> 
> Section 3.1, 3rd paragraph:
>    If present, the Mobile-AAA
>    extension MUST precede to the Mobile-Foreign Authentication
>    extension.
> Should be:
>    If both are present, the Mobile-AAA
>    extension MUST precede the Mobile-Foreign Authentication
>    extension.
>    
[JB] Agreed (this editorial comment was posted earlier).
> 
> Section 3.1, 4th paragraph:
>    If the Mobile Node does not have a security association with
>    the Foreign Agent, the Mobile Node MUST include the Mobile-AAA
>    Authentication extension as defined in section 6.  
> Should be:
>    If the Mobile Node does not have a security association with
>    the Foreign Agent, the Mobile Node MUST include the Mobile-AAA
>    Authentication extension as defined in section 6 when it includes
>    the MN-FA Challenge Extension.  
> 
[JB] Agreed
> 
> Section 3.1, 6th paragraph:
>    Based on local policy, a Mobile Node with co-located 
> care-of-address
>    MAY include the Mobile-AAA Authentication extension in Registration
>    Request.  In this case, if the Mobile Node uses SPI value 
> of CHAP_SPI
>    or HMAC_CHAP_SPI (section 8) in the MN-AAA Authentication 
> extension,
>    Mobile Node MUST include the Mobile-Foreign Challenge 
> extension prior
>    to the Mobile-AAA Authentication extension.  The mechanism used by
>    the Mobile Node to obtain the Challenge value is outside 
> the scope of
>    this document.
> Strike the phrase "Based on local policy" from the above.
> 
[JB] Agreed

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

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

> 
> Section 3.2, 4th paragraph:
>    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,
> Should be:
>    The Foreign Agent MUST NOT accept any Challenge in the Registration
>    Request unless it was offered in the last Registration Reply issued
>    to the Mobile Node,
> 
[JB] Agreed (this editorial comment was posted earlier)
> 
> 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."

> 
> Section 3.2, penultimate paragraph:
>    If the Challenge value defers in the Registration Reply
>    received from the Home Agent, 
> Should be:
>    If the Challenge value differs in the Registration Reply
>    received from the Home Agent, 
> 
[JB] Agreed (this editorial comment was posted earlier)

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

> Section 6, 1st paragraph:
>    This extension MAY co-exist in the same
>    Registration Request with Authetication extensions defined 
> for Mobile
>    IP Registration by [7]. 
> should be:
>    This extension MAY co-exist in the same
>    Registration Request with Authentication extensions 
> defined for Mobile
>    IP Registration by [7]. 
> 
[JB] Agreed (this editorial comment was posted earlier)
> 
> 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.

In the annexes: put notes that the message flows in each annex are
informative only, especially the one in Annex C.
[JB] Will do