$Id: README,v 1.2 2002/04/02 01:26:32 koni Exp $
$Date: 2002/04/02 01:26:32 $
$Author: koni $
$Revision: 1.2 $
-- Setup and Installation --
Please see the file INSTALL for information on setting up your own server or client. To use the client software, you will need information from the service provider or administrator of the host you will use as an slan server.
-- What is SLAN? --
SLAN (secure LAN, pronounced ess-LAN) is, simply put, yet another virtual private networking system. It is slightly different from typical VPN implementations as it is client-server based, rather than peer to peer. A single SLAN server can potentially connect several clients independently to the LAN which it resides on, creating a virtual network topology where the clients (which might be anywhere on the internet) appear as local delivery hosts on the same LAN as the server. Usually, VPN systems build persistent tunnels between routers, and merely offer a secure route between two seperate IP networks. SLAN is designed to allow a client system simply "join" a LAN as if it were locally connected. This connection is dynamic rather than static.
The development of this project was motivated by the insufficient security mechanisms built into the IEEE 802.11 wireless networking standard. Lightlink Internet, a local ISP here in Ithaca, wants to launch a city-wide and potentially larger 802.11 public wireless network, yet still offer data privacy for its customers even though their data is being broadcast over radio waves to, more or less, the entire city.
The SLAN project was created and developed to provide an easily changeable (or rather, fixable and upgrade-able -- we should all know that real network security is a continuous effort, not a one-stop shop), open-source, software solution to this problem, providing client authentication, server/service authentication, data privacy (encryption) and integrity (MAC) using per-session per-user short life keys (as opposed to long term shared secrets like a WEP password), and ability to add any feasible features that the client or service provider finds useful and convenient, such as bandwidth accounting, account status, network status, etc.
The resulting development is a virtual private network system, designed mostly with the intent to protect the link between the client's machine and the service provider's internal networking infrastructure which is assumed (for the context of this project anyway) to be physically secure against privacy violations. SLAN DOES NOT PROTECT YOUR DATA ON THE INTERNET. However, the current design is flexible enough that it could be used for secured remote access through the Internet to a company or organization's private internal network, the way most other VPN implementations are intended to work. Our focus however was the link between the service provider's physically secured backbone network and the client, which for us, is a broadcast medium requiring very little effort or expense for a passive adversary to eavesdrop.
-- What's wrong with WEP? ---
Many might wonder why we didn't want to use 802.11's built in security mechanisms. There are many reasons, I will list a few here:
(1) WEP was not designed for use with legitimate but non-mutually trusting users. In other words, WEP assumes that if you are trusted with access to the network (you know the WEP key or password), then you and the other users mutually trust each other with each other's privacy or network traffic. Hence the name "Wired Equivalent Privacy." If you can plug-in, well, then you can sniff. Clearly, for a 802.11 wireless ISP, legitimate clients (those who subscribed and have accounts) are almost certainly not going to be mutually trusting. Thus, we need something much stronger than WEP, with per-user per-session keys and no simple shared secrets like WEP keys or network passwords.
(2) Access control. Those who haven't subscribed and paid for service should not be allowed to just use it anyway. WEP's access control mechanism is knowledge of the WEP key, shared amongst all other users. What is to stop legit customers from just telling everyone else the shared access password? We want access control (client authentication) with different secrets for each client. This allows the ability to revoke a client's access rights as well as the ability to keep accounting of a subscriber's network usage. With accounting, sharing of access rights is no longer a concern: clients can let their friends use the service as much as they want. Some access points do provide ACLs for MAC addresses, but many cards will allow the MAC address to be overridden by the driver. So this is not particularly useful.
(3) Interoperability. At the time this project was created, many vendor's WEP
implementations did not interoperate. There were 104/128-bit cards, 40/64-bit
cards (that is 40 (or 104) bit key, 24 bit initialization vector). Since some
clients will have only 40 bit cards, all users (if we used WEP) would have to
use 40 bits. Sometimes the longer key cards won't interoperate with shorter
key cards, even if you've set the longer key appropriately (however one does
that). Sometime they do work together. Who's to say whether the latest
128-bit Orinoco "Gold" card will work correctly with Aironet's latest 40 bit
WEP access point. Apple's airport
wants a "network password" instead of hexadecimal keys. Other vendors have a
similar mechanism for hashing ASCII strings into hex keys, but, from what I
can tell, nobody is doing it the same way. This makes WEP a logistic problem,
not just a security concern. This is a tech support nightmare in the
making, without the ability for us to solve the real problem directly.
(4) Short key length. As stated above, we'd be naturally limited to 40-bit long-term keys. This is within the brute-force abilities of off the shelf PCs today. Since the secret is long term, we might as well not bother with encryption at all. It would be false advertising to pretend the service addressed security concerns at all.
(5) Finally, WEP, even with these already crippling limitations, was apparently
not even implemented wisely and does not provide even the very slim margin of
security it was supposed to! See
http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html for some details. Such is
the unfortunate truths of industry provided (and US export controlled)
cryptographic security solutions implemented in hardware or firmware.
Hence, the development of SLAN as a open-source software solution for wireless network security. The salient point of this project is, when people like the Berkeley folks who performed the analysis of WEP mentioned above, find problems or weaknesses in SLAN, we can simply modify our software to fix the problems. Furthermore, as a GPL open source project, if we fail to do this, you can fix it yourself! Open source facilitates and encourages analysis by any capable party. We hope for heavy feedback for the open-source and network security community at large to help us develop SLAN into solid and secure virtual private networking system, free for anyone to use and adapt as they desire.
-- Why not use IPSec? --
The author of this document (Koni) is interested in any opinions or experiences of people actually using IPSec in any kind of setting. IPSec is a very complicated system of protocols -- we need something we can construct on any platform we have resources for, without necessarily the cooperation of the operating system or hardware vendor. Implementing a free version of IPSec for a wide array of platforms is a bit beyond our resources, and doesn't necessarily provide us with the advantages that SLAN can. Some operating systems are shipping now with built-in IPSec support. As this becomes common place, and, depending on IPSec's success, IPSec may eventually replace the need for a system like SLAN. At this moment, we don't see this happening in near future.
We can't just fix problems with IPSec's implementation if we are supposed to interoperate with other IPSec implementations. To our knowledge, there are a few points of interest in this regard. At the time this project was established, we felt (and still feel) that developing a cross platform, open source, customizable system is better for Lightlink's customers as well as a potentially beneficial product free for other organizations to use and develop as they require.
See http://www.counterpane.com/ipsec.html for an analysis of IPSec.
-- What about Microsoft PPTP? --
What about it? First, see these:
http://www.counterpane.com/pptp-paper.html
http://www.counterpane.com/pptpv2-paper.html
The analysis given in the papers above by Counterpane and L0pht Heavy Industries show serious serious problems with this VPN system. We cannot simply improve or fix MS PPTP as Lightlink's Windows users will probably wish to use the implementation that comes with their systems. As well, we want cross platform support, as extensive as our resources permit combined with independent efforts of other developers in the open source community at large. A Linux implementation exists, but I don't know of (but haven't bothered to look extensively) a Macintosh implementation. We do not wish to leave Mac users out in the cold. At current, we have no SLAN implementation for Macintosh, but intend to begin developing one shortly.
One final point worth mentioning, MS PPTP derives its encryption keys from the user's password. As any system administrator will know, users choose their passwords poorly, despite administrative attempts to discourage this. An easily guessed password not only leads to ability to impersonate a user, but in the case of MS PPTP, ability to potentially decrypt past, present, and future network traffic. SLAN is designed to use a user's secret identification information (in most cases, username/password pair) only for authenticating the user. Thus, users who choose poor passwords run the potential risk of somebody using the service on their bill, but the user's network traffic, in the past, present, and future, remain private.
-- Intended Strengths of SLAN --
Our goals are to provide as robust data privacy and integrity as possible, given the current state of practical applied cryptography in the current literature. In this context, practical means acceptable network and CPU performance as well as royalty free algorithms and protocols. We cannot use patented or trademarked algorithms in a product distributed freely as open source.
We intended to provide cross platform support, eventually extending to, but not necessarily limited to,
Linux (Intel) (kernel 2.2.x and 2.4.x)
Linux (PPC) (kernel 2.2.x and 2.4.x)
Windows 95 SE
Windows 98
Windows 98 SE
Windows ME
Windows NT
Windows 2000
MacOS 9
MacOS X
At current, implementations exist only for:
Linux Intel kernel 2.2.x (*) and 2.4.x
Linux PPC kernel 2.2.x (*)
Windows 98 SE (*)
(*) Release 0.04 has temporarily removed support for Win98 SE. Linux PPC implementations have not been tested with Release 0.04, 2.2.x kernels on Intel may require kernel patches for the TUN/TAP virtual device and brigding software.
The way SLAN intercepts network traffic was chosen in hopes of making cross platform support theoretically possible in a simple way. As long as the OS can support more than one Ethernet device and a functional IP routing table, it should be possible to implement SLAN in a similar manner to the existing Linux implementation. Details will vary from system to system. A system which cannot support a second Ethernet device or does not have a solid IP routing table to control the flow of network traffic over the network devices will probably require intensive operating system specific development to implement SLAN.
SLAN intercepts network traffic by loading a device driver which pretends, as far as the operating system is concerned, to be a normal Ethernet device driver. The device redirects the packet to a listening user space program, via a device node in the /dev directory. Encryption and authentication are performed in the user space daemon which sends the result directly to the server. This keeps the OS specific driver simple (and hopefully robust) and the intensive work in user space where portable code can hopefully be used as much as possible.
As mentioned above, the SLAN project does not use a user's password to generate encryption keys. The following will be documented in full in a forthcoming technical document, but briefly, a SLAN connection startup proceeds through the follow steps to gain its security:
(1) Client/Server version handshake
(2) Diffie-Hellman key exchange. Distinct symmetric cipher and message authentication code (MAC) keys are derived from the DH keyexchange by running SHA-1 on the DH keyexchange result. If, say, the DH keyexchange results in 1024 bits, the SHA-1 of the first 512 bits are used for the cipher key and the latter half for the MAC key. (NOTE: this construction is under investigation, it may be modified so that the MAC key and cipher key both depend differently on all the bits of the DH keyexchange). This results in a 160-bit encryption key and 160-bit integrity (MAC) key. Once these keys are established, all control channel and transport channel traffic are encrypted and signed.
(3) Server Authentication (Required). The server uses RSA to prove the identity of the service provider. Obviously, if someone could pose as the server, the system has no security. The client must have the server's public key stored locally. There is not (and shall not be unless someone can convince me that this isn't a horrible idea) a mechanism for the client to learn the server's public key during the server authentication step as a client can in the SSH protocol. The server specifies the key it wishes to use by sending a fingerprint of the key rather than a copy of the public key. If the client does not have the public key corresponding to the fingerprint, the client disconnects.
(4) Client Authentication (Optional -- depending on service provider's desire). Originally we planned to use a variant of CHAP (Challenge Handshake Authentication Protocol), but abandoned this path in order to allow the server to use PAM on Linux to verify a user's identity. This is for flexibility in choice of actual authentication methods used by the service provider, but required dropping one-way hashing of passwords (and a nonce) before transmitting. Thus, a user's password is transmitted over the network, but protected by the encryption and integrity provided and setup at stage (2). If the client fails authentication, the server drops the connection.
(5) MAC Address negotiation. The client proposes addresses and the server accepts one which is unique amongst the currently connected clients. This address is configured on the virtual network interface and used as the the client's Layer2 hardware address on the server's LAN.
(6) The client system's virtual network device may now be configured with an IP address and default route (SLAN client deletes existing default rules). This may be performed by DHCP or by a static configuration. The SLAN client program by default DOES NOT try to initiate this itself.
At this stage, the session is active and network traffic should work normally. The client program adjusts the routing table to set the default network route (and should be only network route) to the slan interface, and a host route to the server on the real network interface. Thus, server bound traffic goes out directly on the real network, all other traffic is intercepted by the slan device driver and delivered to the slan daemon process. Since the server bound traffic goes directly to the server, the service provider must not provide other usual services (web, mail, FTP, whatever) on the same box as the SLAN server. The connection is maintained by keepalive packets sent through the control channel by the server. Failure to respond to a sufficient number of keepalives causes the server to terminate the connection at its end.
The client may initiate a key change at anytime. By default, the client automatically does this at a configurable interval (default 1 hour). To change keys, the Diffie-Hellman key exchange is performed exactly as it was in the connection setup, except the exchange occurs of the encrypted control channel. Thus, a rogue server cannot attempt to hijack a client's connection by intercepting the traffic at key exchange time, because the rogue server would have to know the keys already in use to complete the key exchange protocol correctly. There is no reason why the server authentication couldn't be repeated after each key exchange to further guard against connection hijacking, but we have not bothered to implement this (yet).
The periodic key exchange step is meant to limit the amount of data vulnerable if any single key is ever compromised, by brute force or other means. More paranoid users may set more aggressive key exchange periods if they desire.
At the moment, the default symmetric cipher is Blowfish, and the default MAC is HMAC-SHA1-96. These are currently the only options. The code is designed to support different ciphers and MACs. In the future, we expect to provide the following ciphers, and MACs,
Ciphers (CBC mode):
Rijandael (AES)
Twofish
- MACs
- HMAC-SHA1 HMAC-MD5-96 HMAC-MD5
These options are low priority for now. DES and 3-key DES are noticeably slower than the options above, so I do not plan to implement them unless people demand it. The current design uses the same key for client --> server traffic AND server --> client, so DO NOT USE STREAM CIPHERS unless this is changed and you know what you are doing.
Order of operations:
- prepend 32-bit packet sequence number (used to guard against replays)
- calculate MAC of resulting packet and prepend the MAC (96 bits by default)
- CBC-encrypt this packet (using ciphertext stealing -- no bother with padding to blocksize).
Thus, the sequence number and MAC form the IV for the CBC encryption. In the case of 64-bit block length of Blowfish and the 96 bits of HMAC-SHA1-96, the MAC and sequence number fill exactly two blocks. Comments on the security of this construction are hereby solicited.
The decryption and verification of the packet is the reverse process. Packets which fail the MAC check are rejected. Out of sequence packets are rejected, subject to a small window (default 10) where packets with a past sequence number is tolerated. This is desired since the UDP packets may be delivered to the server or client out of order. Packets with a forward sequence number are always tolerated under the assumption that an attacker cannot forge the encryption and MAC of the packet (which contains the sequence number).
Sequence numbers are reset when a key exchange occurs. Key exchange intervals should be set such that sequence number roll-over cannot realistically occur before a key exchange would normally occur. Since the sequence numbers are 32 bits in size, several gigabytes would need to be transmitted before this is a concern. Hourly key exchanges should be much more than sufficient as far as sequence roll-over concerns go.
Further details on SLAN's security design will appear in a forthcoming technical documentation.
-- Limitations of SLAN design --
The "plumbing" of the recommended slan implementation mentioned above has some drawbacks, most notably, the vulnerability of the routing table to accidental or malicious modification. The security of the system depends on the routing table to direct the traffic which the user wishes to protect to the SLAN device. If an attacker, through casual access to the computer when the user is away from the console, or by remote access (through OS security breach or legitimate usage) can modify the routing table, the user's traffic may be transmitted in the clear without the user's knowledge! One might argue that this is an acceptable risk since if an attacker has casual access to the target's machine, then a great many other things than just the user's network traffic are vulnerable, and possibly easier ways of spying the network traffic than changing the routing table and then listening to the transmitted traffic. The author of this document feels this kind of argument is generally fallacious in security context as it leads to weak security designs because potential threats are dismissed as "larger problems" in the global context as opposed to addressing the problem as localized threat the relevant system's domain. Thus, the reader of this document should be acutely aware that the routing table is most likely the weakest link in the proposed SLAN design.
A service provider may try to guard against this, by blocking the physical network's access except for the ports needed by the SLAN software. Thus, if the routing table is incorrectly configured, the user's network access will not work, which they will certainly notice.
Another option is to have the SLAN client monitor the routing table and notice any changes, alerting the user to any irregularities. This recommended in any case, but currently not implemented in our code. (It most likely will be shortly)
Of course, other options for implementing the kernel side of the SLAN software exist, but the feasibility depends on the information available about the operating system and device drivers. Ideally, the "transport" parts of slan could be implemented directly in the real network device driver itself, settling routing table issues completely. This is quite possible for open source operating systems like Linux, but probably impossible for any proprietary operating system without the cooperation of the vendor.
For our first attempts at developing and promoting this project on a wide array of hardware and operating systems, we have chosen to accept the limitations of the current design and will explore any superior options when opportunities arise.
-- Acknowledgements --
The development of this software was funded in full by Homer Smith of Art Matrix - Lightlink, Inc., Ithaca, New York USA.
The SLAN protocol and design was conceived and implemented on Linux by Mark Wright (Koni).
The windows version of the slan client software was brilliantly developed by Lucas Madar.
Max Parke coordinated and directed the development.
Nick Taylor critiqued the proposed designs and consulted on several technical issues.
John Gutteridge set up and maintained hardware for testing and development.
The cryptography used in this project was possible thanks to many publications and information available on the Internet, most notably,
Schneier, Bruce, "Applied Cryptography", John Wiley & Sons, 1996
Serious work on this project was possible thanks mainly to Mr. Schneier's publications on Cryptography.
-- Further Development --
The SLAN development team and project strive to provide the most secure cross platform virtual private networking system available as open source free software. We solicit here the review and analysis by the open source and security community at large. To contribute to SLAN's development, please send comments, questions, bug reports, patches, etc., to slan@ithacaweb.com.
Please visit the slan website <http://slan.sourceforge.net/> for updated releases and announcements.