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

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 7 Jan 2003 17:45:30 -0600

Hello Yoshi,
I think this is taking too much time for no reason.

First of all, I have a very high and great respect to Charlie and I believe
you
should not address discussion that way. If you have a scenario which you
believe
requires both MN-AAA and MN-FA authentication extension, please come forward
and
present it.

On the other hand, I really have reservation on your reading of RFC3012
(RFC3012-bis).
If the following text does not convince you that any registration request
coming to the PDSN MUST have EITHER MN-AAA auth ext. OR MN-FA auth. ext.
I really and honestly do not see what would.

"
   Furthermore, the Foreign Agent MUST check that there is either a
   Mobile-Foreign, or a Mobile-AAA Authentication extension after
   the Challenge extension.  Any registration message containing
   the Challenge extension without either of these authentication
   extensions MUST be silently discarded.  If the registration
   message contains a Mobile-Foreign Authentication extension with an
   incorrect authenticator that fails verification, the Foreign Agent
   MAY send a Registration Reply to the mobile node with Code value
   BAD_AUTHENTICATION (see Section 10).
"

Regards;
Ahmad Muhanna

---

From: "Fredrik Johansson" <[email-masked]>
Date: Mon, 13 Jan 2003 19:18:54 +0100

RE: CLARIFICATION: Re: [mobile-ip] RFC3012bis-04 AvailableAll,

I believe that there might be cases where both the MN-FA and the MN-AAA auth
extension can be present in a registration request. If a MN connects to a
network where the AAA infrastructure is based on Diameter, the MN may not
have a MN-FA Mobility SA so it MUST be authenticated with the MN-AAA
Mobility SA, the Diameter server may then be configured (or the FA may
request) to distribute a MN-FA Mobility SA to the FA and MN, in the coming
registration requests, the MN will have a Mobility SA with the FA, thus it
has to send the MN-FA auth ext. But it also has a SA with the AAA and it can
not be sure when the FA need the MN-AAA auth ext in order to send the
request via the Diameter server for re-authentication and key renewal.

/fredrik
  -----Original Message-----
  From: [email-masked]
[mailto:[email-masked]]On Behalf Of Ahmad Muhanna
  Sent: Wednesday, January 08, 2003 12:46 AM
  To: 'Yoshiyuki Tsuda'
  Cc: Kuntal Chowdhury; Charles E. Perkins; Jayshree Bharatia;
[email-masked]'; [email-masked]
  Subject: RE: CLARIFICATION: Re: [mobile-ip] RFC3012bis-04 Available

  Hello Yoshi,

  First of all, I have a very high and great respect to Charlie and I
believe you
  should not address discussion that way. If you have a scenario which you
believe
  requires both MN-AAA and MN-FA authentication extension, please come
forward and
  present it.

  "

  Regards;
  Ahmad Muhanna

---

From: Kuntal Chowdhury <[email-masked]>
Date: Mon, 13 Jan 2003 16:21:25 -0600

The following point is not clear to me from the description of the scenario:

Why will the FA request for key distribution for MN-FA from the AAA 
server when it was able to authenticate the user of the MN through 
MN-AAA auth extension?

IMHO, the MN-FA and MN-AAA auth extensions are complimentary, therefore 
using both in the same message is going to introduce redundancy. However 
if more people think that having some redundancy in the registration 
request message helps in certain scenarios, then we can allow all MN-xx 
extensions and move on. Moreover I would insist that we fix/clarify the 
following text in RFC 3344 before we decide to move down this path, 
because this text clearly conflicts with what we are discussing here.

"3.5.3. Mobile-Foreign Authentication Extension

    This Extension MAY be included in Registration Requests and Replies
    in cases in which a mobility security association exists between the
    mobile node and the foreign agent.
"

-Kuntal

Fredrik Johansson wrote:
> All,
>  
> I believe that there might be cases where both the MN-FA and the MN-AAA 
> auth extension can be present in a registration request. If a MN 
> connects to a network where the AAA infrastructure is based on Diameter, 
> the MN may not have a MN-FA Mobility SA so it MUST be authenticated with 
> the MN-AAA Mobility SA, the Diameter server may then be configured (or 
> the FA may request) to distribute a MN-FA Mobility SA to the FA and MN, 
> in the coming registration requests, the MN will have a Mobility SA with 
> the FA, thus it has to send the MN-FA auth ext. But it also has a SA 
> with the AAA and it can not be sure when the FA need the MN-AAA auth ext 
> in order to send the request via the Diameter server for 
> re-authentication and key renewal.
>  
> /fredrik
> 
>     should not address discussion that way. If you have a scenario which
>     you believe
>     On the other hand, I really have reservation on your reading of
>     RFC3012 (RFC3012-bis).