RE: [Mip6] Summary of Justification for AlternativeAuthenticationOption

[[e-mail]]

James,

I disagree with the need for having such a mechanism in view of the fact
that an HA is expected to support both the authentication schemes mandatorily.

-BPa

> 
> Gopal,
> 
> I believe you missed the need for some mechanism to allow an 
> MN to determine
> which authentication technique to use. Without this, there is an
> interoperability problem, because the MN cannot infer simply from the
> failure of the signaling that it should try the other method.
> 
>             jak
> 
> ----- Original Message ----- 
> From: "Gopal Dommety" <[e-mail]>
> To: <[e-mail]>
> Sent: Thursday, September 23, 2004 2:55 PM
> Subject: [Mip6] Summary of Justification for Alternative
> AuthenticationOption
> 
> 
> > Hello All,
> >
> >              I am attaching a summary of the discussion 
> that took place on
> > justification of an alternate authentication mechanism.  
> Please let me
> know if
> > I have left out any important issue in the summary. I could 
> have also
> mis-read
> > people opinions, so if there is a correction please let me 
> know. I will
> > send a follow-up
> >   email with the next steps.
> >
> >
> > Thanks,
> > -Gopal
> >
> >
> > Summary
> > =======
> >
> > The WG has been engaged in a discussion over the last week on the
> > topic of standardizing an authentication date suboption based
> > 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)
> > 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.
> > 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
> >
> >
> > _______________________________________________
> > Mip6 mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/mip6
> >
> 
> 
> 
> _______________________________________________
> Mip6 mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mip6
> 

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