Subject: Re: I-D ACTION:draft-ietf-send-psreq-00.txt

From: Pekka Savola <[email-masked]>
Date: Sun, 17 Nov 2002 16:16:20 +0200 (EET)

Ooops sent the previous by accident, let's try again..

On Fri, 18 Oct 2002 [email-masked] wrote:
> 	Title		: IPv6 Neighbor Discovery trust models and threats
> 	Author(s)	: P. Nikander
> 	Filename	: draft-ietf-send-psreq-00.txt
> 	Pages		: 13
> 	Date		: 2002-10-17
> 	
> The existing IETF standards specify that IPv6 Neighbor Discovery
> and Address Autoconfiguration mechanisms MAY be protected with
> IPsec AH.  However, the current specifications limit the security
> solutions to manual keying due to practical problems faced with
> automatic key management.  This document specifies three different
> trust models and discusses the threats pertient to IPv6 Neighbor
> Discovery.  The purpose of this discussion is to define the
> requirements for Securing IPv6 Neigbor Discovery.

Hopefully the comments aren't completely ignored as the last two times 
(for netaccess-threats).

Anyway..

Substantial:

1) I think there should be another trust model, or s subcategory of one: 
"semi-trusted".  Model 1 is useless other than as a trust model of the 
current state.  E.g. intranet nodes really _should_ be semi-trusted, not 
completely trusted.  Semi-trusted network would have to be protected from 
packet hijacking, MITM, etc. -- but not necessarily DoS attacks.

Another possible way to tackle this would be to add "Trusted Host Goes 
Bad" threat -- ie. a node in a "trusted" network is compromised.

2) Bogus On-Link Prefix threat appears to be much worse than DoS, rather a 
redirect: why couldn't the attacker just fabricate the NA responses for 
bogus On-Link prefixes and claim the traffic (and perform MITM or 
whatever)?  (E.g. to capture www.hotmail.com traffic, advertise their 
prefixes as on-link)

3) Bogus Address Configuration Prefix threat appears to be a bit more 
complex than that.  If a dynamic DNS update is done, this can be made to 
do very much harm; in particular, to spoof forward + reverse DNS checks.  
Example:
 
 1. figure out the EUI64 address of the victim node, here <VICTIM>::<IID>
 2. make your own node (somewhere in the internet) be a <ATTACKER>::<IID>.
 3. configure the reverse of the attackers node, above, be 
<VICTIM>::<IID> --> "secure.victim.com".
 4. advertise an address config prefix of <ATTACKER>::/64
 5. victim configures <ATTACKER>::<IID>, and updates DNS so that 
"secure.victim.com" (also) points to <ATTACKER>::<IID>

Reverse DNS spoof is ready.

Editorial:

==> many places: the "The threat involves XXX" is written in many forms 
(with/without "/" and with/without "messages") -- make more uniform.

   There are two general types of threats:

      1) Redirect attacks in which a malicious node redirects packets
         away from the last hop router to another node on the link.

==> generalize "Redirect attacks"
==> generalize "last hop router": in the threats any node can be 
compromised like this

   A redirect attack can be used for DoS purposes by having the node to

==> s/can be/can also be/

4.1     Non router/routing related threats

   In this section we discuss attacks against "pure" Neighbor
   Discovery functions, i.e., Neighbor Discovery, Neigbor
   Unreachability Discovery, and Address Autoconfiguration.

