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>]

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. 

Thoughts, anyone? 

Vidya 

> -----Original Message-----
> From: Wassim Haddad [mailto:whaddad at tcs.hut.fi] 
> Sent: Sunday, July 30, 2006 7:57 AM
> To: Dondeti, Lakshminath
> Cc: mipshop at ietf.org; Suresh Krishnan
> Subject: Re: AR compromise (Re: [Mipshop] Review 
> ofdraft-haddad-mipship-hmipv6-security-04)
> 
> On Fri, 28 Jul 2006, Lakshminath Dondeti wrote:
> 
> > Continuing the discussion on the topic of using the AR as 
> the key distributor.
> 
> => You have mentioned in your first comment that you're not 
> familiar with HMIPv6. Add to this that am well aware that 
> you're opposed to any solution which is based on SEND 
> protocol... All this pushes me to remind you that this draft 
> is based solely on SEND to address a specific issue in HMIPv6.
> 
> > Generally speaking, edge entities are easy to physically 
> get access to 
> > and therefore easy to compromise.
> 
> => FYI, there is a much more interesting and objective 
> analyze of all these threats in RFC 3756 without mentioning a 
> very interesting *philosophy* which is worthy to become 
> familiar with to understand the importance of implementing 
> SEND protocol. Maybe you should take a look.
> 
> > The idea of AR as the key distributor to a network entity 
> and the MN 
> > seems to ignore that vulnerability.
> 
> => Your comment does not make sense because the proposal is 
> based on SEND protocol which aims to counter threats 
> mentioned in RFC3756, which include to some extent the threat 
> you're mentioning above.
> 
> > Note that in your protocol, a compromised AR can continue to send 
> > bogus BUs even after the MN has moved away from that AR.
> 
> => note also that a compromised AR can do *much* more damage 
> than sending bogus BUs messages.
> 
> > Suppose the credential verification is reliant on AAA servers, then 
> > the key management protocol would work even if the AR is 
> compromised.
> 
> => this solution does not aim to rely on AAA. It relies on 
> building a form of trust between the MN and the AR, which 
> starts by implementing the SEND protocol and on exploiting 
> the trust between the MN and the AR to establish a 
> bidirectional security association between the MAP and the MN.
> 
> If you have any comment against the SEND protocol then please 
> post them to the corresponding ML instead of trying to 
> mislead people on this ML by raising *any* kind of possible 
> issue including those already addressed in other 
> specification just because you don't like SEND based solution.
> 
> Concerning your previous comments, version 00 will be 
> submitted tomorrow so please wait for it before pursuing your 
> campaign!
> 
> 
> Wassim H.
> 
> 
> 
> > At 03:01 PM 7/28/2006, Suresh Krishnan wrote:
> >
> > >>Moving beyond that, having an AR distribute a key to the 
> MAP and MN 
> > >>seems to take the opposite view to the philosophy that the edge 
> > >>entities in a network are not as trustworthy as entities 
> deeper in 
> > >>the network.
> > >
> > >I am not sure I see why? Is this philosophy documented somewhere?
> > >
> >
> >
> > _______________________________________________
> > 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
> 

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