Synopsis:

Cryptography: Foundation of good security principle

This topic describes network security principles that you can use to protect data in your network.

Cryptographic security solutions can be applied to a portion of the data path or end to end, whichever is appropriate for your security policy. Generally, the greatest degree of security is provided when cryptographic methods are used end to end. However, if only portions of the data path are considered untrusted by an enterprise (such as the Internet) it may be adequate to protect only the untrusted portion with cryptography. There are many other security protocols that can be configured to protect portions of the data path or the entire data path.

The foundation of good security methods begins with cryptography. Cryptography keeps your data and communications secure using techniques such as encryption, authentication, and data integrity. Encryption services protect sensitive data from being read by other than the intended receiver. Cryptographic authentication and data integrity services allow communicating hosts to detect if data is altered in transit. Public key cryptography can identify and authenticate hosts or users. Public key cryptography can also be used in the secure creation of symmetric session keys for both security endpoints. After a secure session is created, successful data authentication and decryption occur only if both hosts have the correct session keys.

The National Institute of Standards and Technologies (NIST) publishes Federal Information Processing Standards publication 140 (FIPS 140). This publication specifies security requirements for cryptographic modules for both hardware and software components of computer systems. FIPS 140 places some restrictions on the use of cryptographic algorithms and modules. Some examples of the restrictions are:

Cryptographic algorithms and keys must be contained within a cryptographic module and accessed through a well defined cryptographic boundary.
Use of weaker cryptographic algorithms (for example, DES and MD5) is not allowed.
Use of weaker asymmetric key lengths (for example, RSA digital signature operations using key lengths less than 1024 bits) is not allowed.
Use of Diffie-Hellman groups with weaker key lengths (key lengths less than 2048 bits) is not allowed. This restriction applies to groups 1, 2, and 5.

See the National Institute of Standards and Technology (NIST) website at http://csrc.nist.gov/publications/PubsFIPS.html for the most recent FIPS 140 publication, and other related publications.

The Internet Key Exchange daemon (IKED), the network security services daemon (NSSD), and the TCP/IP stack components perform a wide variety of cryptographic operations for IP Security. The IKED and the NSSD manage cryptographic keys and digital signatures and perform hashes for authentication. The IKED and the TCP/IP stacks perform encryption and decryption of messages that flow over the IPSec tunnels. Architectural enhancements to the IKE protocols periodically introduce new cryptographic algorithms for performing hashes and encryption.

In FIPS 140 mode, the IKED, the NSSD, and the TCP/IP stacks enforce the following restrictions on the cryptographic algorithms that can be used for IP security:

You cannot use the DES encryption algorithm.
You cannot use the HMAC-MD5, HMAC-MD5-96, AES128-XCBC, and AES128-XCBC-96 algorithms for authentication or pseudo-random function.
You cannot use Diffie-Hellman groups 1, 2, and 5.
You cannot use certificates for RSA signature authentication that have key lengths less than 1024 bits.
You cannot use pre-shared keys whose length is less than half the key size of the chosen HowToAuthMsgs (IKEv1) or PseudoRandomFunction (IKEv2) algorithm.

In making a security protocol selection, an important consideration is the application workload to be protected. In order to illustrate this concept, it is helpful to understand where various protocols are implemented from a protocol layering perspective.

Figure 1. Security protocols from a protocol layering perspective

The network layer is the lowest layer in the protocol stack where end to end security over multiple hops can be applied. Network layer security protocols provide blanket protection for upper-layer application data without requiring modification to the application. IPSec is implemented at the network layer and provides authentication, integrity, and data privacy between any two IP entities. IPSec can protect a segment of the data path (e.g., between two routers), or it can secure the data path end to end. Because IPSec is applied at the IP layer, it is a connectionless security protocol and is applied on a per packet basis.

IDS:

It is becoming increasingly important to not just protect systems from attacks but to detect patterns of usage that might indicate impending attacks. Many attacks follow a sequence of information gathering, unauthorized access to resources (information, applications, storage), and denial of service. It can be difficult, or at times, impossible to determine the originator of denial of service attacks. Correlating information gathering activities with access violation might help identify an intruder before they succeed.

Intrusion detection services (IDS) provides the following support:

Scan detection and reporting
Attack detection, reporting, and prevention
Traffic regulation for TCP connections and UDP receive queues

You can use IDS policies to specify event conditions and the actions to take for particular events. All IDS policies support logging events to a specified message priority level in syslog, on the system console, or both. Most IDS policies support the following functions:

Discarding packets when a specified limit is reached
Writing statistical records to the INFO message level of syslogd at a specified time interval, and the option to write these records only when exceptional events have occurred
Tracing all or part of the triggering packet to an IDS-specific CTRACE facility, SYSTCPIS

IDS assigns a correlator value to each event. All messages written to the system console and syslogd use this correlator, and records written to the IDS trace use this correlator. A single detected event can involve multiple packets; the correlator value identifies which messages and packets are related to each other. Each IDS policy has additional attributes that you can specify, either in conditions or in the action.

About to update more information

Page updated

Google Sites

Report abuse

Network Security

Synopsis:

Cryptography: Foundation of good security principle

About to update more information