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

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 15 Jan 2003 11:24:36 -0800

Jayashree,
 
I think we can add an additional sentence saying that "FA MAY not remove the MN-AAA extension after successful completion of
the authentication, depending up on policy constraints"  or some such thing like that.
 
This means that HA may receive a registration request with MN-AAA option which it should be prepared to handle (if
DIAMETER is used, it looks like it always receives it). I think it might be worthwhile to calrify this also in the document.
 
-mohan

-----Original Message-----
From: Jayshree Bharatia [mailto:[email-masked]]
Sent: Wednesday, January 15, 2003 10:35 AM
To: Mohan Parthasarathy; Kuntal Chowdhury; [email-masked]
Cc: Ahmad Muhanna; Yoshiyuki Tsuda; Charles E. Perkins; [email-masked]; [email-masked]
Subject: RE: CLARIFICATION: Re: [mobile-ip] RFC3012bis-04 Available

Hello Mohan, 

This was regarding your earlier email discussion on the clarification on the following text in section 3.2 of RFC3012bis:

"The Foreign Agent MUST NOT remove the Mobile-AAA Authentication Extension from the Registration Request prior to the completion of the authentication performed by the AAA infrastructure." 

You have mentioned that this statement sorts of hints that you can remove it after verification. 

For the clarification in RFC3012bis, so far I have received  the following options: 
1. we remain silent about what FA does with MN-AAA auth extension after successful verfication and leave it upto local policy.

For this we need to modify current text in RFC3012bis saying that the processing of the MN-AAA extension is up to the local policy at the foreign agent.

2. we explicitly say that the "FA does not remove MN-AAA auth extension after successful verification" 
This is consistent with the text in section 3.7.2.2 of RFC 3344 since the MN-AAA extension may be used as an Authentication-Enabling extension. From the earlier discussion it seems this approach is analogous to 3GPP2 also.

I am open to comments/suggestions. 

Thanks, 
Jayshree 

-----Original Message----- 
From: Mohan Parthasarathy [ mailto:[email-masked]] 
Sent: Wednesday, January 15, 2003 11:53 AM 
To: Bharatia, Jayshree [RICH1:2H13:EXCH]; Kuntal Chowdhury; [email-masked] 
Cc: Muhanna, Ahmad [RICH2:2Q20:EXCH]; Yoshiyuki Tsuda; Charles E. Perkins; [email-masked]; [email-masked]

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

Jayashree, 
  
-----Original Message----- 
From: Jayshree Bharatia [ mailto:[email-masked]] 
Sent: Tuesday, January 14, 2003 12:49 PM 
To: 'Kuntal Chowdhury'; [email-masked] 
Cc: Ahmad Muhanna; 'Yoshiyuki Tsuda'; Charles E. Perkins; [email-masked]; [email-masked] 
Subject: RE: CLARIFICATION: Re: [mobile-ip] RFC3012bis-04 Available 

Hello, 
In addition to clarification text in RFC3344, we need to update RFC3012bis to introduce new error codes for the MN-AAA extension failure if all MN-xx auth extensions are allowed in a Registration Request. Currently the same error code (BAD_AUTHENTICATION) is sent to mobile for the authentication failure due to the MN-FA auth extension or MN-AAA  extension.

Also, we need to clarify the FA's action upon receipt of the MN-AAA extension.  
I am not sure what you meant by this. We need to clarify the processing of MN-AAA extension on the HA. 
-mohan 
  
If you can think of any other changes for RFC3012bis, please let me know. 
Thanks, 
Jayshree 
> -----Original Message----- 
> From: Kuntal Chowdhury [ mailto:[email-masked]] 
> Sent: Monday, January 13, 2003 4:21 PM 
> To: [email-masked] 
> Cc: Muhanna, Ahmad [RICH2:2Q20:EXCH]; 'Yoshiyuki Tsuda'; Charles E. 
> Perkins; Bharatia, Jayshree [RICH1:2H13:EXCH]; 
> [email-masked]; [email-masked] 
> Subject: Re: CLARIFICATION: Re: [mobile-ip] RFC3012bis-04 Available 
> 
> 
> 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 
> > 
> >     -----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, 
> >     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: Wed, 15 Jan 2003 20:58:53 +0100

