Subject: [Enum] New Security Considerations section (including DNSSEC statements)

From: Michael Mealling <[email-masked]>
Date: 25 Mar 2003 15:08:55 -0500

I wanted to get this out earlier but my laptop died the afternoon after
the ENUM meeting. The major change is the addition of several threat
models taken from a DNSSEC security threats document. Its gotten a
little lengthy but I think much more useful:

 6. Security Considerations

6.1 DNS Security 

   As ENUM uses DNS, which in its current form is an insecure protocol,
   there is no mechanism for ensuring that the data one gets back is
   authentic. As ENUM is deployed on the global Internet, it is expected
   to be a popular target for various kind of attacks, and attacking the
   underlying DNS infrastructure is one way of attacking the ENUM
   service itself. 
   
   There are multiple types of attacks that can happen against DNS that
   ENUM implementations should be aware of. The following threats are
   taken from Threat Analysis Of The Domain Name System [9]:

   Packet Interception Some of the simplest threats against DNS are
      various forms of packet interception: monkey-in-the-middle
      attacks, eavesdropping on requests combined with spoofed responses
      that beat the real response back to the resolver, and so forth.
      In any of these scenarios, the attacker can simply tell either
      party (usually the resolver) whatever it wants that party to
      believe.  While packet interception attacks are far from unique to
      DNS, DNS's usual behavior of sending an entire query or response
      in a single unsigned, unencrypted UDP packet makes these attacks
      particularly easy for any bad guy with the ability to intercept
      packets on a shared or transit network.

   ID Guessing and Query Prediction Since the ID field in the DNS header
      is only a 16-bit field and the server UDP port associated with DNS
      is a well-known value, there are only 2**32 possible combinations
      of ID and client UDP port for a given client and server. Thus it
      is possible for a reasonable brut force attack to allow an
      attacker to masquerade as a trusted server. In most respects, this
      attack is similar to a packet interception attack except that it
      does not require the attacker to be on a transit or shared
      network.

   Name-based Attacks Name-based attacks use the actual DNS caching
      behavior as a tool to insert bad data into a victim's cache, thus
      potentially subverting subsequent decisions based on DNS names.
      Most examples occur with CNAME, NS and DNAME RRS as they redirect
      a victim's query to another location. The common thread in all of
      these attacks is that response messages allow the attacker to
      introduce arbitrary DNS names of the attacker's choosing and
      provide further information that the attacker claims is associated
      with those names; unless the victim has better knowledge of the
      data associated with those names, the victim is going to have a
      hard time defending against this class of attacks.

   Betrayal By A Trusted Server Another variation on the packet
      interception attack is the trusted server that turns out not to be
      so trustworthy, whether by accident or by intent.  Many client
      machines are only configured with stub resolvers, and use trusted
      servers to perform all of their DNS queries on their behalf.  In
      many cases the trusted server is furnished by the user's ISP and
      advertised to the client via DHCP or PPP options.  Besides
      accidental betrayal of this trust relationship (via server bugs,
      successful server break-ins, etc), the server itself may be
      configured to give back answers that are not what the user would
      expect (whether in an honest attempt to help the user or to
      further some other goal such as furthering a business partnership
      between the ISP and some third party).

   Denial of Service As with any network service (or, indeed, almost any
      service of any kind in any domain of discourse), DNS is vulnerable
      to denial of service attacks. DNS servers are also at risk of
      being used as denial of service amplifiers, since DNS response
      packets tend to be significantly longer than DNS query packets.

   Authenticated Denial of Domain Names The existence of RR types whose
      absence causes an action other than immediate failure (such as
      missing MX and SRV RRs, which fail over to A RRs) constitutes a
      real threat.  In the specific case of ENUM, even the immediate
      failure of a missing RR can be considered a problem as a method
      for changing call routing policy.

   Because of these threats, a deployed ENUM service SHOULD include
   mechanisms which ameliorate these threats. Most of these threats can
   be solved by verifying the authenticity of the data via mechanisms
   such as DNSSEC (Section 6.1) once it is deployed.  Others, such and
   Denial Of Service attacks, cannot be solved by data authentication.
   It is important to remember that these threats include not only the
   NAPTR lookups themselves, but also the various records needed for the
   services to be useful (for example NS, MX, SRV and A records).

   Even if DNSSEC is deployed, a service which uses ENUM for address
   translation should not blindly trust that the peer is the intended
   party as all kind of attacks against DNS can not be protected against
   with DNSSEC. A service should always authenticate the peers as part
   of the setup process for the service itself and never blindly trust
   any kind of addressing mechanism.

   Finally, as an ENUM services will be implementing some type of
   security mechanism, software which implements ENUM MUST be prepared
   to recieve DNSSEC and other standardized DNS security responses,
   including large responses, EDNS0 signaling, unknown RRs, etc.