==> "Duplicate Address Detection in Address Autoconfiguration"
(else "router" -related threats isn't really applicable)

   Nodes on the link use Neighbor Solicitation and Adverticement

==> s/Adverticement/Advertisement

   Nodes on the link monitor the reachability of local destinations
   and routers with the Neighbor Unreachability procedure [RFC2461].

==> s/NU/NUD/ ?

   could launch a DoS attack by responding to every duplicate address
   detection attempt by an entering host.  If the attacker claims the
  
==> s/by/made by/ (or tried by)

   or not.  In the trusted operator case, the operator may acts as an

==> s/may acts/may act/

         to answer the stateful configuration queries of a legitmate

==> s/legitmate/legitimate/

   remains as a research question.
4.3     Remotely exploitable attacks

==> add an empty line here

   that the attacker may be off link.  The resource being attacked in

==> s/off link/off-link/ ?

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Sun, 17 Nov 2002 16:19:34 +0200 (EET)

> "secure.victim.com" (also) points to <ATTACKER>::<IID>

Note typo in 3. -- it should have been <ATTACKER>::<IID>, of course.

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 17 Nov 2002 22:27:41 +0200

> packet hijacking, MITM, etc. -- but not necessarily DoS attacks.

That would be interesting.  Do you care to contribute some text to
be included?

> Bad" threat -- ie. a node in a "trusted" network is compromised.

I can do that, but I'd prefer to have some text for your semi-trusted
model, if possible.

> whatever)?  (E.g. to capture www.hotmail.com traffic, advertise their 

I'll check this and come back later.

> do very much harm; in particular, to spoof forward + reverse DNS checks.  
...
> Reverse DNS spoof is ready.

Good catch!  Will add to the next version.

> Editorial:

I'll return to these once I have proper time to go through
the text.

Thanks!!

--Pekka Nikander

---

From: Parijat Mishra <[email-masked]>
Date: Mon, 18 Nov 2002 15:53:49 +0800

A question:

> <VICTIM>::<IID> --> "secure.victim.com".

(a) Presumably configuring the reverse DNS mapping requires at least as much
(administrative) privileges as forward DNS mapping.  Right?

> "secure.victim.com" (also) points to <ATTACKER>::<IID>

If (a) is true, then attackers could perhaps simply spead poop all
over the DNS records of the victim.  Why would they need to wait for the
victim to update his/her DNS record?

---end quoted text---

-- 
Sincerely,
Parijat Mishra
R & D Engineer,
Institute for Communications Research
Tel: (65)68709353

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 18 Nov 2002 09:35:39 -0500

> (a) Presumably configuring the reverse DNS mapping requires at least
> as much (administrative) privileges as forward DNS mapping.  Right?

There was a followup -- this was supposed to be <ATTACKER>::<IID>
i.e., something in the attacker's space with the IID of the victim.

so, it's worth noting that the ATTACKER can't do this "anonymously".

 - we are assuming end-to-end security at or above IP, so redirecting
   secure.victim.com is at most a DoS

 - problem fixes itself when the mobile server wanders back to a
   well-behaved network.

 - this this particular attack may be indistinguishable from an ISP
   which allows you to join their network and then suffers a failure.

In terms of remedies for repeat offenders:

 - you can blacklist prefixes.

 - you can revoke/blacklist whatever certification chain is used to
 certify the routers of the attacker.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 18 Nov 2002 16:41:05 +0200 (EET)

>    secure.victim.com is at most a DoS

Where has this assumption been made?  Nowhere, I believe.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Nov 2002 06:31:30 +0200 (EET)

> That would be interesting.  Do you care to contribute some text to

I've included a diff of some required changes this trust model would 
bring.

Some further analysis would be needed, of course, but this should be 
enough to be able to see whether this is something that will need 
consideration.

Note that I *don't* assume the traffic must be enscrypted, as suggested in
an earlier message.  If I'm wrong this has a few implications, at least:
 1) this threat model doesn't seem to be useful
 2) wording has to be clarified wrt. encryption etc.
 3) "redirect" attacks should be clarified to be _bombing_ attacks against 
someone else in the subnet, not redirects to yourself.

I don't believe we can assume full encryption: it may be something that 
may be a required item for the protections to work in Public LAN or Adhoc 
case, but I don't see this being realistic in corporate cases.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
--- draft-ietf-send-psreq-00.txt	Wed Nov 20 04:05:56 2002
+++ draft-ietf-send-psreq-00.txt.bis	Wed Nov 20 10:20:10 2002
@@ -34,7 +34,7 @@
    and Address Autoconfiguration mechanisms MAY be protected with
    IPsec AH.  However, the current specifications limit the security
    solutions to manual keying due to practical problems faced with
