Subject: Re: [MOBILE-IP] MOBILE-IP] Are Mobile-Home Authentication's optional ?

From: Woo-June Kim <[email-masked]>
Date: Wed, 8 Mar 2000 09:15:22 +0900

Pat, 

From your answer I can see that you are considering a wider possibility - the chance that even the HA may not be trusted by the MN. A case that becomes possible when dynamic HA allocation becomes available (and not according to the scheme of using the subnet broadcast address as originally mentioned in RFC2002 as that case could assume a trust relationship between the HA and the MN).

But as Gopal mentioned in the earlier attached e-mail, how is the information that the MN's registration request trustworthy going to be conveyed to the HA in the absence of a

1) MN-HAAA authentication
2) MN-HA authentication.

It seems to me the HAAA would have to tell the HA by some means that "in the future you will receive a registration request from MN and it has already been authenticated at the FA". Which raises the question of identifying the message securely. i.e. When the request is received how can the HA be sure it is the request the HAAA was talking about ? What if there was an imposter in the middle ? 

It seems to me the only reasonable answer would be to include the MN-HAAA authentication extension in the registration request to the HA. Then for such cases as you mention where the HA is assigned dynamically (including cases where the HA is now in a domain with no trust relationship with the MN) then the MN may be authenticated by the MN-HAAA authentication. For cases where there is a preexisting trust relationship, the MN-HA authentication field would/could be used. 

If this scenario is followed, under what conditions can the MN-HAAA authentication extension be removed by the FA ? It seems to me, only when there is a MN-HA authentiation extentsion, implying the MN has a trust relationship with the HA. If there is no MN-HA authentication extension, the MN-HAAA authentication must be left in the message for the HA to use for verification. If the HAAA can somehow instruct the HA to except messages (as mentioned by Gopal) fine, but if not, the HA goes through the whole authentication routine again with the MN-HAAA authentication extension.

Of course if a framework like DIAMETER  was used, whereby the AAA will relay the registration messages itself, your statements above are fundamentally correct. But if we stay with the model where the path of the registraion request/reply messages is different from the AAA authentication path, we end up with the problem that both Gopal and I have raised.

cheers

Woojune Kim

>Since the HA inherently trusts its AAA server (and if it doesn't then we have
>a problem), if the AAAH states that the Mobile Node was authenticated, why
>does the HA have to also authenticate the user?
>
>Further, if we mandate MN-HA, then we need to push the Mobile Node's secret to
>the HA, and if the HA lives in a non-trusted domain (e.g. HA in foreign
>domain), why would you want to provide the MN's password to it?
>
>PatC
>>>
>>>Anyway your answer brings more questions to my mind.
>>>
>>>The challenge/response draft says the MN-AAA authentication extension can be
>>removed by the FA after authentication is carried out by some means at the FA.
>>(by an AAA infra etc.)
>>>
>>
>>Woo, I agree with you.
>>
>>Charlie,
>>
>>To add even if the MN-AAA is not removed, since the HA will not authenticate
>>based of HA-AAA, how will the
>>HA authenticate the MN? Is the assumption that HA will be instructed to by the
>>HAAA to accept the MN? (Note: I am not
>>sure if this is good or bad.  I would like to understand the motivation for the
>>Statement about HA-MN being optional).
>>
>>Thanks
>>Gopal
>>
>>
>>>If the MN-AAA authentication is removed, and there is no MN-HA authentication,
>>by what means will the HA be able to authenticate the message ? Are you not
>>assuming that in such a case the MN-HA authentication is used ?
>>>
>>>My understanding leads me to assume that in case either an MN-AAA
>>authentication or MN-HA authentication extension will always be in a
>>registration request received by the Home Agent. But the current wording of the
>>document seems to able to lead to cases where the FA implementation could remove
>>an MN-AAA authentication extension even when an MN-HA authentication does not
>>exist.
>>>
>>>Please correct me if I'm wrong again.
>>>(by the way then I believe the wording of
>>>
>>>"..........
>>>   Since the Challenge extension, and the authentication extension that
>>>   is used by the Mobile Node to satisfy the challenge, both follow
>>>   the Mobile-Home Authentication extension whenever the latter is
>>>   present, the Foreign Agent MAY remove the Challenge Extension and
>>>   the applicable authentication from the Registration Request without
>>>   disturbing the authentication value computed by the Mobile Node for
>>>   use by the Home Agent.
>>>........"
>>>
>>>should be changed (Is the first sentence grammatically correct ?)
>>>to reflect the fact that the MN-AAA authentication can only be removed if there
>>is a MN-HA authentication extension.
>>>)
>>>
>>>cheers
>>>
>>>Woojune Kim,
>>>Senior Engineer
>>>Samsung Electronics Ltd.
>>>tel : +82-342-779-8526
>>>hp : +82-11-368-7480
>>>e-mail : [email-masked]
>>>
>>>
>>>>
>>>>Hello,
>>>>
>>>>Woo-June Kim wrote:
>>>>
>>>>> To me even if FAC is used, I don't quite see how it nullfies the need for
>>>>> the MN-HA authentication field.
>>>>
>>>>The Challenge specification was written after the MN-NAI specification,
>>>>and the MN-NAI specification allows a MN-AAA authentication extension
>>>>to take the place of the MN-HA authentication extension.
>>>>
>>>>Regards,
>>>>Charlie P.
>>>>
>>>
>>Thank You.
>>Regards,
>>Gopal
>>-------------------------------------------------------------------------------------------------------------
>>
>>Gopal Dommety
>>408 525 1404
>>[email-masked]
>>Cisco Systems, San Jose, CA, 95051
>