6.2 Caching Security

   The caching in DNS can make the propagation time for a change take
   the same amount of time as the time to live for the NAPTR records in
   the zone that is changed. The use of this in an environment where
   IP-addresses are for hire (for example, when using DHCP [8]) must
   therefore be done very carefully.

6.3 Call Routing Security

   There are a number of countries (and other numbering environments) in
   which there are multiple providers of call routing and number/name-
   translation services.  In these areas, any system that permits users,
   or putative agents for users, to change routing or supplier
   information may provide incentives for changes that are actually
   unauthorized (and, in some cases, for denial of legitimate change
   requests).  Such environments should be designed with adequate
   mechanisms for identification and authentication of those requesting
   changes and for authorization of those changes.

6.4 URI Resolution Security

   A large amount of Security Issues have to do with the resolution
   process itself, and use of the URIs produced by the DDDS mechanism.
   Those have to be specified in the registration of the ENUM
   Enumservice used, as specified in Section 3.1.3.

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Richard Shockey <[email-masked]>
Date: Wed, 26 Mar 2003 12:57:09 -0500

>little lengthy but I think much more useful:

Your chairs have not heard any comments on this text .... do we believe 
than that silence is consent and that this text can now be incorporated in 
the document?

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto:[email-masked]> or <mailto:[email-masked]>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 26 Mar 2003 19:47:30 +0100

Your chairs have not heard any comments on this text .... do
    we believe than that silence is consent and that this text can
    now be incorporated in the document?
    
I always thought that the security section list the threats added
to the current system. A lot of the things mentioned here actually
lists well known threats not specific to enum (DNS threats). For
that part it is not necessary to list them but just point to the
existing documents, such as the DNS threats drafts (to be published
soon) and other relevant RFC's.

	jaap

---

From: Jim Reid <[email-masked]>
Date: Wed, 26 Mar 2003 11:16:27 -0800

>>>>> "Jaap" == Jaap Akkerhuis <[email-masked]> writes:

    Jaap> I always thought that the security section list the threats
    Jaap> added to the current system. A lot of the things mentioned
    Jaap> here actually lists well known threats not specific to enum
    Jaap> (DNS threats). For that part it is not necessary to list
    Jaap> them but just point to the existing documents, such as the
    Jaap> DNS threats drafts (to be published soon) and other relevant
    Jaap> RFC's.

Yes, this would be a better approach. The chances are those DNS
threats documents would get updated and revised more quickly than
2916bis. And they're independent of the ENUM WG too. 
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Michael Mealling <[email-masked]>
Date: 26 Mar 2003 14:33:36 -0500

> 2916bis. And they're independent of the ENUM WG too. 

Oh lordy... ;-)

Ok, my recollection of the consensus was that we couldn't make DNSSEC
mandatory. So we should explain the threat risks that DNS entails in
enough detail so that its obvious that, while DNSSEC in its current form
isn't fully baked, to neglect using it would be extremely dangerous.
Could someone propose some text for me to take the current form and
rework it to balance that consensus and the above statements about
tracking the dns-threats document?

-MM

---

From: Richard Shockey <[email-masked]>
Date: Wed, 26 Mar 2003 14:56:55 -0500

> > 2916bis. And they're independent of the ENUM WG too.

Really ... I really dont see the problem with listing known threats 
here.  IMHO this is a bit of hair splitting.

If anyone has text you want to see included .then submit it NOW ...because 
we need to move on get 05 ready and start a last call process.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 28 Mar 2003 11:06:25 +0000

Michael Mealling said:
>       attacks,

*man*-in-the-middle, surely?

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum