Subject: RE: [mobile-ip] RFC3012bis-04 Available

From: "Jayshree Bharatia" <[email-masked]>
Date: Fri, 3 Jan 2003 14:31:55 -0600

Looks like my original posting was lost. Please see my comments inline.

Thanks,
Jayshree

> -----Original Message-----
> From: Yoshiyuki Tsuda [mailto:[email-masked]]
> Sent: Friday, January 03, 2003 6:21 AM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: [email-masked]'; [email-masked]';
> [email-masked]
> Subject: Re: [mobile-ip] RFC3012bis-04 Available
> 
> 
> Hi Jayshree,
> 
>  My comments are embeded in the following...
> 
> Thanks.
> -Yoshi
> 
> at Thu, 2 Jan 2003 13:08:15 -0600, Jayshree Bharatia wrote:
> >Hello Yoshi,
> >
> >Please see my response inline. 
> >
> >Regards,
> >Jayshree
> >
> >> -----Original Message-----
> >> From: Yoshiyuki Tsuda [mailto:[email-masked]]
> >> Sent: Saturday, December 28, 2002 5:03 AM
> >> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> >> Cc: [email-masked]'; [email-masked]';
> >> [email-masked]
> >> Subject: Re: [mobile-ip] RFC3012bis-04 Available
> >> 
> >> 
> >> Jayshee,
> >> 
> >>  Unfortunately, the proposed text will cause a problem.
> >>  There is the following case where both MN-AAA authentication
> >>  extension and a Mobile-Foreign authentication extension are
> >>  required:
> >> 
> >>  If an MN has a configured home address, but the MN doesn't
> >>  have a configured HA, and the MN wants to be authorized by
> >>  an AAA, and there is an SA between the MN and an FA, both
> >>  an MN-AAA authentication extension and a Mobile-Foreign
> >>  authentication are required, you know, where,
> >>  - the MN-AAA authentication extension is used to verify the
> >>    MN and assign an HA,
> >
> >[JB] The intent of RFC3012bis is to use MN-AAA Authentication 
> >extension when there is no security association between the MN 
> >and the FA. If you already have a security association between
> >MN and the FA, what type of verification the MN is trying to
> >do with the AAA? 
> 
>  As I wrote in the above, the AAA(H) is expected to
>  authenticate the MN and assign an HA to the MN.
>  In this case, you know, there isn't a Mobile-Home
>  Authentication extension, but an MN-AAA Authentication
>  extension at the beginning in order to authenticate
>  the MN.
> 
> 

[JB] I am not sure why there isn't a Mobile-Home Authentication extension.
Regardless, the scenario you have just mention is applicable to basic MIP
operation and should work even when the mobile node and Foreign agent are
not RFC3012bis compliant. 

> >>  - the Mobile-Foreign authentication extension is used to
> >>    verify the MN by a visited network.
> >> 
> >>  And, I believe a protocol should define mechanisms, not
> >>  policies;  your proposed texts smells the policy to prohibit
> >>  the above customer's requests.
> >> 
> >[JB] Unfortunately, we have to deal with the optionality and hence 
> >need this type of policy so that customer's requirements are 
> clarified.
> 
>  Then, I'd like to ask you WHY you proposed that the
>  Request must not include both Mobile-Foreign
>  Authentication extension and Mobile-AAA Authentication
>  extension.
> 
>  Are there any serious problems ?

The RFC3012bis draft allows a foreign agent/Mobile node to a use
challenge/response mechanism for the replay protection. In this context, if
MN-FA authentication extension is used, it is sufficient to authenticate the
mobile node. This is generally the case when there is a security
association.  But the similar type of extension is essential when there is
no security association between the MN and the FA. Hence, this draft defines
MN-AAA authentication extension so that a mobile node can still supply
credentials for the MN authorization. We have currently mentioned in the
draft that MN-AAA must be included if the MN-FA extension is not present.
Having both extensions in the same message doesn't serve any added value.
Putting explicit text on allowing only one extension in the same
Registration Request message will prevent further confusion. 

It seems you are trying to use MN-AAA authentication extension to instruct
the FA to use the AAA infrastructure. The basic MIP operation should able to
support this type of  functionality even when the mobile node and foreign
agent are not RFC3012bis compliant and hence I have reservation toward
accepting your comments. 
> >> Thanks.
> >> -Yoshi

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 03 Jan 2003 15:07:04 -0800

Hello folks,

I have some comments inline about the authentication extensions.
They were originally designed to minimize inter-feature
interference, and so are largely independent.  However,
whenever a security association exists between two entities,
the corresponding authentication extension MUST be present.
So, it MIGHT be possible to have both the Mobile-Home and
the Mobile-AAA (and even the Mobile-Foreign) extension all
in the same registration request.

> Jayshree Bharatia wrote:

> >  extension at the beginning in order to authenticate

If the mobile has a home agent, but moves to a new domain,
then it might require AAA support to satisfy the authorization
requirements in the new domain.  In this circumstance, the
new registration would naturally have both types. 
This is not necessarily incompatible with the last paragraph
above, but it is good to keep in mind.

> mobile node. This is generally the case when there is a security association.

It is sufficient from the standpoint of the foreign agent, surely.

> But the similar type of extension is essential when there is no security
> association between the MN and the FA. Hence, this draft defines MN-AAA
> authentication extension so that a mobile node can still supply credentials
> for the MN authorization. We have currently mentioned in the draft that MN-AAA
> must be included if the MN-FA extension is not present. Having both extensions
> in the same message doesn't serve any added value.

There might be cases when both are needed.  For instance, the mobile
node might need to get a new home agent for some reason, perhaps if the
last registration reply indicated a failure condition.

>                                                    Putting explicit text on
> allowing only one extension in the same Registration Request message will
> prevent further confusion.

I didn't see why it was needed, but I didn't read all of the previous
messages.  Is the confusion just based on ordering?

> It seems you are trying to use MN-AAA authentication extension to instruct the
> FA to use the AAA infrastructure.

This seems to put the cart before the horse.  The FA is likely to
be using the AAA infrastructure regardless of the mobile node's
operation.  If the FA can't use the AAA infrastructure because of
some lack of the mobile node, it won't accept the registration.

>                               The basic MIP operation should able to

In fact, the basic Mobile IP operation is currently specified to enable
the classification of MN-AAA as a "authorization-enabling extension",
but the only way to get it approved is by having the foreign agent to
be aware of the extension and to do some "right thing".  Presumably,
this could be DIAMETER or RADIUS or any other AAA sort of thing, at
least as far as Mobile IP is concerned.

Regards,
Charlie P.