---

From: Patrice Calhoun <[email-masked]>
Date: Wed, 8 Mar 2000 13:08:27 -0800

One more time.....

I never stated the Mobile was inherently trusted. Yes, if the MN-HA is not
present, then the MN-AAA MUST be present (which is what started this whole
thread to begin with, I believe).

PatC
>Pat,
>
>From your answer I can see that you are considering a wider possibility - the
>chance that even the HA may not be trusted by the MN. A case that becomes
>possible when dynamic HA allocation becomes available (and not according to the
>scheme of using the subnet broadcast address as originally mentioned in RFC2002
>as that case could assume a trust relationship between the HA and the MN).
>
>But as Gopal mentioned in the earlier attached e-mail, how is the information
>that the MN's registration request trustworthy going to be conveyed to the HA in
>the absence of a
>
>It seems to me the HAAA would have to tell the HA by some means that "in the
>future you will receive a registration request from MN and it has already been
>authenticated at the FA". Which raises the question of identifying the message
>securely. i.e. When the request is received how can the HA be sure it is the
>request the HAAA was talking about ? What if there was an imposter in the middle
>?
>
>It seems to me the only reasonable answer would be to include the MN-HAAA
>authentication extension in the registration request to the HA. Then for such
>cases as you mention where the HA is assigned dynamically (including cases where
>the HA is now in a domain with no trust relationship with the MN) then the MN
>may be authenticated by the MN-HAAA authentication. For cases where there is a
>preexisting trust relationship, the MN-HA authentication field would/could be
>used.
>
>If this scenario is followed, under what conditions can the MN-HAAA
>authentication extension be removed by the FA ? It seems to me, only when there
>is a MN-HA authentiation extentsion, implying the MN has a trust relationship
>with the HA. If there is no MN-HA authentication extension, the MN-HAAA
>authentication must be left in the message for the HA to use for verification.
>If the HAAA can somehow instruct the HA to except messages (as mentioned by
>Gopal) fine, but if not, the HA goes through the whole authentication routine
>again with the MN-HAAA authentication extension.
>
>Of course if a framework like DIAMETER  was used, whereby the AAA will relay the
>registration messages itself, your statements above are fundamentally correct.
>But if we stay with the model where the path of the registraion request/reply
>messages is different from the AAA authentication path, we end up with the
>problem that both Gopal and I have raised.
>
>cheers
>
>Woojune Kim
>
>
>