Re: [Mip6] Summary of Justification for Alternative Authentication Option

[Gopal Dommety <[e-mail]>]

Francis,

please see inline...

At 07:27 PM 9/26/2004 +0200, Francis Dupont wrote:
>  In your previous mail you wrote:
>
>    Summary
>    =======
>
>    The WG has been engaged in a discussion over the last week on the
>    topic of standardizing an authentication date suboption based
>
>=> I believe "standardizing" means to make it a Proposed Standard,
>doesn't it?


Yes.


>    mechanism for the purpose of registering an MN with its HA via the
>    BU/BAck messages.
>    To summarize the discussion in brief:
>    1. The I-D draft-patil-mip6-whyauthdataoption-00.txt was used as the
>        baseline for the discussion
>    2. Opinion was expressed that the I-D was more inclined in justifying
>        why the use of  IKE was a problem for setting up the MN-HA IPsec SA
>        and not really providing sufficient justifications for an
>        alternative scheme to the use of IPsec for securing the signaling
>        messages between the MN and HA
>    3. There were a few people who expressed strong views of keeping IPsec
>        as the only means for MIP6 security between MN and HA (Francis and
>    Hesham (?))
>    4. There were others who claimed the need for an alternate option to
>        MIP6 including one operator who plans to deploy the protocol in
>        their network (Raj, James Kempf, Alpesh, Gopal, Kuntal, Vijay,
>        Michael Roe)
>
>=> you should be more accurate: just alternate option or standardized
>alternate option?
>
>    5. There was also a note from an implementers perspective on the
>        challenges of integrating MIP6 with IPsec (Michael Roe)
>    6. There was discussion about the problem of replay attacks and the
>        need for key refreshment
>    7. IKEv2 is expected to provide a solution to the problem of setting
>        up dynamic SAs in networks that rely on AAA infrastructures. While
>        IKEv2 itself has been approved, the details of how IKEv2 is used
>        with MIP6 are still being worked out in an I-D that is not ready
>        yet.
>
>=> IMHO the main problem with an IKEv2 based solution is that there is
>no public implementation... Another point is that IKEv2 does not support
>home agent allocation.
>
>    8. There was an opinion that the bootstrap work being done in the WG
>        would address the needs of the environment claimed in I-D
>        draft-patil-mip6-whyauthdataoption-00.txt
>
>=> some AAA/EAP based solutions are already ready (i.e., implemented)
>and of course they support home agent allocation.
>
>There are some other points:
>  - we were supposed to ask an advice from security area directors
>  - the requirement level of auth data option is still not clear enough
>  - if the auth data option is only for the 3GPP2 environment there is
>    no reason to standardize it at the IETF: the 3GPP2 can require what
>    it wants in its own environment. If it likes to get an IETF document,
>    an informational RFC should be enough and even faster (less possible
>    concerns from the IESG).
>Some of these points were already mentioned on the list...
>
>Regards
>
>[e-mail]
>
>_______________________________________________
>Mip6 mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/mip6


_______________________________________________
Mip6 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mip6