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

[Jari Arkko <jari.arkko at kolumbus.fi>]

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?

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