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

From: "Jayshree Bharatia" <[email-masked]>
Date: Tue, 8 Jul 2003 17:17:02 -0500

Hello Pete,

Please see my comments inline.

Thanks,
Jayshree

> -----Original Message-----
> From: Pete McCann [mailto:[email-masked]]
> Sent: Tuesday, July 01, 2003 10:34 AM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: [email-masked]'; [email-masked]';
> [email-masked]'
> Subject: RE: [mobile-ip] Comments on 3012bis

>  > [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.
> 
[JB] Ok. In this case, I can update the current abstract as below:
"...In this specification, we define extensions for the Mobile IP Agent
Advertisements and the Registration Request that allow a foreign agent to
use a challenge/response mechanism to authenticate the mobile node.
Furthermore, an additional authentication extension, the Mobile-AAA
authentication extension, is provided so that a mobile node can supply
credentials for authorization using commonly available AAA infrastructure
elements. This Authorization-enabling extension MAY co-exist in the same
Registration Request with Authentication extensions defined for Mobile IP
Registration by [7]. This document obsoletes RFC 3012."	

>  > > 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.
> 
[JB] If I recall you have posted this issue of RFC3344 on the mailing list
earlier also and I also agree that this  needs to be resolved. But again I
am not sure whether RFC3012bis is the right place. 

>  > >       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.
> 
[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."
> 
>  > > 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.
[JB] I don't have problem either way. It is just that in past, I have
received comments wrt to support of the mobile node with co-located CoA.
Although, your suggestion doesn't change anything for supporting the mobile
node with co-located CoA, it may cause further confusion to others.

>  > > 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.
> 
[JB] According to RFC3012bis (section 3.2), the challenge is always prior to
the MN-AAA auth extension. So it won't be possible to remove the challenge
extension when the MN-AAA auth exist in the Registration Request. Also, this
draft mandates in section 3.2 that if the MN-AAA auth extension is received
in the Registration Request, the FA must not remove the MN-AAA auth and the
challenge extension.

> You need to keep "If a security association is in use between
> Foreign and Home agents," because the FA-HA is not mandatory.
> 
[JB] Ok. I will add this condition to the text.
> 
>  > > 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..."
> 
[JB] Ok
> ...
> -Pete

---

From: Pete McCann <[email-masked]>
Date: Wed, 9 Jul 2003 10:18:34 -0500

Hi, Jayshree,

A few responses below.  I have deleted text where it is not necessary
for context, and where we have reached agreement...

 > Registration by [7]. This document obsoletes RFC 3012."	

Can we say somewhere "this document updates RFC 3344"?  That would be
very helpful to the reader when they see this conflict in requirements.

 > am not sure whether RFC3012bis is the right place. 

I think RFC3012bis has already done this.  See the following text in
Section 3.2:

   If the Mobile-AAA
   Authentication Extension is present in the Registration Request, the
   Foreign Agent MUST NOT remove the Mobile-AAA Authentication Extension
   and the Mobile-Foreign Challenge Extension from the Registration
   Request.  

I am just asking that this change be made explicit with the "updates"
language, which is a flag that tells the reader this spec takes
precedence over RFC 3344.  Otherwise, I'm sure there will be big
arguments in other SDOs (e.g., 3GPP2) when these conflicting
requirements are discovered.

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

 > node with co-located CoA, it may cause further confusion to others.

Ok, why don't we use "when the MN registers directly with its HA (using a
co-located care-of address)."?

 > extension when the MN-AAA auth exist in the Registration Request.

I disagree.  The draft only requires this ordering if the challenge is
not protected by MN-FA authentication extension.  The only statements
I can find on the relative ordering of MN-AAA and Challenge extensions
are the following:

   If present, the Mobile-AAA
   extension MUST precede to the Mobile-Foreign Authentication
   extension.

and

   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.

Note that if MN-FA auth is used, there is no requirement for the
Challenge to come before MN-AAA.

 > Also, this

Yes, that is the same requirement I quoted above which is an update to
RFC 3344.

I think you should either make it clear with an explicit requirement
that MN-AAA MUST follow the FA Challenge if both are present, or relax
the "no removal" requirement so that it only applies to MN-AAA
extension and anything preceding it.

-Pete