-   automatic key management.  This document specifies three different
+   automatic key management.  This document specifies four different
    trust models and discusses the threats pertient to IPv6 Neighbor
    Discovery.  The purpose of this discussion is to define the
    requirements for Securing IPv6 Neigbor Discovery.
@@ -48,8 +48,9 @@
    2.0 Previous Work
    3.0 Trust models
        3.1 Corporate Intranet Model
-       3.2 Public Wireless Network with an Operator
-       3.3 Ad Hoc Network
+       3.2 Semi-trusted Corporate Network Model
+       3.3 Public Wireless Network with an Operator
+       3.4 Ad Hoc Network
    4.0 Threats on a (Public) Multi-Access Link
        4.1 Non router/routing related threats
            4.1.1 Neighbor Solicitation/Advertisement Spoofing 
@@ -90,9 +91,10 @@
 
    The purpose of this document is to define the types of networks the
    Secure IPv6 Neighbor Discovery mechanisms are expected to work, and
-   the threats that the security protocol(s) must address.  To fulfil
-   this purpose, this document first defines three different trust
+   the threats that the security protocol(s) must address.  To fulfill
+   this purpose, this document first defines four different trust
    models, roughly corresponding to secured corporate intranets,
+   semi-trusted corporate networks,
    public wireless access networks, and pure ad hoc netwroks.  After
    that, a number of threats is are discussed in the light of these
    trust models.  The threat catalog is aimed to be exhaustive, but it
@@ -156,20 +158,32 @@
 
 draft-ietf-send-psreq-00.txt                        P. Nikander (editor)
 
-   Three different trust models are specified:
+   Four different trust models are specified:
 
      1. A model where all authenticated nodes trust each other.
         This model is thought to represent a situation where the nodes
         are under a single administration and form a closed or
         semi-closed group.  A corporate intranet is a good example.
 
-     2. A model where there is a router trusted by the other 
+     2. A model where all authenticated nodes trust each other, but
+        only to a certain extent.  Here, the authenticated nodes
+        are partially trusted, that is, it is assumed they behave 
+        properly, but it is deemed desirable to limit the extent of 
+        damage they're able to inflict to the local network if they
+        start misbehaving (e.g. through a security compromise).
+        This model is thought to represent a situation where the nodes
+        are under a single administration and form a closed or
+        semi-closed group, but where the risk of security compromise is
+        still significant.  A corporate network containing many public
+        services is a good example.
+
+     3. A model where there is a router trusted by the other 
         nodes in the network.  This model is thought to represent
         a public network run by an operator.  The clients pay to
         the operator, have its credentials, and trust it to provide
         the service.  The clients do not trust each other.
 
-     3. A model where the nodes do not directly trust each other
+     4. A model where the nodes do not directly trust each other
         at the IP layer.  This model is considered suitable for
         e.g., ad hoc networks.
 
@@ -203,7 +217,26 @@
    key distribution mechanisms work right out-of-the-box.  For further
    details, see [IKE-ND].
 
-3.2         Public Wireless Network with an Operator
+3.2         Semi-trusted Corporate Network Model
+
+   In some corporate networks, even though all nodes are under
+   one administrative domain, the cost of a node starting to behave
+   badly (e.g. after an intrusion through a security vulnerability)
+   may be too high.  
+
+   The nodes may be considered to be usually reliable at the IP layer.  
+   Thus, once a node has been accepted to be a member of the network, 
+   it is assumed to behave in a semi-trustworthy manner.
+
+   Here, it is assumed that a node-gone-rogue being able to perform 
+   Denial-of-Service is still acceptable, but hijacking connections,
+   launching man-in-the-middle attacks etc. is not.
+
+   The approach to secure this environment is as described in the next
+   section; one may be able to take some shortcuts, as a certain level
+   of trust is still assumed (see section above).
+
+3.3         Public Wireless Network with an Operator
 
    A scenario where an operator runs a public wireless (or wireline)
    network, e.g., a WLAN in a hotel, air port, or cafe, has a different
@@ -243,7 +276,7 @@
    cryptographic protection to the ICMPv6 packets carrying ND
    messages.  
 
