Subject: Security considerations in Links draft

From: Dan Grossman <[email-masked]>
Date: Thu, 08 Mar 2001 17:39:54 -0500

The security considerations section of the draft has a few problems.  While it 
correctly identifies a placement principle, it does not acknowledge the fact 
that there are assets to be protected in subnets.  It also does not 
acknowledge that many applications restrict use of end-to-end security 
mechanisms to only the most privacy-sensitive information, on the assumption 
that eavesdropping attacks are relatively difficult to mount (as they are, for 
example, in a dial-up, DSL a leased line by topological constraint).  For 
example, most e-commerce sites use SSL when checking out, but not while 
browsing;  this raises obvious privacy concerns in the context of shared media 
networks.  I'd also suggest that some words of wisdom about using sensible 
mechanisms be included.

Suggested replacement text:
   Security has become a high priority in the design and operation of
   the Internet.  A consensus has
   emerged for what might be called a "security placement principle":  a
   security mechanism is most effective when it is placed as close as
   possible to, and under the direct control of the owner of, the
   asset that it protects.

   The conclusion that follows from this principle is
   that end-to-end security (e.g., privacy and data integrity)
   can only be ensured with end-to-end (rather than subnet) mechanisms.   
   Not only are
   end-to-end security mechanisms more cohesive with the assets that they
   protect, they cover more threats (including compromises in the gaps between
   concatenated subnetwork mechanisms).  This is an important application of  
   the end-to-end arguments [src81].

   Several end-to-end security mechanisms have already been deployed in
   the Internet and are enjoying increasing use. The most important are
   the Secure Sockets Layer (SSL), [SSL2] [SSL3] primarily used to
   protect web commerce; Pretty Good Privacy (PGP) [RFC1991], primarily
   used to protect and authenticate email and software distributions;
   the Secure Shell (SSH), used for secure remote access and file
   transfer; and IPSEC [RFC2401], a general purpose encryption and
   authentication mechanism that sits just above IP and can be used by
   any IP application.

   Nonetheless, these end-to-end security mechanisms are less widely used
   than might be desired.  Decisions to NOT use such 
   mechanisms often implicitly assume a degree of security commensurate
   with that of a concatenation of point-to-point links and LANs in a
   single administrative domain.  The Internet architecture does not allow  
   applications to know about the security properties of the subnets along a 
   path, and subnets have little if any leverage to encourage applications to 
   use end-to-end security.  Thus, shared medium subnets may wish to consider
   including mechanisms that raise the degree of privacy and system integrity
   of their service to about that of point-to-point connections.  This should 
be
   done with the full knowledge that such mechanisms are not functionally
   equivalent to end-to-end mechanisms.

   In keeping with the "placement principle" discussed above,
   subnetwork designers should develop mechanisms to protect subnetwork assets.
   Examples of threats to subnetwork assets include theft-of-service and  
   denial-of-service (targetted and global). Shared media subnets tend to be
   especially vulnerable to attacks.  In some cases, mechanisms that protect
   subnet assets can also improve (but NOT ensure) end-to-end security.

   Subnet security mechanisms should be designed and impelemented with care 
and 
   attention to accepted practice. See, for example, [Schenier1] and   
   [Schneier2].  (we could go on here about things like the fallacy of 
security 
   by obscurity, or on the importance of good random numbers... but I won't 
   suggest doing this)

[Schneier1] Schneier, Bruce, Applied Cyptography: Protocols, Algorithms and 
Source Code in C (John Wiley and Sons, October 1995). 

[Schneier2] Schenier, Bruce, Secrets and Lies: Digital Security in a Networked 
World (John Wiley & Sons, August 2000).

---

From: John Border <[email-masked]>
Date: Thu, 08 Mar 2001 18:51:52 -0500

This looks good to me.  One minor enhancement... Change the SSL reference to
SSL and TLS...

John

---

From: Dan Grossman <[email-masked]>
Date: Fri, 23 Mar 2001 17:39:12 -0500

As a result of our discussion yesterday, here is additional text concerning 
 
>    subnet assets can also improve (but NOT ensure) end-to-end security.
----------------
>    by obscurity, or on the importance of good random numbers... but I won't 
------------------
Replacement text:
Design and implementation for security is difficult [Schneier2][Schneier3]. 
[Schneier1] describes  protocols and algorithms which are considered well 
understood and believed to be sound.  

Poor design process, subtle design errors and flawed implementation can result 
in gaping vulnerabilities.  In recent years, a number of subnet standards have 
had problems exposed.  Following are examples of some of the kinds of mistakes 
that have been made:
-- Use of weak and untested algorithms [Crypto9912], [BGW].  For a variety of 
reasons, algorithms were chosen which had subtle flaws that made them 
vulnerable to a variety of attacks.
-- Use of 'security by obscurity' [Schneier4], [Crypto9912].  One common 
mistake is to assume that making cryptographic algorithms secret makes them 
more secure.  This is intuitive, but wrong.  Full public disclosure early in 
the process attracts peer review by knowledgeable cryptographers.  Exposure of 
flaws by this review far outweighs any benefit that accrues by forcing 
attackers to reverse engineer security algorithms.
-- Inclusion of trapdoors [Schnier4], [Crypto9912].  Trapdoors are flaws which 
are surreptitiously left in an algorithm to allow it to be broken.  This might 
be done, for example, in the interest of password recovery, or by governmental 
agencies.  They can be discovered and exploited by malicious attackers.
-- Sending passwords or other identifying information in cleartext. For many 
years, analog cellular telephones could be cloned, allowing theft of service 
by attackers eavesdropping on registration.
-- Keys which are common to all systems on a subnet [BGW] 
-- Incorrect use of sound mechanism.  For example [BGW], one subnet standard 
includes an initialization vector which is poorly designed and poorly 
specified.  A determined attacker can easily recover multiple cyphertexts 
encrypted with the same keystream and perform statistical attacks to decypher 
them.
-- Identifying information sent in cleartext which can be resolved to an 
individual, identifiable device,  This creates a vulnerability to attacks 
targetted to that device (or its owner). 
-- Inability to renew and revoke shared secret information.
-- Insufficient key length [need a reference?]
-- Failure to address Man-in-the-Middle attacks (e.g., by mutual 
authentication).

This list is by no means comprehensive.  Design problems are difficult to 
avoid, but expert review is generally invaluable in avoiding problems. 

In addition, well designed security protocols can be compromised by 
implementation defects.  Examples of such defects include use of predictable 
pseudo-random numbers [RFC1750], vulnerability to buffer overflow attacks due 
to unsafe use of certain I/O system calls [WFBA2000], and inadvertent exposure 
of secret data.
> World (John Wiley & Sons, August 2000).
[Schneier3] Schnier, Bruce "Why Cryptography is Harder Than it Looks", 
www.counterpane.com
[Crypto9912] Scheneier, Bruce "European Cellular Encryption Algorithms" 
Crypto-Gram (December 15, 1999)  www.counterpane.com
[BGW] Nikita Borisov, Ian Goldberg, David Wagner, "Security of the WEP 
Algorithm"  www.www.isaac.cs.berkeley.edu/isaac/wep-faq.html
[RFC1750] D. Eastlake, S. Crocker, J. Schiller, Randomness Recomendations for 
Security, December 1994 (this will be obsoleted soon... check before 
submitting to RFC editor)
[WFBA2000] David Wagner, Jeffrey S. Foster, Eric Brewer and Alexander Aiken, 
"A First Step Toward Automated Detection of Buffer Overrun Vulnerabilities", 
Proceeedings of NDSS2000, or www.berkeley.edu:80/~daw/papers/