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

From: "Jayshree Bharatia" <[email-masked]>
Date: Mon, 23 Dec 2002 15:32:30 -0600

Hello all,
 
Currently we have the following paragraph in section 6 
"If the mobile node does not include a Mobile-Foreign Authentication [7]
extension, then it MUST include the Mobile-AAA Authentication extension
whenever the Challenge extension is present." 
 
As Mark pointed out, there is nothing in this draft to prevent having both
MN-AAA and MN-FA authentication extensions in the Registration Request.
Since we are interested in either MN-AAA authentication or MN-FA
authentication, I like to propose the following text for section 6.
 
"If the mobile node does not include a Mobile-Foreign Authentication [7]
extension, then it MUST include the Mobile-AAA Authentication extension
whenever the Challenge extension is present. But the same Registration
Request MUST not include both Mobile-Foreign Authentication extension and
Mobile-AAA Authentication extension."
 
Any comments?
 
Regards,
Jayshree

-----Original Message-----
From: Robert J Marks [mailto:[email-masked]]
Sent: Monday, December 23, 2002 2:58 PM
To: Bharatia, Jayshree [RICH1:2H13:EXCH]
Subject: RE: [mobile-ip] RFC3012bis-04 Available

Hi Jayshree,
 
The draft does not appear to prohibit both the MN-FA and MN-AAA extensions
from being present in the same request. I do not believe you can assume that
if one is present, the other will not be. Perhaps if the intent is to allow
one or the other, the draft could be more specific.
 
Bob

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jayshree Bharatia
Sent: Monday, December 23, 2002 2:30 PM
To: [email-masked]' <mailto:[email-masked]'>

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

-----Original Message----- 
From: Bharatia, Jayshree [RICH1:2H13:EXCH] 
Sent: Monday, December 23, 2002 2:28 PM 
To: 'Yoshiyuki Tsuda'; [email-masked]' 
Cc: Chowdhury, Kuntal [RICH1:2H18:EXCH] 
Subject: RE: [mobile-ip] RFC3012bis-04 Available 

Hello Yoshi, 

Please see my comments below. 

Regards, 
Jayshree 

