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

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 18 Dec 2002 15:44:48 -0800

Jayashree,

Section 3.2, (foreign agent processing of registration requests), describes how the
FA would process the MN-AAA extension. There is no section on how HA would process this
extension when it receives the request ? It is not that the details are different, but
i think it can be clarified a bit more. In the case you use the AAA infrastructure,
HA would receive the registration request from FA with the MN-AAA extension through the
AAA infrastructure and process it. In the case you use the CHAP_SPI mechanism,
FA does the MN-AAA verification and possibly strip the MN-AAA extension and passes
the registration request to HA. In this case it is not clear as to whether the extension
can be removed or not. There is some minimal description about "FA MUST NOT
remove the extension" unless MN-AAA is verified. Do you think it is worth clarifying ?

-mohan

 -----Original Message-----
From: Jayshree Bharatia [mailto:[email-masked]]
Sent: Tuesday, December 17, 2002 11:10 AM
To: [email-masked]'
Subject: [mobile-ip] RFC3012bis-04 Available

Hello all, 
New version of RFC3012bis (version 04) is now available at http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc3012bis-04.txt.
Thanks, 
Jayshree

---

From: "Jayshree Bharatia" <[email-masked]>
Date: Thu, 19 Dec 2002 17:47:09 -0600

Hello Mohan,

There is no MN-AAA extension processing done at the HA and hence we don't
have any section in RFC3012bis detailing it. This is regardless CHAP_SPI or
any other MIP SPI is used. We have some description on this in Appendix C
discussing the message flow. I would think that this should be sufficient
but let me know otherwise.

Thanks,
Jayshree

-----Original Message-----
From: Mohan Parthasarathy [mailto:[email-masked]]
Sent: Wednesday, December 18, 2002 5:45 PM
To: Bharatia, Jayshree [RICH1:2H13:EXCH]; [email-masked]
Subject: RE: [mobile-ip] RFC3012bis-04 Available

Jayashree,

Section 3.2, (foreign agent processing of registration requests), describes
how the
FA would process the MN-AAA extension. There is no section on how HA would
process this
extension when it receives the request ? It is not that the details are
different, but
i think it can be clarified a bit more. In the case you use the AAA
infrastructure,
HA would receive the registration request from FA with the MN-AAA extension
through the
AAA infrastructure and process it. In the case you use the CHAP_SPI
mechanism,
FA does the MN-AAA verification and possibly strip the MN-AAA extension and
passes
the registration request to HA. In this case it is not clear as to whether
the extension
can be removed or not. There is some minimal description about "FA MUST NOT
remove the extension" unless MN-AAA is verified. Do you think it is worth
clarifying ?

-mohan

 -----Original Message-----
From: Jayshree Bharatia [mailto:[email-masked]]
Sent: Tuesday, December 17, 2002 11:10 AM
To: [email-masked]'
Subject: [mobile-ip] RFC3012bis-04 Available

Hello all, 
New version of RFC3012bis (version 04) is now available at
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc3012bis-04.txt.
Thanks, 
Jayshree

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 19 Dec 2002 16:31:20 -0800

Jayashree,

>There is no MN-AAA extension processing done at the HA and hence we don't have any section >in RFC3012bis detailing it. This is regardless CHAP_SPI or any other MIP SPI is used.

Ok. It looks like the MN-AAA extension either gets removed at the AAAH (if you use
the verification infrastructure) or the FA (if you use the CHAP_SPI). It was not
very obvious until i read some other draft (Diameter Mobile IP application).
I got this confusion while reading the 3GPP2 spec which references RFC3012, where
it has decided to keep the MN-AAA extension as part of the Registration request
being forwarded to the HA and HA has a policy knob to process or not process it. Either
it was not very clear reading 3012 or they intentionally did it :-)

>We have some description on this in Appendix C discussing the message flow.
>I would think that this should be sufficient but let me know otherwise.

The diagram is clear. And if section 3.2 can say "MN-AAA extension is removed from
the registration request before forwarding to HA" would make it even more clear.

my 2 cents,
mohan

Thanks, 
Jayshree 
-----Original Message----- 
From: Mohan Parthasarathy [mailto:[email-masked]] 
Sent: Wednesday, December 18, 2002 5:45 PM 
To: Bharatia, Jayshree [RICH1:2H13:EXCH]; [email-masked] 
Subject: RE: [mobile-ip] RFC3012bis-04 Available 

Jayashree, 
 -----Original Message----- 
From: Jayshree Bharatia [mailto:[email-masked]] 
Sent: Tuesday, December 17, 2002 11:10 AM 
To: [email-masked]' 
Subject: [mobile-ip] RFC3012bis-04 Available 

Hello all,

---

From: "Kuntal Chowdhury" <[email-masked]>
Date: Fri, 20 Dec 2002 10:55:13 -0600

> Mohan Parthasarathy wrote:
> Jayashree,
> 
> >There is no MN-AAA extension processing done at the HA and hence we 
> >don't have any section >in RFC3012bis detailing it. This is 
> regardless 
> >CHAP_SPI or any other MIP SPI is used.
> 
> Ok. It looks like the MN-AAA extension either gets removed at 
> the AAAH (if you use the verification infrastructure) 

