The IT Security Cookbook - Security Mechanisms

This chapter outlines typical mechanisms used to implement IT Security. The mechanisms discussed are Cryptography, Access control lists, Authentication, implementation of rules & policies and availability mechanisms.

7.1 Cryptography & Digital Signatures

Introduction
Cryptography is the translation of information (known as plaintext) into a coded form (known as cypertext) using a key. Cryptography is mostly used to protect the privacy of information (i.e. limit who can access the information).

In a strong cryptosystem, the original information (plaintext) can only be recovered by the use of the decryption key. So the plaintext information is protected from "prying eyes". A secure encryption algorithm is one who cannot be easily inverted on a Supercomputer today (i.e. the PC of tomorrow). There are two principal methods of cryptography, Shared Key and Public Key cryptography.

References: "Applied Cryptography", 2nd Edition 1996, Bruce Schneier.
[THE crypto reference- buy one now!]

7.1.1 Shared (or symmetric) Key Cryptography

Both parties exchanging data have a key, this key (unknown to others) is used to encrypt the data before transmission on one side and to decrypt on receipt on the other side. There are two kinds of symmetric ciphers: Block (which encrypt blocks of data at a time) and stream ciphers (which encrypt each bit/byte or word sequentially).

  • The well known DES (Data Encryption Standard) is a shared key block cipher. DES was developed under contract to NIST (National Institute of Standards and Technology) by IBM. In basic mode it encrypts 64-bit blocks of plaintext, with a 56 bit key, using 16 iterations of an elaborate combination of table lookups and bit rearrangements.
  • The US government certified DES in 1977 and continues to re-certify DES every 5 years. With the advances in computing hardware, DES is now breakable by organisations with significant resources (by brute force: trying all possible combinations of the key). This is mainly due to the relatively small key size of 56 bits used by DES. One solution is the so called Triple-DES or 3DES system, in which the data block is encrypted three times using two different keys (in a time slightly faster than 3 times a normal encryption). 3DES has a key strength roughly equivalent to 112bits. 3DES has not yet been certified by the US government, but it is unlikely that the original DES will be re-certified again in 1997.
  • RC2, RC4 and RC5 are (proprietary) variable key size stream ciphers from RSA Inc. Since key size is variable, they can be more or less secure than DES. USA export approved versions have 40-bit key sizes (not very useful). Domestic versions can have keys between 40 and 1024 (RC4, RC5) or 255 (RC2) bits. RC4 is the fastest (it was also published as an Internet draft without RSA's approval) and RC5 is considered the "safest".
  • IDEA: Developed by the Swiss ETH University in Zurich and Ascom (patented).Finalised in 1992 by Lai & Massey, uses a 128 bit key. No weaknesses are currently known in this algorithm and a brute-force attack will not be feasible in the foreseeable future. PGP uses IDEA as it's symmetric algorithm. The licensing terms are included in Appendix C (basically personal use is free and integrating IDEA into a sellable product costs money).
  • Blowfish: Is public domain algorithm, that is new but hasn't shown any major weaknesses. It is fast and compact, with variable key sizes and uses 8 byte blocks.
  • AES: The Advanced Encryption Standard is designed to replace DES. NIST is accepting proposals until June 1998. It should have keys of 128, 192, 256 bits and use 128 bit blocks. The final algorithm probably won't be available until the year 2000.

Advantages: Shared key algorithms are much faster than their public key counterparts.
Disadvantages: Both side must know the same key and they must find a secure way of exchanging it (via a separate secure channel).

Typical applications: Encryption of information to protect privacy. i.e. local encryption of data files (where no transmission is required), data encryption for transmission, banking systems (PIN encryption).

7.1.2 Public Key Cryptography

Both parties have a private key and a public key. The private keys are known only to their owners, but the public keys are available to anyone (like telephone numbers). The sending party encrypts the message with the receivers public key and the receiver decrypts with his own private key. This is possible due to the discovery by Diffie and Hellman (at Stanford University, 1976) that algorithms can be developed which use one key for encryption and a different key for decryption. The public and private key constitute a key pair.
For a cute animated diagram explaining how Public key cryptography works, see http://www.news.com/SpecialFeatures/comp.html.

Two public key crypto-systems are well known:

  • the RSA (named after it's inventors Rivest, Shamir and Adleman) developed at MIT in 1977. A key minimum key length of 768 bits is recommended by RSA Inc. RSAREF is a library from RSA Inc. which is integrated into many commercial products and public domain products (such as the US version of PGP). International, public domain RSA compatible libraries (with large key sizes) do exist and are used in products such as SSH (SSH uses 1024 bit keys by default. It is described below under "Sample authentication products").
  • Diffie-Hellman (named also after it's inventors) which produces shared secret keys from publicly known information. Sun make extensive use of this algorithm in Secure RPC and SKIP. This algorithm has the added advantage that it's patent expires in 1997.

Both of the above are patented in the U.S. PKP (Public Key Partners) of Sunnyvale, CA hold the licensing rights. Although DH patent is now out of date and THE RSA patent only hold until 2000. The public-key algorithms rely on difficult-to-solve mathematical problems such as taking logarithms over finite fields (Diffie-Hellman) or factoring large numbers into primes (RSA) to create one-way functions. Such functions are much easier to calculate in one direction that in the other, making brute force decryption virtually impossible (with today's computing power and decent key sizes). Newer techniques such as Elliptical curves and mixture generators (e.g. RPK at www.rpk.co.nz) are promising faster public key systems.

Advantages: Only the private key need be kept secret. No secret channels need exist for key exchange, since only public keys need be exchanged. However the public key must be transferred to the sender in such a way that he is absolutely sure that it is the correct public key! Public key cryptography also provides a method for digital signatures.
Disadvantages: Slow, due to the mathematical complexity of the algorithms.

Typical applications: Ensuring proof or origin, ensuring that only the receiver can decrypt the information.

7.1.3 Hashing / message digest

A hash function creates a fixed length string from a block of data. If the function is one way, it is also called a message digest function. These (easy to compute) functions analyse a message and produce a fixed length digest which is unique. There is no known feasible way of producing a another message with the same digest. Such algorithms are normally used to create a signature for a message which can be used to verify it's integrity.

To guarantee the integrity of data, hashing algorithms are better than shared key encryption algorithms, since:

  1. Digest functions are faster.
  2. The output is fixed length, so even a very large file produces the same (small) digest. This is much more efficient for data transmission.
  • MD2, MD4 and MD5 are hash functions developed by Ron Rivest of RSA Inc. They all produce 128-bit digests. MD2 is the slowest, MD4 the fastest. MD5 has a more conservative design than MD4. Both of these are publicly available.
  • The MD5 algorithm is the de-facto hashing standard for digests. Public domain versions are available for most platforms on the Internet and it is widely used in integrity checking systems. However some weaknesses were discovered in May 1996 by Dr. Hans Dobbetin of the German Information Security Agency, see http://www.cs.ucsd.edu/users/bsy/dobbertin.ps
  • SHA-1 (Secure hashing algorithm) is a NIST sponsored hashing function has been adopted by the U.S. government as a standard. It produces a 160-bit hash (i.e. larger than MDx) and is roughly 25% slower than MD5. SHA-1 is recommended over MD5
  • Ripe-MD-160 is an algorithm from the european community.

Advantages: much faster than encryption and output is fixed length.
Disadvantages:

  • guarantees integrity only.
  • Known weaknesses: The article, by B. Preneel and P.C. van Oorschot, "On the Security of Two MAC Algorithms", Advances in Cryptography- EUROCRYPT '96, Saragosa, Spain, May 1996. It showed some improvements on known forgery attacks on MD5 envelope method (RFC1828) and banking standard MAA (ISO 8731-2).

Typical applications: Many Internet servers provide MD5 digests for important files made available for downloading. Most digital signature systems and secure email system use a digest function to ensure integrity.

An interesting variation of hashes are Message Authentication Codes (MAC), which are hash functions with a key. To create or verify the MAC, one must have the key. This is useful for verifying that hashes have not been tampereed with during transmission. Two examples are HMAC (RFC 2104) and NMAC, based on SHA-1.

7.1.4 Applying cryptography

Applications such as PGP, S/MIME, Secure RPC (and hence secure NFS & NIS+) and SKIP use a combination public key cryptography and symmetric cryptography to ensure non repudiation and privacy. Hashing algorithms are used for (fast) generation of signatures.

  • The principal problem with most encryption systems is how to distribute and manage keys. Many systems require manual key-ring management. See Certification Authorities below.

7.1.4.1 Encryption Strength

Computers are getting faster, cheaper and better networked each year. All cryptographic algorithms are vulnerable to "brute force" attacks (trying all possibe key combinations). In general, the key length determines the encryption strength of an algorithm with the approximate formula of 2 to the power of the key length, so 56 bit keys take 65,536 times longer to crack than 40 bit keys. Mathematics advances each year, so new mathematical ideas can weaken existing cryptosystems (examples are the discovery of differential and linear cryptanlysis in recent years). Although there are many, encryption products available on the market, not all use secure algorithms or implement them properly, but also most come from the U.S. and are subject to U.S. export restrictions. The U.S. currently enforces either a 40bit limit or escrowing of keys.

  • 40bits is certainly not secure, Example: In 1995, a French student Damien Doligez succeeded in breaking a 40bit netscape shared encryption key in 8 days using a network of 120 UNIX machines (by brute force: trying all possible combinations of the key).
  • In 1996, an improved algorithm brought this down to 4 hours.
  • In 1997, 56 bit DES keys can be broken by dedicated chips (programmable gate arrays within 3 weeks) and by intelligence organisations such as the NSA within seconds. One solution is the so called Triple-DES or 3DES system, in which the data block is encrypted three times using three different keys (in a time slightly faster than 3 times a normal encryption). 3DES has a key strength roughly equivalent to 128bits.
  • Some implementations of encryption algorithms have other weaknesses, such as predictable random number generators that can degrade decryption time much more, or completely insecure algorithms such as XOR, used to protect Winword documents (Winword passwords are available in seconds using utilities found on the Internet). Pkzip also has a relatively weak algorithm.
  • Computing power doubles about every 2 years.
  • 128 bit shared keys and 2048 bit public keys are currently considered to be strong enough to withstand the evolution of computing power in the foreseeable future.
  • Key strength is more important for public keys since they are often use for digital signatures and non repudiation and are rarely changed.
  • The strength of current PK systems is based on the difficulty of the mathematical factoring and discrete-logarithm problem. It is not impossible that faster mathematical methods to solving these problmes be found, making PK guessing easier.
  • See also Minimal Key Lengths for Symmetric Ciphers (1996)

Recommendations:
The encryption key size should be chosen, based on who you wish to protect your information from, and how insecure the transport network is (sending information over the Internet certainly requires more protection that on your local subnet) and how long the information must be protected. It is better to use weak encryption than not to protect data at all, however the danger of a weak encryption system is that it can give users a false sense of security.

  • Protecting against individuals/hackers(up year 2000): Public Key 1024bit, shared key 60 bits.
  • Protecting against governments and very large corporations (up year 2000): Public Key 2048bit, shared key 128bits.
  • Weak (40bit shared/512bit public) key encryption is acceptable for protecting internal working (not highly sensitive) documents that have a lifetime of a few months.

7.1.4.2 Legal Issues / Export restrictions (Sep.97)

The U.S. and certain other countries consider encryption to be a weapon and strictly control exports. This is basically crippling the efforts to include encryption in Applications, Internet services such as Email and Operating systems.

  1. In general the U.S. allows export of 40bit shared key systems and 512 bit public key systems. This is not enough for most applications, since such keys are breakable on powerful computers (see next section).
    • Exceptions: There have been some exceptions to this rule, such as export to Canada & Australia and to large financial institutions worldwide.
    • Lotus export Notes with a 64bit key, of which 24bits are escrowed with the U.S. Govt., making more difficult for non U.S. agencies to look at your Notes communications!
    • Certain products may be used by U.S. companies outside the U.S.
    • Vendors have started building Interfaces into which strong encryption products can be plugged, assuming they're available internationally. E.g. Eudora Pro has a Plugin API which could allow seamless integration strong international encryption unit, without break U.S. law. Other examples at Sun (Solaris DES & Diffie Hellman libraries), Microsoft (NT Secure API), Qualcomm (Eudora Pro + PGP), various PGP Plugins and GUI's.
  2. Certain other countries (e.g. France), forbid encryption except when a key has been deposit in an escrow (so the legal authorities can listen to all communications if they need).
  3. Certain countries allied to the U.S. (e.g. Germany, UK, Sweden, etc.) also enforce the U.S. restrictions by allowing strong encryption domestically, but restricting export of cryptographic devices.
  4. The OECD made a set of recommendations on international cryptography in June 1997, see http://www.oecd.org/dsti/iccp/crypto_e.html.
  5. Many countries have almost no restrictions (e.g. Ireland, Finland), but some (especially European) countries are considering some kind of restriction of the use of cryptography.

The only strong encryption software widely available internationally, known to the author of this document, are from Australia, Finland, Ireland and Russia.

7.1.4.3 Digital Time-stamping Service (DTS)

A DTS issues a secure timestamp for a digital document.

  • A message digest is produced of the document (by the sender) and sent to the DTS. The DTS sends back the timestamp, plus the date & time the timestamp was received with a secure signature form the DTS. This proves that the document existed on the said date. The document contents remain unknown to the DTS (only the digest is known).
  • The DTS must use very long keys, since the timestamp may be required for many years.

7.1.4.4 Certificates, Certification Authorities (CA) and Trusted Third Parties (TTP)

Certificates are digital documents attesting the identity of an individual to his public key. They allow verification that a particular public key does in fact belong to the presumed owner. The ISO certificate standard is X.509 v3 and is comprised of: Subject name, Subject attributes, Subject public key, Validity dates, Issuer name, Certificate serial number and Issuer signature. X.509 names are similar to X.400 mail addresses, but with a field for an Internet email address. The X.509 standard is used in S/MIME, SSL, S-HTTP, PEM, IPsec Key Management.

Where sender and receiver must be absolutely sure of who their Peer is, a certification authority (CA) is a possible solution. Another name for a CA is a Trusted Third Party (TTP). If both sides trust a common authority, this Authority can be used to validate credentials from each side. E.g. the sender sends his public key, name (and other validifying information) to the CA. The CA verifies this information as far as possible, add it's stamp to the packet and sends it to the receiver. The receiver can now be surer than the sender is who he says he is..

Certificates are issued by the CA. The CA is a trusted authority, who confirms the identity of users. The CA must have a trustworthy public key (i.e. vary large) and it's private key must be kept in a highly secure location. CAs can also exist in a hierarchy, which lower level CAs trust high CAs.

The problem with CAs are that you have to trust them! However, even Banks have overcome that problem with the implementation of SWIFT, a world wide financial transaction network.
See also:

7.1.4.5 Emergency File Access

A frequent requirement when protecting file confidentiality via encryption is Emergency File Access. If the file owner encrypts an important file and forgets the key, what happens? A second key is created, split into five parts such that any two of the five (partial) keys, when combined, could be used as a decryption key. The five (partial) keys could be kept by separate people, only to be used if the original owner was not able to decrypt the important file.

  • RSA provided a beta package for Windows based on the above (RSA Secure) in 1995. As usual only a 40bit version was available outside the U.S. It works well together with Window's file manager, but is not yet integrated into Win95's Explorer (Jan.1996) or into Windows NT. Unfortunately it disappeared from the RSA website in 1996, and RSA sell no equivalent product today.

7.1.4.6 Secure Data Transmission using cryptography

Secure data transmission is the exchange of data in a secure manner over (presumed) insecure networks.

Requirements
Secure data transmission is required for class systems or higher and can be divided into the following categories:

  1. Peer entity authentication: Both sides (users & processes) must identify & authenticate themselves, prior to the exchange of data.
  2. Data integrity: Data must remain complete during transmission. Unauthorised manipulation of user data, audit trail data and replay of transmissions shall be reliably identified as errors.
  3. Data confidentiality: Only authorised persons should be able to access the data. (e.g. end-to-end data encryption).
  4. Data origin authentication : Does the receiving process know who the data is coming from? For class systems, non repudiation of origin may be required: On receipt of data, it shall be possible to uniquely identify and authenticate the sender of the data. Has the receiver proof (e.g. digital signatures) of where information came from?
  5. Non repudiation of receipt : Has the sender proof that the information sent was received by the intended receiver?
  6. Access control : All information previously transmitted which can be used for unauthorised decryption shall be accessible only to authorised persons.

Secure data transmission is achieved by the use of cryptography. There are two principal cryptographic methods, public key and shared key. Normally a mixture of both is used for secure communication.

Using Cryptography for secure transmission
When choosing an authentication system, choose a signature function and encryption method and hash function that require comparable efforts to break.
The encryption algorithms described in the previous section can be combined together to produce a system for secure data transmission (refer to the diagram below):

  1. Data integrity: MD5 digests are created on the data part of message.
  2. Non repudiation of origin: Use public keys. i.e. the sender encrypts all or part of the message encrypted with his private key. Often only the message digest is encrypted (for performance reasons). The receiver (decrypts with the senders public key) is sure that the message comes from the correct sender, because only the sender knows his private key. For performance reasons, normally it is sufficient to encrypt the MD5 digest noted above. The digest encrypted with the senders private key is called a signature.
  3. Non repudiation of receipt: not covered here.
  4. Data confidentiality: Confidential parts of the message are encrypted. Shared key encryption is the most efficient method (performance). Normally the shared key is calculated from information known to both sides e.g. the sender uses his private key + receivers public key and the receiver uses his private key + senders public key. They can both generate the same unique key due to the mathematical properties of public key algorithms (i.e. multiplying numbers raised to powers). This data encryption key is often called the session key (it is valid only for a particular session).
  5. Peer entity authentication: Where sender and receiver must be absolutely sure of who their peer is, a certification authority is a possible solution. If both sides trust a common authority, this Authority can be used to validate credentials from each side. E.g. the sender sends his public key, name (and other validifying information) to the Authority. The Authority verifies this information as far as possible, add it's stamp to the packet and sends it to the receiver. The receiver can now be surer than the sender is who he says he is. Similar encryption and hashing to that above would be applied this data.
  6. Access control: not covered here (depends on implementation).

The data is prepared for transmission:

After receipt, the data is decrypted:


Example systems using this approach: Sun's Secure RPC (hence NIS+, NFS), SKIP, S/MIME isn't a million miles away either.

Using FTP for secure file exchange

Ftp is available as standard on many platforms, so you may find it a convenient method of transferring data between say, an UNIX machine and an IBM mainframe. What needs to be done?

  1. Ftp transfers username and password in clear text, therefore do not reply on password protection as the main security barrier.
    • In an automated environment, the username and password could be changed daily on both sides according to a predefined algorithm.
    • The ftp server side should log all connections.
    • The ftp server side should disable an account if an invalid password is received.
  2. Encrypt files before transfer and decrypt after receipt (use private/public keys where proof of origin is required).
  3. Validate file integrity using MD5 digests.
  4. The ftp sources can be altered to remove unwanted commands (e.g. only allow get), change default ports or slightly change the protocol - all of which should increase security. The sources may be had from ftp.uu.net:/packages/bsd-sources.
  5. SSH can also be used to setup PASV FTP over a secured tunnel (SSH2 includes an encrypted ftp client: recommended).

7.2 Sample encryption products/protocols

It is not realistic to expect the Network to be ever 100% secure. The tendency today is to design transparent encryption into the upper layers of the ISO model that can transfer data securely across insecure networks. For encryption which is transparent to applications and routers, IP level encryption is used.

7.2.1 SSH (Secure SHell)

This section has been moved to a separate document ssh_stuff.html.

F-Secure Desktop V2.0 (file encryption)

This product, exported from Finland, allows military strength encryption of files on Windows systems with an easy-to-use GUI. For more information, see http://www.datafellows.com/f-secure

F-secure desktop is interesting for:

  1. Taking a bundle of files, creating an "encrypted package", sending this package (via email or diskette) to someone else anywhere in the world and allowing them to securely decrypt the files, without having F-Secure desktop themselves.
  2. Encryption of files (local or on a network server) on a file-by-file basis, to protect the privacy of files.
  3. Automatic encryption of a list of confidential files when you log out and decryption when you login in. This mode is only recommended for local files, NOT files on network servers.
  4. Secure deletion of confidential files.

Ease of use/features:

  • When starting Win95/NT4, a logon box pops up, asking for the F-Secure user name and password to allow files marked for automatic encryption to be decrypted. Top secret files are automatically encrypted, but not decrypted. If ESC (Escape) is pressed in this box, no files are automatically decrypted, but they may be individually decrypted by double clicking in the explorer. This speeds logon time to the PC when encrypted files do not need to be accessed.
  • Several files can be selected for encryption in Explorer at one time, meaning that the password only needs to be entered once. However, the general behaviour is that the password has to be entered for each encryption and decryption operation.
  • Several user names/password combinations can be accessed on the same machine(if several key files exist), when logging in. This is useful when, for example, a user has a private key and a group key (so that all files in his working group can be shared by group member). Unfortunately the user name can only be chosen during logon and not via the control panel or explorer shortcut.
  • When a new user name/password pair is generated, a backup of the key, protected by a different password can be made to another disk/directory. A backup of the key in this manner reduces the possibility of data loss due to forgotten passwords, faulty disks etc.
  • When files are encrypted, the original version is securely deleted (may be overwritten 1, 3 or 6 times).
  • Both 3DES and blowfish can be used as encryption algorithm.
  • An encrypted package of files can be created, encrypted and sent off to someone else as a self extracting executable. The other side only need to know the password. Nice feature, new to V2.0.

Performance:

  • For a directory containing 5MB of Office files, encryption takes 35 seconds and decryption 15 seconds (on a P5/90, 16MB RAM with Win95 and V1.0 F-Secure Desktop). Encryption is slower because the original unencrypted files are securely deleted (overwritten) 3 times. If the less secure option of delete/overwrite in one pass is used, encryption time for the above reduces to 20 seconds.
  • If a lots of confidential data is kept on a PC (say 100MB), then encryption could take 12 minutes during logout. The way around this problem is to only use the auto-encryption feature for frequently used files and manually encrypt/decrypt the remaining files. This is also more secure.

Advantages:

  • Well integrated into the Windows, Win95 & NT4 environment.
  • Strong encryption (3DES or Blowfish may be selected in V2).
  • V2.0 allows classification of files into top secret, secret and unclassified.
  • Files may be compressed as well an encrypted (V2 only).
  • A set of files or directories can be bundled into an encrypted package (for archiving or secure transport). The package is a self extracting executable, the other side only needs the password.

Problems: No integration with the MS-Office programs/environment.

  • Not really suitable for secure email exchange (since no public key or hashing algorithms are used). Although the encrypted package option does allow a certain secure exchange of data.
  • Automatic encryption/decryption by dragging between encrypted and normal folders is not supported. If the Microsoft CryptoAPI was US exportable this would probably be easier to implement.
  • The profile used for encryption cannot be chosen when individually encrypting a file. The user profile selected at login time is used. A user may wish to encrypt/decrypt certain files with his private profile and other files with, say the shared profile of his working group. He must log out and in again to use a different key!

Recommendations:

  • It is essential to make a backup of the key file and store it in a physically safe place.
  • Keep the auto encryption list from getting too big, it slows down boot time drastically.
  • Don't use the auto-encryption feature on network files/directories, as the concerned files will not be encrypted during the entire logon session (which typically lasts one or more days).
  • If you're encrypting files that may not be decrypted for along time (e.g. a few years) then perhaps the F-Secure Desktop won't be on your machine when you need to decrypt the files or the key may have been lost, then consider creating an encrypted package instead.

If the main use of this product is to encrypt Word (or MS-Office) files, be aware that MS-Office itself is very insecure:

  • Using Word to "password" protect files is complete waste of time. Utilities exist on the Internet to break the password in fractions of a second.
  • If Word crashes (or the PC crashes), Word can leave confidential info lying around in TMP files and "$" dollar files.
    Fix: Login into the PC again and recover files, then shutdown properly. Restart and securely delete any temporary files.
  • Word uses temporary files (TMP) that are not securely deleted (overwritten 3 times with random data for example), so these files could contain and be restored to divulge sensitive data.
    Fix: Add a utility that securely deletes all word TMP files when starting up (e.g. the DOS utility DESTROY.EXE). This has the bad side effect of deleting temporary files that can be used to recover data after a crash. So recovery of word documents after a crash will no longer work.
  • If Word files are deleted with normal Win95/DOS commands, they can still be in the Recycle Bin or easily be recovered from the hard disk (DOS does not delete, it merely renames the first letter of a file name to "?").
    Fix: use a special secured utility to delete files (e.g. F-Secure Desktop "Secure Delete", accessed when right clicking a file in Explorer). Don't leave them in the recycle bin. Consider switching to NT (and the NT filesystem) rather than Win95 (and the FAT filesystem).

    7.2.2 SSL (Secure Socket Layer) V3 (Mar.1997)

    Netscape's secure socket layer is a "plug-in" socket layer (port 443) offering client & server authentication, integrity checking, compression and encryption. It is currently an Internet draft (not yet approved).
    It is designed to fit on the transport layer in the TCP/IP stack (like Berkeley sockets), but below applications (such as telnet, ftp, HTTP). SSL was introduced in July 1994. It is designed for use in Internet WWW commerce applications, but also on LANs. The Netscape Navigator and Microsoft explorer both provide support for SSL V2 and V3 (Explorer 3.0, Navigator 3.0). Web servers supporting SSL3 include Apache & Netscape. Microsoft's IIS supports only SSL2 at the moment.

    Algorithm:
    The client connects to the server and sends a list of supported encryption algorithms. The server replies with algorithm name, his public key, a shared key and the hash algorithm name. The client can check if the public key does belong to that server. The client generates a session key and sends it encrypted with the server's public key to the server. The server decodes the session key (with his private key) and uses it to encrypt data transmitted during the session. The client checks the server by sending random string encrypted with the session key. The server confirms receipt.
    The above authentication method can also be used by the server to authenticate the client, however it must have a public key for the client (not the case for WWW applications).

    • SSL has built in key exchange capabilities, which favour a client wanting to securely connect to a particular server. Normally, the server cannot authenticate the client, as it receives the clients public key without being able to authenticate it. These scheme suits the WWW commerce requirements. However, if the server has a digital signature (certificate) of the client, it can authenticate it.
    • The key functions of authentication, compression, integrity checking and encryption are cleanly separated and may be used independently
    • SSL V3 is cipher independent, the choice of cipher and compression algorithms are with the server, not the client. The defined algorithms are MD5 and SHA (for integrity checking - hashing), RSA (for public key encryption) and RC2,3,4 (in different variations), DES (40 & 56 bit) and 3DES (for symmetric encryption).
    • Most sites have a firewall with a HTTP proxy between WWW clients and the Internet. This poses problems for SSL which is designed to avoid "middlemen". There is an SSL Tunnelling CONNECT extension (supported by the Netscape Proxy Server for example). It is described at http://developer.netscape.com/library/one/sdk/proxy/unixguide/ssl-tunl.htm . SOCKS may also be used for proxying. SSL can't be cached by the proxy, but can by the browser (where it is probably not encrypted).
    • => The big problem with using SSL is high security applications is that it is subject to U.S. export regulations, meaning that the encryption strength is low (so that the U.S. authorities can monitor us easily).
    • HTTPS
      HTTPS is HTTP on top of an SSL layer, normally using port 443. To try HTTPS, connect to https://networth.quicken.com/ . If you use Netscape Navigator, the broken key on the bottom left corner will become "unbroken" indicating that the session is encrypted. One tooth on the key indicates 40bit and 2 teeth indicate 128 bit encryption.
    • Other service are also destined to run over SSL such as secure email (ssmtp/port 465 and spop3/ port 995) and secure NNTP (snews, port 563).

    References:

    1. SSL, V2.0 is documented at http://home.netscape.com/newsref/std/SSL_old.html .
    2. V3.0, as documented at http://home.netscape.com/eng/ssl3/index.html or http://home.netscape.com/newsref/std/SSL.html .
    3. A reference implementation of SSL is available at http://home.netscape.com/newsref/ref/sslref.html
    4. SSL-Talk Email discussion list: Send an email to ssl-talk-request@netscape.com with the *subject* being the single word SUBSCRIBE.
    5. Secure Sockets Layer Discussion List FAQ, http://www.consensus.com/security/ssl-talk-faq.html .
    6. SSLeay is an independent SSL implementation from the Australian Eric Young. It uses publicly available versions of the encryption algorithms.

    7.2.3 PCT V1.0

    Microsoft's Private Communication Technology (PCT) is aimed at replacing SSL. It is more general in nature. Authentication and encryption negotiation are separate. It is used in Explorer 3.0. Coming from Microsoft, it is not compatible with anything else, but could become a standard.

    TBD: How does authentication & key distribution work?

    Microsoft proposed to the IETF (in April 1996) and Netscape a combined SSL/PCT implementation to ensure compatible solutions for Internet commerce. See http://pct.microsoft.com/

    7.2.4 S-HTTP (Secure HTTP)

    S-HTTP is a extension of the HTTP protocol which can run on top of "normal" TCP/IP, developed by CommerceNet. It provides services for transaction confidentiality and works on the application layer, specifically for secure HTTP connections. CommerceNet is the CA in the current implementation. See www.commerce.net/information/standards/shttp.txt .

    • S-HTTP is supported by Netscape Navigator and Microsoft's explorer? Or only Spyglass client and OpenMarket server? Uses port 7070?
    • RSA and DSA are used for signing.
    • DES and RC2 are used for encryption.
    • MD2, MD5 or SHA are used for message digests.
    • Encapsulation formats of PGP, MOSS and PKCS-7 may be used.
    • Key exchange is possible via Diffie-Hellman, Kerberos, RSA, In-band. Public keys are stored in X.509 or PKCS-6 format.

    7.2.5 J/Crypto, CST (Sep'97)

    Baltimore Technologies (http://www.baltimore.ie/) offer strong encryption libraries for C, Java 1.02 & 1.1 and Visual Basic in addition to strong encryption addons to Web servers for secure browsing.

    7.2.6 SKIP (May'98)

    SKIP  (http://www.skip.org/) offers link level encryption, the encryption taking place below the transport layer. It also includes a scheme for authentication, key management and certification authority. Many different encryption algorithms may be used (3DES, DES, RC4, the public key exchange is based on Diffie-Hellman). SKIP could be used for encrypted VPNs (end-to-end, firewall-firewall or end-to-firewall) or encrypted client to server communication. SKIP was developed by Sun Microsystems, who put the source code into the public domain. This is why it may become a standard. Of course due to U.S. export restrictions, the SKIP we get here in Europe (from Sun) is watered down with a smaller session key size.

    SKIP was proposed as an Internet Standard at the December 1995 IETF meeting by Sun. The IETF allowed SKIP to proceed as a proposed and elective/optional standard. Version 0.5 was released in November 1995. The current version is V2, which has the following new features:

    • support changes in IPsec transforms
    • self-generated local identities (UDH, NSID=8)
    • Certificate discovery protocol
    • multiple local identities (slotting)

    See the section "Secure Data Transmission using cryptography" above for basic a description of how SKIP works. SKIP uses a Sun CA (or local CA wiht V2) to verify the validity of keys.

    • The Sun Sunscreen and Checkpoint Firewall-1 firewalls (amoung others) can use the SKIP protocol to setup encrypted (secure) connections over public networks such as the Internet. See the Firewalls chapter.
    • Sun also have SKIP clients for Solaris, Win95 & NT.
    • A Russian company "Elvis+" have also produced SKIP compatible software called FortE+ with PC clients and NT/Solaris servers. See http://www.elvis-plus.com/ . This software is not subject to U.S. export restrictions, so strong encryption is available. The Win95 & NT4 verison have been successfully used  by the author (with strong encryption keys) in small user groups and also work with Sunscreen 100 firewalls.

    7.2.7 IPv6 (IPng) (July 1996)

    IPv6 is the up-and-coming replacement for the current Internet Protocol V4. V6 is needed especially for it's much greater address range, 128bits as opposed to 32 bits (IP addresses are getting scarce), but it also provides security features for improved integrity, authentication and confidentiality not found in the current version.

    IPv6 is located on the network layer and can encrypt all data above this layer (including for example the transport headers). The are two basic encryption modes:

    • The only the data to be transmitted (payload) is encrypted. The headers are not encrypted.
    • The whole IP packet is encrypted and a new unencrypted header is attached to the packet. This is known as "tunnel mode". The Encapsulated Security Payload (ESP) in V6 provides both integrity and confidentiality. It is cipher independent, but DES is being proposed as the default cipher. Tunnel mode can allow unencrypted communications on the LAN and automatic encryption for WAN connections.

    For improved integrity checking, the IPv6 Authentication Header uses the keyed MD5 algorithm for integrity checking.

    Key exchange mechanisms are not yet defined, but the Internet Key Management Protocol (IKMP), an application layer protocol, should be submitted to the IETF by March 1997.

    7.2.8 Photuris

    Photuris is a session key exchanged protocol, still under development (V 08 was released in December 1995). It is proposed for use in RFC-1825 by the IPsec group. It may become an IETF standard in 1996.

    TBD: How does it work?

    7.2.9 PGP (Pretty Good Privacy) (Mar.'97)

    PGP (Pretty Good Privacy) is an encryption system developed by Philip Zimmerman for ensuring data confidentiality and (partially) proof of origin. It is primarily used together with Internet email products such as Eudora or Elm for signing and/or encryption of information. Local files may also be signed/encrypted. Is uses RSAREF and IDEA encryption methods (for public and shared key encryption respectively) and works on almost every platform from mainframes to PCs. It is freely available for non-commercial use., with two principal versions: one for the USA using the RSAREF encryption library and an international version using a non-USA equivalent of RSAREF. The current "standard" version is 2.6.3 (released Feb.96), with a new Vesion 5 released in 1997 (that is not backwards compatible). A commercial version is available from ViaCrypt (for USA users).
    Further information:

    http://world.std.com/~franl/pgp
    http://www.pgp.net/

    Disadvantages:

    • PGP's main weakness is the lack of integration with standard mail utilities delivered with operating systems, the exceptions below not withstanding.
    • Almost no commercial email systems directly support PGP.
    • IDEA licenses are required for commercial use (from Ascom). IDEA is an encryption algorithm developed by the ETHZ, which requires licensing for commercial use.
    • Can be difficult to use for "normal" users. It is a command line utility. Some graphical front ends exist, but they still call the PGP command line and errors messages/debugging is on the commands line, so a DOS window is started for each command. This is not user friendly! One solution is the commercial windows DLL library with PGP function, however this is only available in the U.S. at the moment (TBD: verify).
    • Key management for a large group of users is difficult. TBD: analyse/discuss PGP keyservers.
    • Some companies have a policy not to use PGP.
    • NT filenames with special characters (commas, spaces etc.) are not handled properly, being converted to shorter names.
    • Graphical front ends for PGP are rarely free, most are shareware.

    Advantages:

    • PGP is an international, open standard, with new tools constantly being developed. Each year this tools advance considerable.
    • PGP is internationally recognised and available without U.S. export restrictions. It's encryption mechanism are very strong (if used correctly).
    • It is freely available for non-commercial use (commercial users need to pay the IDEA license from Ascom).
    • PGP can also be used as a shared key file encryption system (using the IDEA algorithm).
    • It can also be used for checking the integrity of important files on servers (by creating a signature for each file).
    • PGP works on many different computer types. The keyrings can be exchanged between different systems.

    Recommendations:

    • Do not use the PGPPASS environment variable to store the pass phrase. This reduces security drastically, unless the user workstation is physically secured from unauthorised access.
    • The pass phrase must be very carefully chosen/protected, especially when user workstations are not physically secured.
    • If you download PGP from the Internet, verify the PGP signature (see the README file for details).

    PGP Tools available (selected):

    • A 32 bit version for Win95/NT is available (see http://www.pgp.net/ ). The PGP (command line) is in fact available for just about every platform from Mainframes to PCs. PGP is Freeware.
    • A nice Win95 graphical front end PGP Shell (pgpshe33.zip) is available from Aegis. WinPGP Shell worked well for technical users. The current version is free, the new V5 32bit version will be shareware when it is released. The new version allows files to be dragged & dropped and allows encryption for multiple recipients (although more than 9 recipients does not work). Multiple files cannot be dragged/dropped either.
    • WinPGP 5.0b (Shareware, cost $29/user) is one of the best GUI for Win95/NT currently. It can encrypt/decrypt/sign files as well as send encrypted files via Email with Exchange, but cannot receive email.
    • PGPWord7 (Shareware, $20) allows Word documents to be directly encrypted within Word7. Problems: Documents opened by drag & drop or by selection from the file menu history are not automatically by this utility. Does not always install correctly. User interface has problems.
    • Lock & Key (Shareware, $15) provides Win95/NT4 Explorer integration. One recipient only. ZBD: Shared key encryption of local files?
    • PGP extension for MS-Exchange (Freeware, beta) allows emails send from Exchange to be encrypted. Cannot encrypt attachments. It can connect to a keyserver to get public keys (untested). Buggy? Other problems?
    • CryptoEx: is a commercial solution for integrating PGP into Exchange. It is untested (yet), the following is a description from the WWW home page:

      CryptoEx ist the first professional PGP extension for Microsoft Outlook and Microsoft Exchange. ... It automatically recognises encrypted emails and offers an easy-to-use keyring administration. .... A user-friendly administrator tool helps distributing CryptoEx and managing user options in large Windows networks.
      Features: User-friendly encryption and signing of all emails and their objects, automatic recognition of encrypted and signed mails, automatic detection of public keys as part of an email and their optional insertion into a keyring. Complete administration of keyrings. integrated public key search on keyservers, support of keys up to a length of 2048 bits, optional creation of a Corporate Master Key, an emergency escrow key which can decrypt all mails encrypted by a company's employees. Optional creation of a Retirement Key, an
      escrow key which can deactivate keys of former employees. Public Keys can be centrally administered and synchronized using Microsoft Exchange's own replication feature. Although preferences and options are fully integrated into the Exchange and Outlook
      user interface, they can be centrally configured and hidden from the user by the network's administrator. The administrator can thus eliminate security gaps such as misconfigurations by the network user.

      A keyserver solution for large intranets will be available soon.
    • Keyservers?
      • AT&T PathServer: PathServer is a service to help you have secure communications on the Internet. A basic tool for facilitating secure communications in environments like the Internet is public key cryptography. Very briefly, public key cryptography enables each user to have a public key, which she distributes widely and a private key that she keeps to herself. She can sign messages in a way that anyone with her public key can verify that she sent the message, and anyone with her public key can encrypt messages so that only she can decrypt them. PathServer is a tool to help users to determine to whom a public key belongs, i.e., to "authenticate" the key.
    • Win95/NT registry hacking: By adding a few entries to the registry, Explorer "right-click" menu entries can be created for quickly selecting encryption/decryption of pgp files destined for a small fixed groups of users. This solution only works well for PGP file exchange inside a small trusted group of users. The registry entries could be used to start a small application which would select the target user group. This application would have to be developed.
    • A "Sun Mailtool" look-alike that integrates PGP is publicly available called privtool (ftp.ox.ac.uk/pub/crypto/pgp/utils ). It is still in beta however, only works on Sun and not all functions work correctly. Freeware.

    7.2.10 S-Tool (UC)

    This public domain utility allows text messages to be stored clandestinely in graphics (GIF) or sound (WAV) files (known as stegography). Use together with PGP, it can be use to create covert channels. TBD.

    7.2.11 SET (Secure Electronic Transmission) - June 1997

    Secure Electronic Transmission is a set of protocols for electronic commerce proposed by VISA, Mastercard and American Express (since Feb. 1996). SET uses MIME (the MIME type is not yet defines) to transport messages. SET 1.0 was released in May 1997.

    Authentication: The server requests authorisation, the server key is authorised by a CA, keys are exchanged with the client and the transaction occurs. The SET digital certification includes an account number and public key.

    SET 2.0: Version 2.0 will feature a much-needed encryption-neutral architecture that encourages the development of faster (than RSA encryption used in SET 1.0) electronic-commerce applications. Vendors such as Certicom, Apple Computer, and RPK are all positioning themselves as alternatives to RSA. Elliptic Curve Cryptosystem (ECC) is a technology that is being pushed by both Certicom and Apple. See also

    http://www.mastercard.com/
    http://www.certicom.com/
    http://www.apple.com/
    http://www.rpk.co.nz/
    http://www.visa.com/cgi-bin/vee/sf/standard.html?2+0

    7.2.12 Encryption Products available outside the U.S.

    U.S. exportable products are MD5, MD2, RC2/RC4 (with 40-bit keys), 40 bit DES. Public key systems are exportable with 512 bits. Are restrictions are enforced unless your are a renowned financial institution or are a government department of a close ally. So U.S. exported products are basically useless for protecting very sensitive data.

    • SKIP, Secure RPC: A 40 bit shared key and 512 bit public key version is available from Sun. A strong version of SKIP is available from the Russian company Elvis+ (http://www.elvis-plus.ru/ ).
    • PGP: See the PGP section above.
    • SSH..
    • IDEA, DES, 3DES, RSA and lots of other algorithms have been implemented in the public domain and are available on the Internet.
    • At last, some European companies have started producing strong encryption products to fill the vacuum created by the U.S. export restrictions. See Baltimore Technologies (http://www.baltimore.ie/ ), Siemens Ireland (with TRUSTEDWEB) and R3/Swissonline (http://www.r3.ch/ ).

    7.3 Authentication

    Authentication is the process of verifying the identity of a subject. A subject (also called a principal) can be a user, a machine or a process i.e. a "network entity".
    A user is often authenticated by a name and password, but other possibilities exist. Authentication uses something which is known to both sides, but not to others. Hence this can be biometrics (fingerprints, retina patterns, passwords), one-time password lists, identity cards, smart-tokens, challenge-response lists etc. Some systems consist of a combination of the above.

    The most common methods of secure authentication today consist of one-time password lists (paper), automatic password generators (smart tokens) and intelligent identity cards.
    A few sample authentication products are discussed in the "Firewalls" chapter.

    7.3.1 Summary of authentication mechanisms

    There is no industry standard today. Many different efforts are underway. In particular the Federated Services API, GSS API and RADIUS seem like a logical ways to interconnect the current incompatible systems, without requiring vendors to throw away their existing products. It is hard to image such an API offering more that basic functionality however (since advanced functionality is not common to all products).

    For enterprise wide authentication and naming services DCE and NIS+ seem to be the current main runners. These will probably tend towards X.500 directory services compatibility, allowing a interoperability gateway to be built. The fact that neither DCE not NIS+ have been fully adopted in the PC client world is a pity, but perhaps reflects pricing and complexity problems.

    SSH is a really impressive product for secure access to UNIX machines.

    For authentication across unsecured networks, proprietary (incompatible, expensive) encrypting firewalls are the current solution. Possible future acceptance of proposed standards such as SKIP or IPv6 will, hopefully, provide long term interoperability.

    7.3.2 Logon

    Client/server applications run on many different types of systems from IBM mainframes, VMS, UNIX to PCs. Unfortunately each of these systems has it's own way of authenticating users. Database logins are normally not integrated with OS (user) logins. Usually a Username and Password identifies a user to the system. If each system and application has it's own logon process, then the user is confronted with an array of (possibly) different usernames and passwords. This poses a real security risk, as the user may be tempted to write down all the different passwords, change them rarely, or use simple ones.

    The ideal solution would be to provide a secure single signon. i.e. when a user logs on to a workstation on the network, his identity is established and can be shared with any system or application. Any user can sign from at any system anywhere and have the same name and password. The user needs to remember only one password. An even more secure signon can be achieved by using Personnel ID Cards to validate the user (via a card reader on each workstation) or via hand held Smartcards (with one time passwords).

    Achieving single signon is not an easy task in today's heterogeneous environment, but it would seem that Kerberos is the main contender with Sun's NIS+ also an option.

    7.3.3 Kerberos

    Kerberos is a secret-key network authentication service developed at MIT by Project Athena. It is used to authenticate requests for network resources in a distributed, real-time environment. DES (i.e. shared key) encryption and CRC/MD4/MD5 hashing algorithms are used. The source code is freely available (for non-commercial version) and Kerberos runs on many different systems.

    Kerberos requires a "security server" or Kerberos server (KDC) which acts as a certification authority, managing keys and tickets. This server maintains a database of secret keys for each principal (user or host), authenticates the identity of a principal who wishes to access secure network resources and generate sessions keys when two users wish to communicate securely.

    There are many versions of the Kerberos authentication system:V3 (MIT), V4 (commercial: Transarc, DEC) and V5 (in beta/RFC 1510, DCE, Sesame, NetCheque). BSDI is the only OS to bundle the Kerberos server. Solaris 2 bundles a Kerberos client, which among other things allows NFS to use Kerberos for authentication.

    Microsoft intend supporting a verion of kerberos in NT5, it remains to be seen how compatible it will be with existing versions.

    Kerberos is not without problems:

    • Digital signatures (and proof or origin) are not supported.
    • Client and server software must be adapted "kerberized" for Kerberos.
    • Administration is complex.
    • Plain text passwords may be stored on the security server.
    • "windows" can remain authenticated for hours.
    • Single point of attack: The Security server is totally trusted and if compromised, the entire network is compromised. (This is partly due to the fact that public key cryptography is not used).
    • Kerberos does not scale well i.e. there is no hierarchical domain concept.
    • User/machine combinations are not authenticated.
    • Incompatibility between V4, V5, DCE or Sesame dialects.
    • International version has no encryption.
    • Availability: Backup or replica servers are not available ?? TBD.
      See also http://nii-server.isi.edu/info/Kerberos

    7.3.4 NIS+

    NIS+ is a hierarchical enterprise wide naming system, based on Secure RPC. In the default configuration it provides user, group, services naming, automounter and key distribution. NIS+ can be easily extended to define customised tables.

    NIS+ is an improved version of the UNIX defacto standard NIS (Network Information System, or yellow pages). NIS & NIS+ were developed by Sun. NIS is available on most UNIX platforms, but has very weak security. NIS+ is much more secure but it only available on Sun's Solaris and recently HP-UX and AIX.

    Security is based in the use of Secure RPC, which in turn uses the Diffie/Hellman public key cryptosystem.

    • See also the UNIX chapter for Technical guidelines on the use of NIS+.
    • NIS+ is very flexible and can be easily extended to manage customised tables.
    • It is stable (Solaris 2.3 or later with the correct patch) enough for production use.
    • It's structure is hierarchical, making it the only major current system which can be used enterprise wide.
    • NIS+ is integrated into the Sun Federated Services (see below) with Solaris 2.5 and higher.

    Disadvantages:

    • The current implementation from Sun begs a better graphical user interface.
    • How well is it supported by IBM or HP? (Apr.96: I've had unofficial confirmation that HP now supports NIS+). Digital's plans to support NIS+ are unknown.
    • No Win95 or NT clients existed in early 1995, but I think the currect "Solstice client" from Sun supports NIS+. It is certainly not supported by Microsoft.
    • Complex administration and no well designed GUI administration tool exists.
    • The key size used by Secure RPC is 512 bytes, which needs to be increased, given the speed of modern workstations.
    • No user GUI for changing passwords/settings is available.
    • The password changing client nispasswd has fixed primitive rules (i.e. not very flexible) and does not allow for dictionary checking, storing of previously used passwords or password generation.

    7.3.5 Remote Access Control Protocols: RADIUS, XTACACS

    7.3.5.1 RADIUS (Remote Authentication Dial In User Service).

    Merit Network and Livingston developed the RADIUS protocol for identification and authentication. There is an IETF working group defining a RADIUS standard.

    • RADIUS is a vendor independent protocol which should allow multiple dial-in access points to user a centralised user database for authentication. There are however man vendor extensions to the standard and the standard is evolving, meaning that not all implementations are compatible.
    • RADIUS encrypts password transmitted by a hashing technique using a shared "secret". This secret has to be introduced to both sides by an out of band communication.
    • See also:
      ftp://ftp.merit.edu/radius/releases
      ftp://ftp.livingston.com/pub/radius

    7.3.5.2 XTACACS (Enhanced Terminal Access Controller Access System)

    XTACACS is an enhancement on TACACS (Terminal Access Controller Access System), which is a UDP based system from BBN which supports multiple protocols. SLIP/PPP, ARA, Telnet and EXEC protocols are supported.

    7.3.5.3 TACACS+

    Also an enhancement on TACACS, but not compatible with XTACACS or TACACS. It allows authentication via S/key, CHPA, PAP in addition to SLIP/PPP and telnet. Authentication and authorisation are separated and may be individually enabled/configured.

    • TCP is used as opposed to UDP (enhance security).
    • Information transmitted may be encrypted.
    • ACLs and password aging are supported.
    • Enhanced auditing & billing functions.

    7.3.6 PPP Authentication protocols: PAP, CHAP

    PAP (password authentication protocol) involves the username and password being sent to a server in clear-text. The password database is stored in a weakly encrypted format.

    CHAP (Challenge Handshake Authentication Protocol) is a challenge/response exchange with a new key being used at each login. However, the password database is not encrypted.

    Some vendors offer variations of the PAP and CHAP protocols but with enhancements, for example storing passwords in encrypted form in CHAP.

    7.3.7 BoKS

    BoKS is a full authentication/single signon package for PC and UNIX systems, made by DynaSoft in Sweden. DynaSoft is a 10 year old company employing about 50 people. The following is an extract from their home page: (http://www.dynas.se/eng/prod/prod_eng.html ):

    The BoKS concept has been developed and improved by DynaSoft since 1987. It is a comprehensive security solution covering areas such as access control, strong authentication, encryption, system monitoring, alarms and audit trails. BoKS functions in UNIX and DOS/Windows environments, offers high reliability and is ported to most UNIX platforms. BoKS can also be integrated with enterprise management systems such as Tivoli and database applications such as Oracle and Sybase.

    BoKS can use Secure Dynamics SecurID smart tokens. Although the author has little practical experience with BoKS, it seems to be in extensive use where high security is required. Runs on UNIX (SunOS, Solaris and HP-UX) and PCs (Win95 & NT versions should be introduced in late 1996). BoKS uses shared key encryption (40 bit DES outside the U.S., 56bit DES in the U.S.).

    7.3.8 HTTP Basic Authentication

    A basic authentication method is supported in HTTP.

    Algorithm: A WWW client sends a request for a document which is protected by basic authentication. The server refuses access and sends code 401 together with header information indication that basic authentication is required. The client presents the user with a dialog to input username and password, and passes this to the server. The server checks the user name and password and sent the document back if OK.
    Encryption: Very weak. The user name and password are encoded with the base64 method. Documents are sent in clear text.

    7.3.9 NT Domains / Lan Manager / SMB & NetBIOS /NetBeui /CIFS

    NT's domains are an extension of (IBM/Microsoft) Lan Manager and are not hierarchical, but domain based - i.e. more suitable for separate LANs.

    • Passwords are not transmitted over the network in clear form, unless the client asks for it (part of the SMB protocol). The latest NT4 & WIn95 patches (autumn 1997) mandate the use of encryption by default. The current version of Samba also supports encryption and more interestingly "pass through" authentication.
    • Several weakness were published in early 1997 and are partially fixed in NT4.0 SP3 and individual patches. Win95 also has several patches.
    • Microsoft will probably introduce hierarchical domains with NT5 (expected mid 1998).
    • See also ftp://ds.internic.net-internet-drafts/draft-heizer-cifs-v1-spec.txt .
    • For a technical explanation of the security problems involved with the TCP/IP NetBIOS file-sharing protocols (now fashionably called CIFS - Common Internet File System) see the paper: http://avian.org/avian/papers/cifs.txt .

    7.3.10 Others

    • Other hierarchical enterprise naming systems exist, such as Banyan Streetalk III and Novell's Netware Directory service. => These products are not discussed here.
    • Strong proprietary authentication products used for Firewalls and dial-in servers are not discussed here. See the chapter "Firewalls".
    • STEL: A secure telnet which support S/Key, SecurID and UNIX passwords for authentication and uses 3DES, DES and IDEA for encryption. See also ftp://ftp.dsi.unimi.it/pub/security/cert-it/stel.tar.gz.
    • OPIE, S/key, SecurID are discussed in the Firewalls chapter.
    • FNS (Federated Naming Services ): X/Open FNS suggests a standardised API (XFN) to bring together the various authentication systems. Applications would only have to interface to this one API. The Federated services API would then decide what authentication system had to be called and how. XFN provides a method for federating multiple naming services under a single, uniform interface for the basic naming operations. The service supports resolution of composite names (that span multiple naming systems) through the naming interface.
      • This could be used (for example) to unify the various Kerberos dialects, RSA, NIS+ and perhaps even Lan Manager or Novell. It will be interesting to see what this initiative brings about.
      • XFN is actively supported by SunSoft, IBM, HP, DEC, Siemens and OSF.
      • FNS is included as a standard naming service in Sun's Solaris 2.5 and consists of a set of enterprise-level name services with specific policies and conventions for naming organisation, users, hosts, sites and services as well as support for global name services such as NIS+, DNS and X.500.
    • RSA Authentication services : The RSA algorithm is used by many products such as PGP and SSH, but also by products from RSA Inc. itself.
    • MISSI (Multilevel Information Systems Security Initiative) : The NSA are sponsoring MISSI in an effort to bring formerly classified authentication technology to the public. MISSI should provide user and message authentication and be cheap and portable. MISSI is being currently developed by several vendors (LJL, SecureWare, MykotronX, Spryrus).
      • Public & private key cryptography is combined, with a key distribution centre and minimal computational overhead. A tamperproof PCMCIA card has been developed, called Fortezza which generates keys.
      • Weaknesses include a dependency on the PC operating systems (DOS/Windows) and complicated certificate structure for rekeying cards.

    7.4 Access Control Lists (ACLs)

    An ACL defines who (or what) can access ( e.g. use, read, write, execute, delete or create) an object. Access Control Lists (ACL) are the primary mechanism used to ensure data confidentiality and integrity. A system with discretionary access control can discern between users and manages an ACL for each object. If the ACL can be modified by a user (or data owner), it is considered to be discretionary access control. If the ACL must be specified by the system and cannot be changed by the user, mandatory access control is being used. There is no standardised ACLs for access to OS services and applications in UNIX.

    • The AIX (optionally), DCE and Windows NT use ACLs to govern access to most objects.
    • Solaris 2.5 and later provides ACLs for filesystems (UFS, NFS).
    • Normal UNIX also uses ACLs (sort of), but by a different name. For example: protecting files (/etc/groups), protecting sharing of filesystems (/etc/netgroups, /etc/exports), mounting of filesystems (/etc/fstab), remote access (.rhosts, /etc/hosts.allow), X Windows (xauth, xhost), NIS networks (/etc/securenets), Printers (/etc/hosts.lpd).

    7.5 Mechanisms for implementing Rules & Policies

    To secure a particular environment, mechanisms are required which allow the rules and policies to be implemented. Implementing rules and policies network wide on UNIX machines is not easy and often requires development of scripts. Another possibility is the use of a tool such as Tivoli, which is designed to implement rules and policies in a networked heterogeneous environment.

    NT allows setting of some, but not all rights per user. It takes a very different approach to UNIX in this area. (See the chapter "NT"). Implement rules as policies across a network of servers is not supported by standard utilities either.

    7.6 Availability Mechanisms

    7.6.1 Backup & Restore

    Things to watch out for:

    • If possible use heterogeneous products which work on all of your servers.
    • On-line indices allow quick retrieval. Backups to disk allow quick restoring.
    • Some products allow users to backup and restores their own files without administrator intervention. Jukeboxes (also called tape stackers) reduce the physical work of changing cassettes and can make restore time quicker (more cassettes are available). Some systems automatically label tapes.
    • Hardware and software compression can reduce backup times, reduce network load and reduce the number of cassettes needed.
    • Network backups load the network significantly, it may not be possible, for example to backup 100 4GB file servers each night over the network. Planning is important.

    7.6.2 Environment

    The computing environment can be protected with Air Conditioning, locked server rooms and UPS (220V protection).

    7.6.3 Redundancy

    Redundancy increases availability and may be implemented in hardware (RAID), disk drivers or OS (RAID) or at the application/service level (e.g. Replication, transaction monitors, backup domain controllers).

    7.6.3.1 Application/service redundancy

    This is often the cheapest and easiest to implement, where available. The principle problem is that few applications support this type of redundancy. Clients connecting to these servers automatically look for a backup or duplicate server if the primary is not available.

    • Naming servers (NIS+, DNS, NIS, WINS, Lan Manager...) often have this capability in-built and it `s use is highly recommended. RAID / mirroring is not necessary for these servers, unless the cost of RAID is cheaper.
    • Filesystem servers can increase availability (cheaply) by replicating files (e.g. user home directories) to another system or to another local disk regularly. If a major crash of the primary file server occurs, users can mount their files from the second system, but changes made since the last replication/ synchronisation will be lost.
      => Typical products: Rdist (UNIX), File replicator (NT).
      => To reduce down time, the above method can be used to keep a synchronised copy of the system disk available on important servers, without adding RAID.

    7.6.3.2 RAID / Mirroring

    The classical method of increasing system availability is by duplicating one of the weakest part in a computer: the disk. RAID (Redundant Array of Inexpensive Disks) is a de-facto standard for defining how standard disks can be used to increase redundancy. The top RAID systems duplicate disks, disk controllers, power supplies and communication channels. The simplest RAID systems are software-only disk drivers which group together disparate disks into a redundant set.
    There are 5 RAID levels:

    • RAID 1: This is basically mirroring.
    • RAID 1+: This is RAID 1 with the addition of parity checking.
    • RAID 2:
    • RAID 3:
    • RAID 4:
    • RAID 5: Striping
    • RAID 5+: Striping with parity (most commonly used RAID level).

    Things to watch for in RAID systems:

    • A black box which is just attached to the scsi port is easier to manage and easier to fix/repair that inbuilt disks & controllers.
    • For high availability systems, never buy the latest & hottest. Buy a RAID proven to work for/by others over a period of 6 months/1 year!
    • Use a RAID which allows standard disks to be used.
    • RAIDs rarely work they way you expect with large databases. Run a trail before buying.
    • Use the same RAID for all your servers if possible (heterogeneous).
    • Special device drivers and kernel patches needed for RAID increase difficulty of maintenance and probably downtime.
    • Software only RAID, if used, should be small, easy to install/reinstall and have a very good user interface.
    • There are only two really interesting RAID levels: RAID5 with parity and mirroring.
    • TBD

    7.6.3.3 System Redundancy

    If applications do not provide built in redundancy, special software (and perhaps hardware) can be installed on two systems to provide Hot Standby functionality. The principle is as follows: Both systems can access shared (high availability, dual ported) disks and have duplicate network connections. The backup machine monitors the primary constantly and if it notices that the primary is no longer functioning, it takes control of the shared disks, reconfigures it self to have the same network address as the primary and starts up the applications that were running on the master. Of course this with only work with certain applications e.g. if the primary crashes and it's principal application thrashes it's configuration or data files in doing so, the backup server will not be able to start the application.

    A example of this is IBM's HACMP product, or Sun's HA cluster.

    7.6.3.4 Full Hardware redundancy

    Specialised computer systems offer compete redundancy in one system i.e. CPU, memory, disks etc.. are fully duplicated. A single point of failure should not exist. These systems often require specially adapted Operating Systems, cost a fortune and are rarely compatible with mainstream systems. Rarely used in the commercial arena, they are most reserved for military or special financial use.

    An example is the Stratos line of systems.

Share this article

Receive all the latest articles by email!

Get all articles delivered directly to your mailbox as and when they are released on WindowSecurity.com! Choose between receiving instant updates with the Real-Time Article Update, or a monthly summary with the Monthly Article Update.



Receive all the latest articles by email!

Receive Real-Time & Monthly WindowSecurity.com article updates in your mailbox. Enter your email below!
Click for Real-Time sample & Monthly sample

Become a WindowSecurity.com member!

Discuss your security issues with thousands of other network security experts. Click here to join!

Community Area

Log in | Register

Solution Center

Readers' Choice

Which is your preferred VPN solution?