> -----Original Message----- 
> From: Yoshiyuki Tsuda [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Saturday, December 21, 2002 4:10 AM 
> To: Bharatia, Jayshree [RICH1:2H13:EXCH] 
> Cc: [email-masked]; [email-masked]'; 
> Chowdhury, Kuntal 
> [RICH1:2H18:EXCH] 
> Subject: Re: [mobile-ip] RFC3012bis-04 Available 
> 
> 
> Hi Jayshree, 
> 
>  Thank you for your pointer.  I've found it in Appendix B. 
>  OK, AAA is expected to set BAD_AUTHENTICATION(67).  Then, 

[JB] Not sure why you have mentioned that AAA is expected to set
BAD_AUTHENTICATION (67). The draft RFC3012bis expects the foreign agent to
send BAD_AUTHENTICATION error code in a Registration Reply if the
verification at AAA fails. Please note that interactions between the AAA and
Foreign Agent are not part of RFC3012bis.

>  there is a small issue; if an MN receives the error code 
>  of BAD_AUTHENTICATION(67), and if there are Mobile-Foreign 
>  authentication extension and MN-AAA authentication 
>  extension in a registration request or a registration reply, 
>  the MN cannot distinguish which extension has the error... 
> 

[JB] As per the current description in RFC3012bis draft, if the Mobile Node
does not have a security association with the Foreign Agent, the Mobile Node
must include the Mobile-AAA Authentication extension.  If security
association exists between the MN and the FA, the MN-FA authentication
extension is included and there won't be MN-AAA authentication extension in
the Registration Request message. Hence there is no issue.

>  Also, in case of a co-located Mobile Node, which error code 
>  does the MN expect to receive, 67 or 131 ? 
> 

[JB] RFC3012bis allows a foreign agent to use a challenge/response mechanism
to authenticate the mobile node. For co-located Mobile Node, this mechanism
is not applicable.

>  Although the above issues might be so small, it would have 
>  be much clearer to assign a new error code to the verification 
>  error of MN-AAA authentication extension, I'd like to think. 
>  Have great holidays! 
> 
> Thanks. 
> -Yoshi 
> 
> at Fri, 20 Dec 2002 16:25:45 -0600, Jayshree Bharatia wrote: 
> >Hello Yoshi, 
> > 
> >For a verification error, the AAA has to set the error code. 
> This is what 
> >currently is not in the scope of RFC3012bis. But once this 
> verification 
> >failure is notified to the FA, the error code 
> BAD_AUTHENTICATION is sent to 
> >the mobile node in the Registration Reply. This is discussed 
> in section 3.2 
> >of RFC3012bis draft. 
> > 
> >Regards, 
> >Jayshree 
> > 
> >-----Original Message----- 
> >From: Yoshiyuki Tsuda [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> >Sent: Friday, December 20, 2002 4:17 PM 
> >To: Bharatia, Jayshree [RICH1:2H13:EXCH] 
> >Cc: [email-masked]; [email-masked]'; 
> Chowdhury, Kuntal 
> >[RICH1:2H18:EXCH] 
> >Subject: Re: [mobile-ip] RFC3012bis-04 Available 
> > 
> > 
> >Hi Jayshree and all, 
> > 
> > Thank you for your qualification. 
> > Ah, it's outside the scope of rfs3012bis ?!!! 
> > I understand authentication issues by AAA should be treated 
> > by AAA(diameter).  But, personally I'd thought rfc3012 was 
> > the best place to define error codes related to MN-AAA 
> > authentication extension, because MN's developers won't 
> > read Diameter's I-Ds without a pointer, and because right 
> > now such an error code is missing in Diameter's I-Ds, I'm 
> > afraid. 
> > Have great holidays! 
> > 
> >Thanks. 
> >-Yoshi 
> > 
> > 
> >at Fri, 20 Dec 2002 11:44:12 -0600, Jayshree Bharatia wrote: 
> >>Hello Yoshi, 
> >> 
> >>The verification and related processing at AAA is outside 
> the scope of 
> >>RFC3012bis. The current version of RFC3012bis (04) has a 
> description in 
> >>section 3.2 regarding how verification errors received from 
> the AAA are 
> >>treated at the foreign agent. 
> >> 
> >>Regards, 
> >>Jayshree 
> >> 
> >> 
> >>-----Original Message----- 
> >>From: Yoshiyuki Tsuda [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> >>Sent: Friday, December 20, 2002 4:46 AM 
> >>To: Bharatia, Jayshree [RICH1:2H13:EXCH] 
> >>Cc: [email-masked]; [email-masked]' 
> >>Subject: Re: [mobile-ip] RFC3012bis-04 Available 
> >> 
> >> 
> >>Hi Jayshree, 
> >> 
> >> Just one question: 
> >> If an AAA find an authentication error in MN-AAA 
> >> authentication extension, what error code will the AAA 
> >> return to an MN ? 
> >> 
> >> I've just found the above error code is missing; a 
> >> guideline to allocate error codes from the AAA seems to 
> >> be missing, I'm afraid.  Or, am I missing any other RFCs ? 
> >> 
> >> Someone suggested me to use 131 (mobile node failed 
> >> authentication).  I think it's a good idea to use it 
> >> instead now... 
> >> 
> >>Thanks in advance. 
> >>-Yoshi 
> >> 
> >> 
> >>at Tue, 17 Dec 2002 13:09:32 -0600, Jayshree Bharatia wrote: 
> >>>Hello all, 
> >>> 
> >>>New version of RFC3012bis (version 04) is now available at 
> >>> http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc
<http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc>  
3012bis-04.txt. 
>>>Thanks, 
>>>Jayshree

---

From: Yoshiyuki Tsuda <[email-masked]>
Date: Sat, 28 Dec 2002 20:02:40 +0900

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

Thanks.
-Yoshi

---

From: "Robert J Marks" <[email-masked]>
Date: Sat, 28 Dec 2002 09:01:43 -0600

Hi Yoshi,

If both may be present, then the MN-AAA extension MUST precede
the MN-FA extension, to allow the MN-FA extension to be removed
by the FA.

Bob

> [mailto:[email-masked]] On Behalf Of 
> Yoshiyuki Tsuda
> Sent: Saturday, December 28, 2002 5:03 AM
> To: Jayshree Bharatia
> Cc: [email-masked]'; [email-masked]'; 
> [email-masked]