-3.3           Ad Hoc Network
+3.4           Ad Hoc Network
 
    In an ad hoc network, or any network without a trusted operator,
    none of the nodes trust each other.  Since there are no a priori
@@ -331,7 +364,8 @@
    Advertisement messages.
 
    This attack is not a concern if access to the link is restricted to
-   trusted nodes.  In the case just the operator is trusted, the nodes
+   completely trusted nodes.  In the case just the operator is trusted, or
+   the other nodes are only semi-trusted, the nodes
    may rely on the operator to certify the address bindings for other
    local nodes.  In the ad hoc network case, and optionally in the
    trusted operator case, the nodes may use self certifying techniques
@@ -362,7 +396,7 @@
    This threat involves Neighbor Solicitation/Advertisement.
 
    This attack is not a concern if access to the link is restricted to
-   trusted nodes.  Under the two other trust models, a solution
+   trusted or semi-trusted nodes.  Under the two other trust models, a solution
    requires that the node performing NUD is able to make a
    disctinction between genuine and fabricated NA responses.
    
@@ -381,7 +415,7 @@
 draft-ietf-send-psreq-00.txt                        P. Nikander (editor)
     
    This attack is not a concern if access to the link is restricted to
-   trusted nodes.  Under the two other trust models, a solution
+   trusted or semi-trusted nodes.  Under the two other trust models, a solution
    requires that the node performing DAD is able to verify whether the
    sender of the NA response is authorized to use the given IP address
    or not.  In the trusted operator case, the operator may acts as an
@@ -426,7 +460,8 @@
    Solicitation. 
 
    This attack is not a concern if access to the link is restricted to
-   trusted nodes.  In the case of a trusted operator, there must be a
+   completely trusted nodes.  In the case of a trusted operator, or
+   the other nodes are only semi-trusted, there must be a
    means for the nodes to make a distinction between trustworthy
    routers, run by the operator, and other nodes.  There are currently
    no known solutions for the ad hoc network case, and the issue
@@ -442,7 +477,7 @@
    in Section 4.2.1.  This is a redirect/DoS attack.
 
    There are currently no known solutions for any of the presented
-   three trust models.  On the other hand, on a multi-router link one
+   four trust models.  On the other hand, on a multi-router link one
    could imagine a solution involving revocation of router rights.
    The situation remains as a research question.
     
@@ -461,7 +496,8 @@
    This threat involves Redirect messages. 
 
    This attack is not a concern if access to the link is restricted to
-   trusted nodes.  In the case of a trusted operator, there must be a
+   completely trusted nodes.  In the case of a trusted operator, or
+   the other nodes being only semi-trusted, there must be a
    means for the nodes to make a distinction between trustworthy
    routers, run by the operator, and other nodes.  There are currently
    no known solutions for the ad hoc network case, and the issue
@@ -488,7 +524,7 @@
    This threat involves Router Advertisement messages. 
     
    This attack is not a concern if access to the link is restricted to
-   trusted nodes.  In the case of a trusted operator, there must be a
+   trusted or semi-trusted nodes.  In the case of a trusted operator, there must be a
    means for the nodes to make a distinction between trustworthy
 
 draft-ietf-send-psreq-00.txt                        P. Nikander (editor)
@@ -519,7 +555,7 @@
    This threat involves Router Advertisement messages. 
     
    This attack is not a concern if access to the link is restricted to
-   trusted nodes.  In the case of a trusted operator, there must be a
+   trusted or semi-trusted nodes.  In the case of a trusted operator, there must be a
    means for the nodes to make a distinction between trustworthy
    routers, run by the operator, and other nodes.  There are currently
    no known solutions for the ad hoc network case, and the issue
@@ -553,7 +589,7 @@
    This attack involves Router Advertisements. 
    
    This attack is not a concern if access to the link is restricted to
-   trusted nodes.  In the case of a trusted operator, there must be a
+   trusted or semi-trusted nodes.  In the case of a trusted operator, there must be a
    means for the nodes to make a distinction between trustworthy
    routers, run by the operator, and other nodes.  There are currently
    no known solutions for the ad hoc network case, and the issue