According to the DIAMETER-MIPv4 draft-13, the MN-AAA AVP is removed at
the AAAH (i.e. not present in HAR). However, MIP-Reg-Request AVP in the 
HAR may contain all the extensions including MN-AAA extension if the 
same was present in the RRQ from the MN. Therefore MN-AAA somehow makes 
its way the HA!

> or the 
> FA (if you use the CHAP_SPI). 

3012bis-04 draft does not say that FA removes the MN-AAA auth. extension
after verification, but it does make it clear that the MN-AAA is not
processed at the HA.

> It was not very obvious until i 
> read some other draft (Diameter Mobile IP application). I got 
> this confusion while reading the 3GPP2 spec which references 
> RFC3012, where it has decided to keep the MN-AAA extension as 
> part of the Registration request being forwarded to the HA 
> and HA has a policy knob to process or not process it. Either 

Actually, in the latest release of the 3GPP2 standard, there is an
indication
(VSA) passed from the AAAH to the FA to indicate whether to remove the
MN-AAA
and MN-FA auth. extensions before relaying the RRQ to the HA.

-Kuntal

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 20 Dec 2002 09:24:23 -0800

Ok, thanks for the clarification. 

It says "It MUST NOT remove the extension without verification".  It sort

of hints that you can remove it after verification. And this is what i want

to clarify. If it is going to be present when it passed through the

verification infrastructure,  it looks like there is even more need to clarify this.

> it was not very clear reading 3012 or they intentionally did it :-) 

Actually, in the latest release of the 3GPP2 standard, there is an indication 
(VSA) passed from the AAAH to the FA to indicate whether to remove the MN-AAA 
and MN-FA auth. extensions before relaying the RRQ to the HA.  

Ok.

-mohan

-Kuntal

---

From: "Kuntal Chowdhury" <[email-masked]>
Date: Fri, 20 Dec 2002 15:02:28 -0600

>Ok, thanks for the clarification. 

If using DIAMETER mobile IP verification infrastructure, the HA will receive
the MN-AAA (embedded in the MIP-Reg-Request AVP). In that case, perhaps we
should not change the behavior of the HA while using the RADIUS verification

infrastructure.

I suggest we either remain silent about what FA does with MN-AAA auth
extension 
after successful verification and leave it upto local policy, or we
explicitly say 
that the "FA MUST NOT remove MN-AAA extension from the Registration
Request". 

I think the latter approach is preferable since it makes the HA (and
somewhat FA) behavior consistent while using two different (RADIUS and
DIAMETER) verification 
infrastructures. The former approach is analogous to what 3GPP2 already
defined.

Regards,
Kuntal

---

From: "Jayshree Bharatia" <[email-masked]>
Date: Mon, 23 Dec 2002 14:29:35 -0600

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

> From: Yoshiyuki Tsuda [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
> >
> >From: Yoshiyuki Tsuda [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
> >>
> >>
> >>From: Yoshiyuki Tsuda [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,
> >>>

---

From: "Woojune Kim" <[email-masked]>
Date: Mon, 30 Dec 2002 10:39:27 -0500

It seems these discussions on the order of the authentication extensions keep on coming up.
Can't we just put in a section that describes the order instead of relying on people's understanding of text rules ?
i.e. 

It seems 

MN_HA -> MN-AAA -> MN-FA 

seems to be the rough order. If any one of them is not used, it is skipped. 

The generalized AAA extensions for other cases such as regional authentications etc. will also need to be kept in mind. So this probably will NOT as simple as I have stated above, but it may be a start.

Any takers ?

>From: Robert J Marks [mailto:[email-masked]]
>Sent: Saturday, December 28, 2002 10:02 AM
>To: 'Yoshiyuki Tsuda'; 'Jayshree Bharatia'
>Cc: [email-masked]; [email-masked]
>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
>
>> From: [email-masked] 
>> [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]
>> 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
>> 
>> at Mon, 23 Dec 2002 15:32:30 -0600, Jayshree Bharatia wrote:
>> >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
>> >
>> >From: Robert J Marks [mailto:[email-masked]]
>> >Sent: Monday, December 23, 2002 2:58 PM
>> >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
>> >
>> >From: [email-masked]
>> >[mailto:[email-masked]] On Behalf Of 
>> Jayshree Bharatia
>> >Sent: Monday, December 23, 2002 2:30 PM
>> <mailto:[email-masked]'>
>> >
>> >Subject: FW: [mobile-ip] RFC3012bis-04 Available
>> >
>> >
>> >
>> >
>> >
>> >> From: Yoshiyuki Tsuda [ mailto:[email-masked]
>> ><mailto:[email-masked]> ] 
>> >> >From: Yoshiyuki Tsuda [ mailto:[email-masked]
>> ><mailto:[email-masked]> ] 
>> >> >>From: Yoshiyuki Tsuda [ mailto:[email-masked]
>> ><mailto:[email-masked]> ] 
>> >> >>> 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 
>> 
>
>