Subject: [Mip6] FW: Request security perspective for Mobile IPv6 I-D [Auth-protocol]

From: [email-masked]
Date: Fri, 15 Oct 2004 08:43:51 -0500

Feeback from the security directorate on the Auth-protocol proposal.

-BPa

> -----Original Message-----
> From: ext Radia Perlman [mailto:[email-masked]]
> Sent: Thursday, October 14, 2004 6:34 PM
> To: Russ Housley
> Cc: [email-masked]; Patil Basavaraj 
> [email-masked]; [email-masked]
> Subject: Re: Request security perspective for Mobile IPv6 I-D
> 
> 
> I'd like to see more description of why IPsec is not compatible with 
> MIP6. Unless
> there's something really special about MIP6, then if IPsec won't meet 
> their needs
> or is too much work, then IPsec should be changed.
> 
> If inventing a new mechanism is because of a short term "this is what 
> the implementations
> are doing now", I think instead it would be better to switch 
> to IPsec, 
> so that there
> aren't lots of different security protocols being invented.
> 
> Admittedly, IPsec has a bunch of functionality that you don't 
> need, like
> encryption and perfect forward secrecy. So your mechanism is 
> certainly 
> simpler.
> If it was implementing that instead of IPsec, then certainly I could 
> imagine the
> appeal. However, if the node will wind up implementing IPsec 
> anyway, it 
> doesn't
> seem like it should be that hard to use it for MIP6. But 
> maybe I don't 
> understand
> the issues (like why existing hardware doing IPsec would have to be 
> modified to
> support MIPv6....maybe because the existing hardware is only 
> doing IPv4, 
> in which
> case the hardware would just ignore IPv6 packets, I'd assume, 
> so maybe 
> that's
> what you mean...that you'd have to change the hardware to do 
> IPsec for 
> IPv6).
> 
> Aside from whether there should be another mechanism, the 
> only issue I 
> could see
> is how you avoid replay. With the "identification option" you 
> make sure 
> that an
> old message outside of the acceptable window will be 
> discarded. But if 
> the acceptable
> window were, say, 10 minutes, then it would seem like an 
> attacker would 
> be able
> to continue to replay a message for 10 minutes (or worse, if the 
> client's clock is
> n minutes ahead of the server's).
> 
> Radia
> 
> 
> 
> Russ Housley wrote:
> 
> > Radia and Sam:
> >
> > Please review for the Security Directorate.
> >
> > Please respond directly to [email-masked] and 
> > [email-masked], but CC [email-masked] and 
> > [email-masked] too.
> >
> > Russ
> >
> >
> > > -----Original Message-----
> > > From: Patil Basavaraj 
> > > Sent: Thursday, October 07, 2004 1:56 PM
> > > To: [email-masked]; [email-masked]
> > > Cc: Thomas Narten; Gopal Dommety (E-mail); Margaret 
> Wasserman (E-mail)
> > > Subject: Request security perspective for Mobile IPv6 I-D
> > >
> > > Hello Security ADs,
> > >
> > > The Mobile IPv6 WG is currently proposing a mechanism to allow a
> > > Mobile node (MN) to register with its Home agent (HA) via an
> > > authentication mechanism which involves carrying Auth-Data via
> > > an authentication-data-suboption within the binding
> > > update/Ack messages.
> > > This mechanism is akin to the one that is currently used in Mobile
> > > IPv4.
> > > RFC3775/6 which specify Mobile IPv6, currently mandate the
> > > establishment
> > > of an IPsec SA between the MN and HA and thus 
> authentication of the MN
> > > is achieved via the presence of this SA. The Binding
> > > update/Ack messages
> > > are secured using IPsec ESP (from the MN-HA SA).
> > >
> > > The proposal to authenticate a MN to its HA in the 
> absence of an IPsec
> > > SA is specified in I-D:
> > > 
> http://ietf.org/internet-drafts/draft-ietf-mip6-auth-protocol-00.txt
> > >
> > > The justifications for why this is needed are contained in:
> > > http://ietf.org/internet-drafts/draft-patil-mip6-whyauthdataop
> > tion-00.txt
> > as well as some additional justifications at:
> > http://www1.ietf.org/mail-archive/web/mip6/current/msg01657.html
> >
> > We would appreciate your views from a security perspective on 
> > standardizing
> > the authentication of a MIP6 MN to its HA using Auth-data 
> carried in 
> > the BU.
> >
> > Rgds,
> > -Basavaraj
> 
> 
> 
> 

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