Subject: RE:[CLARIFICATION] [mobile-ip] BU Authorization method: design team recommendation

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 6 Feb 2002 11:42:12 -0800

> 5. In order to guarantee security of the above exchange, the 
> HA-MN tunnel should be encrypted for the RR messages (but not 
> necessarily for other messages on this tunnel). Note that 

How does exposing the CN-HA link and protecting the HA-MN link
guarantee the security of the above exchange ? I am not disagreeing
with the proposal here. But I am not clear on the requirement of
the need for MN-HA link to be secured in the RR proposal. If I
did not protect the MN-HA link, the same attacks that are possible
on the CN-HA link are possible on this link also. Am I correct ?
So, the idea behind protecting the MN-HA link is to limit the
total number of attacks possible. Correct ? Or are there are
attacks specific to HA-MN link ?

thanks
-mohan

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Monday, February 04, 2002 1:01 PM
> To: [email-masked]
> Subject: [mobile-ip] BU Authorization method: design team 
> recommendation
> 
> 
> The MIPv6 security design team is trying to resolve the 
> issues around the method to use for authorizing binding updates.
> 
> This note specifies the design team's motivation and current 
> position. In order to move forward in an efficient manner it 
> would be beneficial if responses could make it clear they are
> - a clarification (by putting CLARIFICATION: in the Subject
>    field)
> - an issue with a particular point (by ISSUE:)
> - disagreement with the conclusion (by CONCLUSION:)
> 
> We would also like folks to state for each of our six 
> separate recommendations whether they AGREE, CAN TOLERATE, or 
> DISAGREE with them. In case of DISAGREE, please explain why.
> 
> 1. INTRODUCTION
> ===============
> 
> To date, various BU authorization methods have been proposed. 
> Of the proposals that don't assume a separate infrastructure 
> the properties they rely on are either RR and/or CGA 
> properties.  An analysis of the security properties of those 
> general categories of CGA and RR can be found at:
> 
>      
> http://www.piuha.net/~jarkko/publications/mipv6/Residual_Threats.txt
> 
> 2. ALTERNATIVES
> ===============
> 
> The main alternatives for the actual address ownership 
> authorization problem are:
> 
> (a) Return Routability, RR
> (b) RR enhanced with Cryptographically Generated Addresses, CGA
> 
> The security properties of these methods have been described
> in the URL referenced from section 1. In addition, there are 
> a few additional properties we would like to bring to the
> attention:
> 
> - CGA requires additional computational power. It is not
>    clear though if this is big enough requirement to be an
>    issue, particularly when very constrained nodes could
>    refuse RO, and given that it has been demonstrated that
>    protocols can be designed where MNs and CNs can offload
>    their expensive computations to their HAs.
> 
> - Several IPR claims have been made regarding CGA.
> 
> In addition to the basic mechanism there are a few additional 
> issues that we need to decide:
> 
> (i)  Whether or not Binding Security Associations (BSAs) are
>       used
> 
> (ii) What addresses need RR tests (HoA, CoA, or both), and
>       what is the correct time to perform the tests, always
>       at the time the binding is requested?
> 
> 3. RECOMMENDATIONS
> ==================
> 
> 1. The design team recommends a mandatory RR mechanism for
> IPv6 nodes, but with limitations on how long bindings can 
> stay alive before they need to be refreshed. This 
> recommendation is based on the findings of the security 
> analysis, which point to some deficiences in the RR method 
> below the "do no harm" principle, to which the limitations 
> provide a reasonable answer. The RR mechanism should be 
> placed in the MIPv6 RFC. Given that RR may not be sufficient 
> in all situations or may need to be replaced later with 
> something else, we recommend that a secure mechanism for 
> selecting different BU authorization methods, using the "bit 
> method" described in the URL referenced from section 1, is 
> included in this RFC as well.
> 
> 2. The design team additionally recommends an optional CGA 
> mechanism to be standardized in a separate RFC in the MIPv6 
> WG, using the above "bit method". This recommendation is 
> based on the findings of the security analysis, which point 
> to lesser signaling requirements and improved security 
> properties of CGA, as well as potential for solving 
> additional, IPv6 problems. Due to IPR and CPU consumption 
> concerns it seems problematic to make CGA a mandatory 
> requirement, however.
> 
> 3. Regarding issue (i), the design team recommends that the 
> RR method should not use a BSA since we already recommend 
> both HoA and CoA RR tests to be performed every time a 
> binding is refreshed or updated with RR. For CGA, the design 
> team recommends that a (simplified) BSA can be used to store 
> the Diffie-Hellman value generated as a part of the initial 
> binding, since with CGA, only the CoA test needs to be 
> performed on every binding refresh.
> 
> 4. Regarding issue (ii), the design team recommends both CoA 
> and HoA tests to be performed every time binding is refreshed 
> or updated with RR. We also recommend additionally that these 
> tests are made using separate requests in order to avoid 
> reflection problems with the authorization protocol itself (a 
> BU authorization request sent from the CoA should not be 
> answered to the HoA). This essentially leads to a five 
> message exchange that lasts 1.5 RTTs since because two pairs 
> of the messages can occur in parallel:
> 
> 1a. MN(HoA)--->HA--->CN
> 1b. MN(CoA)--------->CN
> 2a. CN-------->HA--->MN(HoA)
> 2b. CN-------------->MN(CoA)
> 3.  MN(CoA)--------->CN
> 
> 5. In order to guarantee security of the above exchange, the 
> HA-MN tunnel should be encrypted for the RR messages (but not 
> necessarily for other messages on this tunnel). Note that 
> there aren't similar scalability problems with this as there 
> are with MN-CN security, since the home agents and mobile 
> nodes must have an existing relationship anyway. This could 
> be done e.g. using IPsec ESP with pre-shared keys.
> 
> 6. For CGA, the design team recommends that 1a/2a can be 
> omitted for all but the initial exchange and periodic tests 
> every few hours or perhaps once a day.
> 
>

---

From: "Jari Arkko" <[email-masked]>
Date: Wed, 6 Feb 2002 22:20:24 +0200

the HA-MN link
>attacks specific to HA-MN link ?

Yes, the idea is to limit the attackers to those who are on
the HA-CN path. (Besides, security for the HA-CN path
would be hard or impossible to get anyway.)

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 7 Feb 2002 09:25:31 +0100 (CET)

> attacks specific to HA-MN link ?

Mohan,

The wording above is far from correct as you observe.

The intent was to say something more like 
	In order to minimize the exposure
	by preventing attacks on the path between the HA and MN, ...

There aren't any specific attacks on the HA-MN link - it is just a question
whether the attacker is on-path or off-path.
By protecting the HA-MN part of the path even on-path attackers on that part
of the path can't cause anything but DoS (by dropping packets).

   Erik