RE: CLARIFICATION: Re: [mobile-ip] RFC3012bis-04 Availableyes, that's true,
if Diameter is used, the fa will not remove the mn-aaa auth ext (but on the
other hand it can not since it doesn't know if the message is authenticated)
so the extension will reach the ha

/fredrik
  -----Original Message-----
  From: Mohan Parthasarathy [mailto:[email-masked]]
  Sent: Wednesday, January 15, 2003 8:25 PM
  To: Jayshree Bharatia; Kuntal Chowdhury; [email-masked]
  Cc: Ahmad Muhanna; Yoshiyuki Tsuda; Charles E. Perkins;

  Jayashree,

  I think we can add an additional sentence saying that "FA MAY not remove
the MN-AAA extension after successful completion of
  the authentication, depending up on policy constraints"  or some such
thing like that.

  This means that HA may receive a registration request with MN-AAA option
which it should be prepared to handle (if
  DIAMETER is used, it looks like it always receives it). I think it might
be worthwhile to calrify this also in the document.

  -mohan

    -----Original Message-----
    From: Jayshree Bharatia [mailto:[email-masked]]
    Sent: Wednesday, January 15, 2003 10:35 AM
    To: Mohan Parthasarathy; Kuntal Chowdhury; [email-masked]
    Cc: Ahmad Muhanna; Yoshiyuki Tsuda; Charles E. Perkins;

    Hello Mohan,

    This was regarding your earlier email discussion on the clarification on
the following text in section 3.2 of RFC3012bis:

    "The Foreign Agent MUST NOT remove the Mobile-AAA Authentication
Extension from the Registration Request prior to the completion of the
authentication performed by the AAA infrastructure."

    You have mentioned that this statement sorts of hints that you can
remove it after verification.

    For the clarification in RFC3012bis, so far I have received  the
following options:
    1. we remain silent about what FA does with MN-AAA auth extension after
successful verfication and leave it upto local policy.

    For this we need to modify current text in RFC3012bis saying that the
processing of the MN-AAA extension is up to the local policy at the foreign
agent.

    2. we explicitly say that the "FA does not remove MN-AAA auth extension
after successful verification"
    This is consistent with the text in section 3.7.2.2 of RFC 3344 since
the MN-AAA extension may be used as an Authentication-Enabling extension.
From the earlier discussion it seems this approach is analogous to 3GPP2
also.

    Thanks,
    Jayshree

    -----Original Message-----
    From: Mohan Parthasarathy [mailto:[email-masked]]
    Sent: Wednesday, January 15, 2003 11:53 AM
    To: Bharatia, Jayshree [RICH1:2H13:EXCH]; Kuntal Chowdhury;
[email-masked]
    Cc: Muhanna, Ahmad [RICH2:2Q20:EXCH]; Yoshiyuki Tsuda; Charles E.
Perkins; [email-masked]; [email-masked]

    Jayashree,

    -----Original Message-----
    From: Jayshree Bharatia [mailto:[email-masked]]
    Sent: Tuesday, January 14, 2003 12:49 PM
    To: 'Kuntal Chowdhury'; [email-masked]
    Cc: Ahmad Muhanna; 'Yoshiyuki Tsuda'; Charles E. Perkins;

    Hello,
    In addition to clarification text in RFC3344, we need to update
RFC3012bis to introduce new error codes for the MN-AAA extension failure if
all MN-xx auth extensions are allowed in a Registration Request. Currently
the same error code (BAD_AUTHENTICATION) is sent to mobile for the
authentication failure due to the MN-FA auth extension or MN-AAA  extension.

    Also, we need to clarify the FA's action upon receipt of the MN-AAA
extension.
    I am not sure what you meant by this. We need to clarify the processing
of MN-AAA extension on the HA.
    -mohan

    If you can think of any other changes for RFC3012bis, please let me
know.
    Thanks,
    Jayshree
    > From: Kuntal Chowdhury [mailto:[email-masked]]
    > >     [mailto:[email-masked]]On Behalf
    > Of Ahmad Muhanna