Subject: [mobile-ip] RE: mobile authentication inconsistencies, resend

From: "Jayshree Bharatia" <[email-masked]>
Date: Tue, 6 May 2003 14:08:14 -0500

Hi Ali,

Please see my comments inline.

Regards,
Jayshree
 
> --------- RFC3012bis-04, section 3.2, bottom of page 6 ---------
> 
> "The Foreign Agent MUST NOT remove the MN-AAA Authentication 
> Extension from the Registration Request prior to the 
> completion of the authentication performed by the AAA infrastructure."
> 
> replace this sentence with:
> 
> "The Foreign Agent MUST NOT remove the MN-AAA Authentication 
> Extension and the FA-Challenge extension from the 
> Registration Request when forwarding the message to the Home Agent."
> 
> OR, for more local policy flexibility:
> 
> "Unless explicitly instructed by the AAA infrastructure to 
> remove the MN-AAA Authentication Extension and the 
> FA-Challenge extension, the Foreign Agent MUST NOT remove 
> these extensions from the Registration Request when 
> forwarding the message to the Home Agent."
> 
[JB] Currently I have added the following text:
"The Foreign Agent MUST NOT remove the Mobile-AAA Authentication Extension
from the Registration Request."

> --------- RFC3012bis-04, section 6 ---------
> 
> Insert section 6.1:
> 
> 6.1 Co-Located Mobile Node Processing
> 
> When the mobile is registering in co-located mode, depending 
> on local policy, it may randomly choose a challenge value, 
> and compute the MN-AAA authenticator. A mobile which does so, 
> MUST include the challenge value it chose in the FA-Challenge 
> extension field and the MN-AAA authenticator it calculated in 
> the MN-AAA Authentication extension field of the mobile-ip 
> registration request it generates.
>
[JB]I have modified your text as below: 

"Based on local policy, a Mobile Node with co-located care-of-address MAY 
include the Mobile-AAA Authentication extension in Registration Request. 
In this case, the Mobile Node MUST include the Mobile-Foreign Challenge 
extension prior to the Mobile-AAA Authentication extension. The mechanism 
used by the Mobile Node to obtain the Challenge value is outside the scope 
of this document."

I would think that this new text will be best fitted in section 3.1 
as a last paragraph).

Please let me know if you have any comments/suggestions.

---

From: Yoshiyuki Tsuda <[email-masked]>
Date: Wed, 07 May 2003 16:21:06 +0900

Hello Jayshree,

 Just one comment about modification of RFC3012bis-04,
 section 6.1:
 If an MN and an AAA use other than chap, the Mobile-
 Foreign Challenge extension may not be required.  So,
 I think, "the mobile node MAY include the mobile-foreign
 challenge extension ..." is better.

Thanks.
-Yoshi

---

From: Bjorn Andersson <[email-masked]>
Date: Wed, 7 May 2003 10:30:36 +0300

> Please let me know if you have any comments/suggestions.

At least I object to the idea that the MN may choose that challenge
value itself. What kind of challenge/response protocol would that be?
In the case of how the CHAP authenticator is defined, it may be argued
that the ID field in the RR header is the challenge, and that this
will be included in the MD5 calculated over the RR message. But then
again, the reason why the least-order 237 bytes from the FA challenge was
included in the CHAP challenge (even though the FA challenge is included
in the RR message as an extension) was that MD5 alone is not secure
enough. If this is the case, then the mobile node must not for the same
reason be allowed to select this challenge itself.

I suggest that the MN uses the ID field as the challenge in the same
way as the FA challenge, if the FA challange is not available. Although
it would be redundant information, the MN could add the ID field in
a challenge extension to make everybody happy.

  Bjorn

-- 
Bjorn Andersson <[email-masked]>
PGP id 5AFC144B
Mobile +358 40 7723074