Internet-related protocols and mechanisms
A request for comment is an official Internet document, managed by the Internet Engineering Task Force (IETF) and serves as a means of disseminating information for comment and consultation about the workings of the Internet. RFCs describe open standards for the benefit of those who may want or need to use those standards for communication. They're produced by volunteers who participate in different working groups and they're published in various locations, particularly on the IETF site. Details on TLS (qv, below) are in the form of an RFC.
The IETF's IP Security Protocol working group is currently defining security additions to IP, the specifications providing for authentication, integrity, and privacy services at the IP datagram layer. It's described in several RFCs and although specified with IP v.6.0 in mind, can be used with IP v. 4.0 (the current standard, using four-section dotted addresses, as in 192.168.1.3). It is intended to serve as a basis for providing security to Internet communications such as for VPNs, encapsulated tunnels, and so on. A number of vendors and software organizations are developing or offering products incorporating IPSec. SSH Communications Security of Finland, for example, has a product named IPSec Express which is designed to facilitate the development of electronic commerce applications that comply with the IPSec standard, while the NetBSD Foundation has merged IPSec code into NetBSD distributions since June 1999.
Although IPSec has become the de facto standard for Internet security implementations, it's attracted criticism from, among other, Niels Ferguson and Bruce Schneier, the latter being the author of the highly-regarded Blowfish cipher. Ferguson and Schneier argue that IPSec has become unduly complex and tends to be unmanageable. The problem here, they say, is that accretions are made not so much to enhance the product in desirable ways, but to meet the wishes and expectations of the wide range of interests represented. They contrast this approach unfavorably with the approach taken by NIST to select a new security algorithm to replace DES, described here in the paper on symmetric cryptography (part 2).
They conclude that IPSec is far better than any previous security protocol but claim that the complexity inherent in its design has led to a large number of ambiguities, contradictions, inefficiencies, and weaknesses, and have resulted in a set of specifications that are extremely difficult to understand, with the result that they doubt whether it could ever result in a truly secure operational system. They make a number of specific recommendations but admit that the poor quality of the documentation and the unduly complex nature of the protocol means that they have not fully understood the system, a pretty damning indictment given their experience and authority. As they point out, there's no prize for getting security 90% right. Bluntly, they say that they strongly discourage the use of IPSec in its present form, but they even more strongly discourage any current alternatives. And so they recommend IPSec when the alternative is an insecure network.
Secure HTTP (S-HTTP) is a security extension to HTTP, operating at the application layer. It's intended to provide privacy and authentication while supporting non-repudiation and allowing for a range of cryptographic algorithms and key management mechanisms to be used. RSA is typically used for the initial key negotiation, although keys may also be obtained from a Kerberos server agreed upon in advance of a session or generated in one session for use in the next.
Secure Sockets Layer (SSL) is a handshake protocol developed by Netscape Communications to provide security and privacy to Internet sessions. It supports both server and client authentication and is designed to negotiate encryption keys as well as to authenticate the server before any data is exchanged. It uses encryption, authentication, and MACs to maintain the integrity of the transmission channel.
Although SSL is optimized for use with HTTP, it can also be used with FTP or other relevant protocols. It operates at the transport level and is application independent, so that relevant protocols like FTP or HTTP can be layered on top. An initial handshake is used to authenticate the server. During this process the server submits a certificate to the client and specifies its preference for the cipher to be used. The client then generates a secret key to be used during the upcoming session and submits it to the server, appropriately encrypted using the server's public key. The server decrypts the message using its private key, recovers the secret key, and authenticates itself to the client by sending it a message encrypted with the secret key. Further exchanges takes place with data encrypted using this agreed upon secret key.
An optional second phase may be used for added security. Here, the server sends a challenge to the client to which the client responds by returning its own digital signature on the challenge, together with its public-key certificate.
The challenge phases are typically carried out using RSA with MD5 being used for message digests. A variety of symmetric ciphers can be used, including DES, triple-DES, IDEA, RC2 and RC4. The public-key certificates conform to the X.509 standard. SSL is now at version 3.0.
The early history of SSL gives a warning about the importance of peer review for cryptographic products, specifically, an incident was written up in the January 1996 issue of Dr Dobb's Journal by Ian Goldberg and David Wagner, two Ph.D. students at the University of California, who explain how they broke the encryption system then used.
As Netscape wouldn't, at that time, release any information on the structure of SSL or the cryptography and other methods used, Goldberg and Wagner reverse-engineered the relevant algorithms. They discovered that the seed used to generate the pseudo-random number that, in turn, generated the secret key depended on the time of day, the process ID, and the parent process ID. The two IDs are relatively easy to obtain, at least by any user with an account on a UNIX machine running the browser. Packets collected by a sniffer can be timed to within a second. That information reduced the number of possible seeds to a million, and cracking those was easily accomplished in less than half a minute using an HP 712/80.
It's very difficult to generate a true random number using a computer, so programs requiring a random number will instead generate a seed in as random a manner as possible and then generate a pseudo-random number from this using a pseudo-random number generator (PRNG). However, the same seed with a particular PRNG will give the same number and that number, used appropriately in a cryptosystem algorithm, will give the same key. This isn't in itself a vulnerability, but it's extremely important that the original seed be made as random as possible. Applications will often draw on events that are extremely hard to predict or to replicate, such as random electronic noise within chips, noisy diodes, certain disc drive movements, user keystrokes or mouse movements, and so on. In this particular case, the use of the three elements to create the seed seems reasonable at first glance, and clearly did so to the original designers, but further analysis revealed the limitations. Bringing in others to catch flaws of this sort is precisely what makes peer review so valuable, something that is essential if a system is ultimately to be considered sound.
Transport Layer Security (TLS)
The Transport Layer Security (TLS) protocol is based on and similar to SSL and is a draft standard of the IETF. Its primary goal is to provide privacy and data integrity between two communicating applications. It consists of two layers. The lower level is termed the TLS Record protocol and is layered on top of some reliable transport protocol, such as TCP. This layer has two basic properties, specifically that the connection is private and that it is reliable. It is used for encapsulation of various higher level protocols but can also be used without encryption. Where encryption is used, as would be normal, the secret keys for this are generated uniquely for each connection and are based on a secret key negotiated by another protocol, such as the higher level TLS Handshake protocol.
The TLS Handshake protocol provides connection security that has three basic properties, namely that the peer's identity can be authenticated using asymmetric cryptography, that the negotiation of a shared secret is secure, and that the negotiation is reliable.
As with SSL, TLS is application protocol independent and uses a similar range of ciphers. The TLS standard, however, leaves the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates to the judgment of the designers and implementers of the protocols that run on top.
The goals of the TLS protocol are cryptographic security, interoperability, and extensibility, in that order of priority. The last of these goals means that TLS provides a framework into which new and improved asymmetric and other encryption methods can be introduced as they become available.
Wireless Transport Layer Security (WTLS)
The security layer protocol in the Wireless Application Protocol (WAP) architecture is called the Wireless Transport Layer Security (WTLS). It operates above the transport protocol layer, is modular, and depends on the required security level of the given application whether it's used or not. WTLS provides the upper-level layer of WAP with a secure transport service interface that preserves the transport service interface below it. In addition, it provides an interface for managing secure connections.
WTLS is very similar to TLS but is optimized for low-bandwidth bearer networks with relatively long latency. However, it adds new features such as datagram support, optimized handshake and key refreshing. As with TLS, its primary goal is to provide privacy, data integrity, and authentication between two communicating applications.
Secure Electronic Transmission (SET)
The Secure Electronic Transmission (SET) protocol has been developed by the VISA and MasterCard banking consortia as a method for secure bank card transactions over open networks. It supports DES and tripleDES for bulk data encryption and RSA for the public-key encryption of the secret keys and the bank card numbers.
Although SET is considered extremely secure, this very security leads to its being relatively slow. Further, users need properly-issued digital certificates, so it can't be used in a simple ad hoc way as is the case with SSL or TLS. For these reasons, and for the added reason that many banks shift the risk and consequences of bank card security breaches on to their merchant customers, the take-up of SET has been much less than was originally thought might be the case. However, there are indications that this is changing.
Secure Wide Area Network (S/WAN)
The Secure Wide Area Network initiative was driven by RSA Data Security and intended to promote the widespread deployment of Internet-based Virtual Private Networks (VPNs). S/WAN supported encryption at the IP level and so provided a more fundamental and lower-level security than could be offered by the likes of SSL or TLS. A VPN is a mechanism designed to allow users to maintain secure tunnels between them while using the public Internet. For example, remote offices can be connected cheaply without incurring the cost or point-to-point inconvenience of using dedicated leased lines. Messages passing through the tunnels are encrypted, so they should be safe from useful interception by third parties. In reality, and partly on account of the development of different standards designed to bring competitive benefit to one company or another, there's a major gap between theory and practice, particularly so far as interoperability is concerned. The S/WAN initiative was an attempt to bring some order to the resultant chaos.
Although the original S/WAN initiative is no longer active, there are very similar initiatives in the Linux FreeS/WAN and the Virtual Private Network Consortium initiatives. FreeS/WAN is a Red Hat Linux implementation of IPSec (qv) and effectively provides a roll-your-own VPN implementation for Linux under the GNU GPL.
Secure Shell (SSH) is a protocol that's currently being standardized by the IETF's SECSH working group. It allows secure remote access over a network. A variety of methods can be used to authenticate the client and server and to establish an encrypted communication channel between SSH-enabled systems. This connection can then be used to, for example, establish a VPN or create a secure remote login on a server to replace the likes of telnet, rlogin, or rsh.
Why bother encrypting e-mail? In many case it may not make any difference, but users should understand that sending a plain text e-mail is equivalent to sending a postcard that anyone can read. E-mail travels an indeterminate and fragmented route and there are numerous points on the way where it can be viewed without difficulty. Part of the time it remains in semi-public areas on a network mail server or in the storage of an ISP. E-mails can also be wrongly routed or erroneously sent out in bulk: A recent admission in the periodical Network News was from a network manager who mistakenly sent to every printer in the building an image of his face with the legend "I am very munchable," which was intended as a private T-shirt message for his wife. That wasn't an e-mail, certainly, but it just as easily could have been and the embarrassment would have been no different. A number of products offer secure e-mail either as with Pretty Good Privacy (PGP, discussed in detail in a later feature) in the form of a complementary product or by using a protocol such as Secure MIME (S/MIME) to add digital signing and encryption facilities to mail messages generated using an appropriate client such as Netscape. MIME (Multipurpose Internet Mail Extensions) is an Internet mail standard that allows enhanced text, audio, graphics, video, and the like to be included in e-mail messages in standardized format. MIME does not, however, provide any security elements -- S/MIME adds those. S/MIME has been endorsed by a number of networking and messaging ISVs including Netscape, Qualcomm, Microsoft, Lotus, Novell, and others. Information is available from the IETF.
Introducing encrypted e-mail to a larger organization introduces a new set of problems, however. Anti-virus products may not necessarily identify dangerous attachments that are encrypted. Further, scanners and firewalls, whose job it may be to ensure that confidential or illegal information is prevented from traveling into or out of an organization or department, might similarly have problems.
One solution might be to encrypt and decrypt at the external gateway, although this leaves the e-mail unencrypted as it travels through the company network, which might not be suitable. In any case, a number of e-mail encryption packages work at the desktop level as an adjunct to whatever e-mail client is being used. However, scanning at the desktop, by decentralizing certain content security policies, makes matters much more complex and difficult to enforce. Another option -- generally clumsy and resource-intensive, but appropriate in some circumstances -- might be to allow encrypted e-mail to be used only when a copy is simultaneously sent to a centralized mailbox for decryption and examination; difficulties here include the doubling of traffic, delays in message delivery, a need to keep users informed of the practice, and possible inconvenience experienced by users. The Giga Group, which raised the issue recently in a discussion, recommend that the most satisfactory solution is to have the e-mail encrypted and mailed to a central relay; at this point, it's decrypted, examined for compliance with security policies and for viruses, encrypted for the intended recipient, and duly re-mailed. As ever, the best method depends on balancing the risks with the costs and inconveniences of proposed solutions.
Murdoch Mactaggart is a freelance
writer and business consultant who writes on software development, the Internet
and on business and management issues around these areas. Whether readers can
make accurate sense of what he writes is a moot point but, flexible though he
tries to be, he generally sticks to English rather than introducing languages of
his own making. Contact him at IBMDev@TextBiz.com.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
Spring, JRuby, and Ajax development is easier with WebSphere Application Server - a smart Java 5 and J2EE Web services-based application server.
- Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and other best-of-breed open source software such as OpenEJB, Apache Axis, and Apache Derby.
- Article: The article leverage the Spring Framework and the WebSphere Application Server to improve your J2EE project productivity.
- Tutorial: See how the free WebSphere Application Server and XML can improve the efficiency of your JRuby on Rails and Ajax development.
- Buy: WebSphere Application Server - Express
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