@@ -577,7 +613,7 @@
    This attack involves Neighbor Solicitation. 
 
    This attack does not directly involve the trust models presented.
-   However, if access to the link is restricted to registed nodes, and
+   However, if access to the link is restricted to registered nodes, and
    the access router keeps track of nodes that have registered for
    access on the link, the attack may be trivially plugged.  However,
    no such mechanisms are currently standardized.  
@@ -595,8 +631,9 @@
      R/D   Redirect/DoS (Redir) or just DoS attack
      Msgs  Messages involved in the attack: NA, NS, RA, RS, Redir
      1     Present in trust model 1 (corporate intranet)
-     2     Present in trust model 2 (public operator run network)
-     3     Present in trust model 3 (ad hoc network)
+     2     Present in trust model 2 (semi-trusted corporate network)
+     3     Present in trust model 3 (public operator run network)
+     4     Present in trust model 4 (ad hoc network)
 
    Symbols in trust model columns:
 
@@ -604,22 +641,22 @@
      +     The threat is present and at least one solution is known
      R     The threat is present but solving it is a research problem
 
-   +-------+----------------------------+-----+-------+-------+---+---+---+
-   | Sec   | Attack name                | N/R | R/D   | Msgs  | 1 | 2 | 3 |
-   +-------+----------------------------+-----+-------+-------+---+---+---+
-   | 4.1.1 | NS/NA spoofing             | ND  | Redir | NA NS | - | + | + |
-   | 4.1.2 | NUD failure                | ND  | DoS   | NA NS | - | + | + |
-   | 4.1.3 | DAD DoS                    | ND  | DoS   | NA NS | - | + | + |
-   +-------+----------------------------+-----+-------+-------+---+---+---+
-   | 4.2.1 | Malicious router           | RD  | Redir | RA RS | - | + | R |
-   | 4.2.2 | Good router goes bad       | RD  | Redir | RA RS | R | R | R |
-   | 4.2.3 | Spoofed redirect           | RD  | Redir | Redir | - | + | R |
-   | 4.2.4 | Bogus on-link prefix       | RD  | DoS   | RA    | - | + | R |
-   | 4.2.5 | Bogus address config prefix| RD  | DoS   | RA    | - | + | R |
-   | 4.2.6 | Parameter spoofing         | RD  | DoS   | RA    | - | + | R |   
-   +-------+----------------------------+-----+-------+-------+---+---+---+
-   | 4.3.1 | Remote ND DoS              | ND  | DoS   | NS    | + | + | + |
-   +------------------------------------+-----+-------+-------+---+---+---+    
+ +-------+----------------------------+-----+-------+-------+---+---+---+---+
+ | Sec   | Attack name                | N/R | R/D   | Msgs  | 1 | 2 | 3 | 4 | 
+ +-------+----------------------------+-----+-------+-------+---+---+---+---+
+ | 4.1.1 | NS/NA spoofing             | ND  | Redir | NA NS | - | + | + | + |
+ | 4.1.2 | NUD failure                | ND  | DoS   | NA NS | - | - | + | + |
+ | 4.1.3 | DAD DoS                    | ND  | DoS   | NA NS | - | - | + | + |
+ +-------+----------------------------+-----+-------+-------+---+---+---+---+
+ | 4.2.1 | Malicious router           | RD  | Redir | RA RS | - | + | + | R |
+ | 4.2.2 | Good router goes bad       | RD  | Redir | RA RS | R | R | R | R |
+ | 4.2.3 | Spoofed redirect           | RD  | Redir | Redir | - | + | + | R |
+ | 4.2.4 | Bogus on-link prefix       | RD  | DoS   | RA    | - | - | + | R |
+ | 4.2.5 | Bogus address config prefix| RD  | DoS   | RA    | - | - | + | R |
+ | 4.2.6 | Parameter spoofing         | RD  | DoS   | RA    | - | - | + | R |   
+ +-------+----------------------------+-----+-------+-------+---+---+---+---+
+ | 4.3.1 | Remote ND DoS              | ND  | DoS   | NS    | + | + | + | + |
+ +------------------------------------+-----+-------+-------+---+---+---+---+    
 
 draft-ietf-send-psreq-00.txt                        P. Nikander (editor)
     
