RE: SEND-based protection and related confusions (was RE: AR compromise(Re: [Mipshop] Review ofdraft-haddad-mipship-hmipv6-security-04))

["Narayanan, Vidya" <vidyan at qualcomm.com>]

In the HMIP model (as in any host-based mobility model), I do feel
strongly that the compromise of an AR must not cause spurious binding
cache entries at the MAP on behalf of the MN. As we move towards a model
of distributed systems and IP all the way to the edge, the concern of
domino effects is higher. So, brokering a trust relationship between the
MN and the MAP by the AR providing a key and then doing a DH exchange is
not attractive to me. If we want to leverage the presence of CGAs, we
could perhaps go down the path of IKEv2 using CGAs/self-signed certs,
etc. We have to keep in mind that this is not equivalent to simple IPsec
or IKEv2/EAP, but, in the interest of infrastructureless security, it
can be done. Doing IKEv2 has several advantages, including the fact that
you can then use IPsec as the secure channel. IKEv2 employs a well
designed authenticated DH exchange that provides several useful
properties and if we are going to take on a DH-based approach, it makes
sense to use IKEv2. 

If SEND is used, it will protect the MAP advertisement coming from the
AR - so, that communication can be independently protected. 

Vidya

> -----Original Message-----
> From: Lakshminath Dondeti [mailto:ldondeti at qualcomm.com] 
> Sent: Tuesday, August 15, 2006 8:27 AM
> To: Jari Arkko; James Kempf; Narayanan, Vidya
> Cc: mipshop at ietf.org
> Subject: Re: SEND-based protection and related confusions 
> (was RE: AR compromise(Re: [Mipshop] Review 
> ofdraft-haddad-mipship-hmipv6-security-04))
> 
> At 06:47 AM 8/15/2006, Jari Arkko wrote:
> >James Kempf wrote:
> >
> > > Agree with all these points. RFC 3756 and the SecCon 
> section of 3971 
> > > describe what protection SEND does and doesn't provide.
> >
> >Agree about the parts concerning SEND. I still need to read more to 
> >understand the HMIP part of this argument, so I am not commenting on 
> >that.
> >
> > > Also, it is important to distinguish between SEND and 
> CGAs. RFC 3792 
> > > describes how CGAs work, and the protection described 
> there can be 
> > > applied to other protocols that use CGAs, but care is needed to 
> > > ensure that the protection properly to the appropriate threats.
> >
> >Indeed. One bit of history that may be interesting: we considered an 
> >earlier SEND design that would also have provided subsequent payload 
> >traffic protection, and not just ND protection. There are plenty of 
> >security mechanisms, but the interesting part is usually in how they 
> >are applied for a given problem. If a component such as SEND 
> or CGA is 
> >used in a new application, you would expect that the 
> specific needs of 
> >the application are addressed. Either by choosing the right 
> underlying 
> >components or extending them to do the necessary things.
> >
> >But back to today's problem: do we know what the requirements for a 
> >HMIP security solution are? I'm not sure I want to discuss 
> what nodes 
> >should be involved yet. Rather, what are the resources and messages 
> >that need protection?
> 
> Good question.  I started with 4140's security 
> considerations; that seems like a good starting point.
> 
> Lakshminath
> 
> 
> >--Jari
> >
> > >                jak
> > >
> > > ----- Original Message ----- From: "Narayanan, Vidya"
> > > <vidyan at qualcomm.com>
> > > To: <mipshop at ietf.org>
> > > Sent: Tuesday, August 01, 2006 2:47 PM
> > > Subject: SEND-based protection and related confusions (was RE: AR
> > > compromise(Re: [Mipshop] Review
> > > ofdraft-haddad-mipship-hmipv6-security-04))
> > >
> > >
> > > I want to get a clear understanding myself on what SEND 
> provides and 
> > > what it doesn't. I seem to have an understanding that is 
> different 
> > > from some views here. For instance, the following email seems to 
> > > allude that SEND protects against AR compromise. In some previous 
> > > discussions, I heard the views that once an MN and AR use 
> SEND, that 
> > > link is now secure. Either I am terribly mistaken in my 
> reading of 
> > > RFCs 3756, 3971 and 3972 or these misconceptions really need to 
> > > cleared up, before we build more protocols based on SEND.
> > >
> > > I want to state upfront that I have nothing against 
> enhancing SEND 
> > > to protect other protocols or providing other functionality. I am 
> > > only questioning some of the fundamental assumptions being made 
> > > about the protection provided by SEND itself. Here are 
> some points 
> > > that I think are worth getting clarity on.
> > >
> > > 1. SEND protects ND messages only - this does not extend any 
> > > protection whatsoever to any future messages exchanged 
> between the 
> > > MN and any entity in the network, including the AR.
> > >
> > > 2. SEND itself DOES NOT protect against AR compromises. In fact, 
> > > RFC3756 seems to explicitly bring this to attention in 
> section 4.2.3 
> > > - "There are currently no known solutions for any of the 
> presented 
> > > three trust models."
> > >
> > > 2a. In the case of SEND itself, the AR is one of the signaling 
> > > endpoints and nothing can be done about compromise of that.
> > >
> > > 2b. In the case of protocols such as HMIP, the AR has no 
> need to be 
> > > involved in the protocol. Hence, a compromise of the AR must not 
> > > result in issues with respect to the protocol operation 
> (note: this 
> > > is only referring to the operation of the particular protocol in 
> > > question, not a general routing problem or DoS attack 
> issue per say).
> > >
> > > 3. SEND DOES NOT protect against MiTM attacks on other messaging 
> > > exchanged on the link (even if it is between the same two 
> nodes that 
> > > executed SEND).
> > >
> > > A reasonable extension to SEND for other purposes would be when a 
> > > key is exchanged to be shared between the same two 
> entities that executed SEND.
> > > Brokering trust relationships between other entities 
> based on SEND, 
> > > given that ARs are edge entities and given that SEND only 
> protects 
> > > ND messages, does not seem quite right to me.
> >
> >
> >
> >_______________________________________________
> >Mipshop mailing list
> >Mipshop at ietf.org
> >https://www1.ietf.org/mailman/listinfo/mipshop
> 
> 

_______________________________________________
Mipshop mailing list
Mipshop at ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop