Re: [MEXT] [!! SPAM] Re: Well-known problem with authentication/etc. in wireless networks

[Jong-Hyouk Lee <[e-mail]>]

authentication for access network and authentication for binding update are
different.

On Thu, Aug 25, 2011 at 10:05 PM, <[e-mail]> wrote:

>
> That¹s a good summarization Pete.
> But we do multiple authentications today.
> We do access authentication (1) and then we have to authenticate with the
> HA yet again in (3).
> That could be optimized.
>
> -Raj
>
>
> On 8/25/11 2:54 PM, "ext Pete McCann" <[e-mail]> wrote:
>
> >Hi, Charlie,
> >
> >The problem seems to be we have the following three steps that have
> >to be carried out in order:
> >
> >1) access authentication
> >2) address assignment
> >3) mobility management
> >
> >(3) depends on (2) because you can't bind your home address to a
> >care-of address until you have a care-of address.  (2) depends on (1)
> >because operators don't like to give out resources until they know they
> >will get paid.
> >
> >It's possible to combine all these things into one protocol (perhaps PANA
> >could have been that vehicle, if certain decisions had not been made) but
> >the IETF seems to like breaking problems down into layered solutions.
> >
> >-Pete
> >
> >On Thu, Aug 25, 2011 at 3:19 PM, Charles E. Perkins
> ><[e-mail]> wrote:
> >> Hello Pete,
> >>
> >> Yes, putting Mobile IP inside of EAP would be one approach.
> >> It would have some interesting advantages.  Other approaches
> >> might be more properly done in [netext] -- or perhaps have
> >> already been looked; I could have possibly missed some of
> >> the relevant discussion there.
> >>
> >> Regards,
> >> Charlie P.
> >>
> >>
> >>
> >> On 8/25/2011 11:40 AM, Pete McCann wrote:
> >>>
> >>> Hi, Julien,
> >>>
> >>> Are you talking about EAP inside IKEv2?  That presupposes that the MN
> >>> is already attached to the network somewhere and has an IP address
> >>>(i.e.,
> >>> it has already passed access authentication).
> >>>
> >>> It may be interesting to look at whether access authentication and
> >>> mobility
> >>> management can be combined.  For example, we could put Mobile IP (or
> >>> some variant of it) inside an EAP exchange used for access
> >>>authentication.
> >>> Charlie, are you proposing something like this?
> >>>
> >>> -Pete
> >>>
> >>> On Thu, Aug 25, 2011 at 1:44 PM, Julien Laganier<[e-mail]
> >
> >>>  wrote:
> >>>>
> >>>> Charlie,
> >>>>
> >>>> I am not sure I understand what is missing in MIPv6; a MN and an HA
> >>>> can already mutually authenticate using EAP, and this is incidentally
> >>>> what 3GPP leverages on, together with the EAP-AKA method. What is
> >>>> missing?
> >>>>
> >>>> --julien
> >>>>
> >>>> On Wed, Aug 24, 2011 at 12:06 PM, Charles E. Perkins
> >>>> <[e-mail]>  wrote:
> >>>>>
> >>>>> Hello folks,
> >>>>>
> >>>>> It's now 2011.  Mobile IP was standardized late in
> >>>>> 1996, after work had already been started nearly
> >>>>> ten years before.  Over two decades! -- and regardless
> >>>>> of lip service to fixed/mobile convergence we still
> >>>>> don't have seamless mobility in user devices across
> >>>>> heterogeneous media, and standards organizations
> >>>>> (notably 3GPP) are not properly taking advantage of
> >>>>> what Mobile IP can do. The losers are the end-users,
> >>>>> which means all of us.
> >>>>>
> >>>>> There are many reasons for this, but one of the
> >>>>> main reasons has to do with authentication at the
> >>>>> access network.  EAP in various forms is being
> >>>>> utilized for this purpose, and Mobile IP is not,
> >>>>> even though there has never been any reported
> >>>>> failure of the RFC 5944 or RFC 4285 or RFC 6275
> >>>>> (to my knowledge).  Moreover, unless there is
> >>>>> something wrong with the cryptography that also
> >>>>> has not been reported, these authentication methods
> >>>>> enable _mutual_ authentication between the network
> >>>>> and the client, not just client authentication.
> >>>>>
> >>>>> In order for Mobile IP to enable the real promise
> >>>>> of high performance heterogeneous networking, we
> >>>>> have to do some more work.  I would like to initiate
> >>>>> some more discussion about this.  DMM is interesting
> >>>>> in its own right, but it's not at all the whole
> >>>>> story.  Moreover, with proper design, it is likely
> >>>>> the supposed burden of signaling to the home agent
> >>>>> can be substantially reduced.  As one simple example,
> >>>>> if handovers are accomplished locally between trusted
> >>>>> access agents (routers, 802.11 access controllers, ...)
> >>>>> then the actual timing of tunnel redirection from the
> >>>>> home agent becomes much less critical.  This is also
> >>>>> intricately intertwined with authentication.
> >>>>>
> >>>>> If the Home Agent were recognized as a robust security
> >>>>> appliance, then it could naturally sit on the network
> >>>>> boundary as an IP-addressable device.  Mobile IP
> >>>>> authentication could become the primary means of
> >>>>> validating user access, instead of an afterthought
> >>>>> to enable IP-address preservation after all the heavy
> >>>>> lifting has been done a lower levels.
> >>>>>
> >>>>> I would like to propose that in this working group we
> >>>>> should go about making this happen.  It seems to be
> >>>>> important, and undeniably aligned with our working
> >>>>> group responsibilities.
> >>>>>
> >>>>> Regards,
> >>>>> Charlie P.
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> MEXT mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/mext
> >>>>>
> >>>> _______________________________________________
> >>>> MEXT mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/mext
> >>>>
> >>>
> >>
> >>
> >_______________________________________________
> >MEXT mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/mext
>
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext
>



-- 
IMARA Team, INRIA, France.
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random.

#email: hurryon (at) gmail (dot) com || jong-hyouk.lee (at) inria (dot) fr
#webpage: https://sites.google.com/site/hurryon/