@@ -633,7 +670,7 @@
    Thanks to Alper Yegin of DoCoMo Communications Laboratories USA for
    identifying the Neighbor Discovery DOS attack.  We would also like
    to thank Tuomas Aura and Michael Roe of Microsoft Research
-   Cambridge as well as Jari Arkko and Vesa-Matti M„ntyl„ of Ericsson
+   Cambridge as well as Jari Arkko and Vesa-Matti Mäntylä of Ericsson
    Research Nomadiclab for discussing some of the threats with us.
 
 7.0     References

---

From: "James Kempf" <[email-masked]>
Date: Wed, 20 Nov 2002 04:40:49 -0800

I'm wondering how useful this particular point is for SEND. It seems like a more
general point. SEND is specifically directed at threats to ND, so whether or not
traffic is encrypted isn't particularly relevent.

That said, it might be worthwhile expanding out this discussion on trust models
to a more general draft, like the IPv6 node requirements draft, as a guide to
when to use what level of security. Does this make sense?

            jak

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Nov 2002 15:03:54 +0200 (EET)

> traffic is encrypted isn't particularly relevent.

I fear it's relevant: the implications of the first (and this new second) 
threat model are significantly different depending on whether a redirect 
attack is also a DoS (but on someone else in the subnet) or could be used 
for hijacking clear-text traffic.

People have a *very* different level of urgency to fix things if it's
about more than just DoS attacks.  (Personally, I'm not particularly 
interested in SEND if it's only about patching DoS attacks in ND.)

Perhaps this is questionable because SEND originated from worries against
_wireless_ links where there is no difference if no encryption is used --
you don't ned to use vulnerabilities in ND to eavesdrop clear-text
traffic.  But this has been generalized now.  On e.g. wireline network, 
eavesdropping clear-text traffic without ND should be relatively 
difficult.

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 25 Nov 2002 16:05:55 -0500

I'd be inclined to remove the "corporate intranet" model and replace
it with your "semi-trusted network", unless you want a "null
hypothesis" threat model -- one where the existing insecure ND is
appropriate.

That said, I think the document could be tightened up considerably by
qualifying/scoping all intances of "trust" -- or finding a better word
to replace it.

Never just say "X trusts Y", but rather "X trusts that Y will send
reasonable router advertisements" or (better still) "X believes RA
messages from Y are legitimate because they are signed by Y's key and
Y's key is signed by ..."

					- Bill

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 28 Nov 2002 14:30:04 +0200

Bill,

(I'm now working on the next version of the psreq draft.)

> hypothesis" threat model -- one where the existing insecure ND is

I more or less adopted this approach, considering what happens
if a node becomes compromised in a corporate intranet.

> Y's key is signed by ..."

I changed the language somewhat.  However, it turned out to be hard
to start talking about keys or beliefs since we do not have any
specific solution in mind yet.  Thus, when we are speaking about trust,
we are really trying to denote beliefs about future behaviour, not
authentication or authorization in the technical sense.

Thus, when we write that "a node trusts the other nodes to behave
correctly at the IP layer and not to send any ND or RD messages
containing false information", that is a belief about the node's
future behaviour.  On this level, there is no way of enforcing it,
and the reasons for this trust most probably lie outside of the
IP layer and are due to e.g. physical protection or other means.

I added the following text to the introduction:

    It should be noted that the term "trust" is used here in a rather
    non-technical and loose manner.  The most appropriate interpretation
    is to consider it as an expression of an organizational or
    collective belief, i.e., an expression of commonly shared beliefs
    about the future behaviour of the other involved parties.
    Conversely, the term "trust relationship" denotes a mutual a priori
    relationship between the involved organizations or parties where the
    parties believe that the other parties will behave correctly even in
    the future.  A trust relationship makes it possible to configure
    authentication and authorization information between the parties,
    while the lack of such a relationship makes it impossible to
    pre-configure such information.

Would you consider this satisfactory?

--Pekka