NEHRU ARTS AND SCIENCE COLLEGE
T.M.PALAYAM, COIMBATORE
NAME OF THE PAPER: NETWORK SECURITY AND CRYPTOGRAPHY
STAFF NAME: A.SENTHIL KUMAR
ACADEMIC YEAR : 2011 - 2012
UNIT-IV:
Authentication application – pretty good privacy – S/MIME – ip security – web security
considerations –secure socket layer transport layer security –secure electronic transaction.
Authentication application
Authentication is the act of establishing identity via the presentation of information that allows
the verifier to know the presenter is who or what it claims. This identity could be any number of
things, including:




People
Systems
Applications
Messages
Why would one want to verify an identity in the first place? Hopefully, most people reading this
recognize that as sarcastic humor. If not, here are a few common reasons:




To control access to a system or application
To bind some sensitive data to an individual, such as for encryption
To establish trust between multiple parties to form some interaction with them
To assure that a piece of information is genuine
Within an application, one or all of these aspects may apply. This article presents different types
of authentication and ways of adding it to your applications.
Types of Authentication
There are many different types of authentication that can be used in an application. The selection
of the most appropriate type of authentication will depend on the needs of the application; use
this guide to determine which makes the most sense for your application.



Basic, single-factor authentication
Multi-factor authentication
Cryptographic authentication
These authentication types apply to all classes of entity that require authentication: systems,
users, messages, and applications.
Basic Authentication
Basic authentication is a commonly used term that most people probably understand already. It
refers to password-based authentication. A password can be any information that is used to
verify the identity of a presenter. Common examples that fall into this category are:




The common password
Host or system names
Application names
Numerical IDs
Authentication entails the validation of a single credential pair—the presenter's identity reference
and their password. The authentication process typically takes the password and compares it to
that which is stored in the authentication database. This comparison is often done as a plain text
comparison where the provided password exactly matches that expected password, or with some
permutation function where the password first undergoes an alteration such as hashing or
encryption and the resulting data is then compared. The storage of the password is the next piece
that is also often in plaintext or some permutation based on the aforementioned cryptographic
function. Basic authentication has the following benefits. It is:



Easy to manage within an application
Easy to deploy across applications
Easy for end users to use
There are some important caveats when using basic authentication of which every developer
should be aware:





Passwords are commonly weakly specified
Identities can be spoofed and impersonated
Passwords can be susceptible to theft
Requires considerable effort to provide strong security
Can be difficult to scale across distributed and large environments
Pretty Good Privacy
Pretty Good Privacy (PGP) is a data encryption and decryption computer program that provides
cryptographic privacy and authentication for data communication. PGP is often used for signing,
encrypting and decrypting e-mails to increase the security of e-mail communications. It was
created by Philip Zimmermann in 1991.
PGP and similar products follow the OpenPGP standard (RFC 4880) for encrypting and
decrypting data.
PGP encryption uses a serial combination of hashing, data compression, symmetric-key
cryptography, and, finally, public-key cryptography; each step uses one of several supported
algorithms. Each public key is bound to a user name and/or an e-mail address. The first version
of this system was generally known as a web of trust to contrast with the X.509 system which
uses a hierarchical approach based on certificate authority and which was added to PGP
implementations later. Current versions of PGP encryption include both options through an
automated key management server.
Compatibility
As PGP evolves, PGP systems that support newer features and algorithms are able to create
encrypted messages that older PGP systems cannot decrypt, even with a valid private key. Thus,
it is essential that partners in PGP communication understand each other's capabilities or at least
agree on PGP settings.
Confidentiality
PGP can be used to send messages confidentially. For this, PGP combines symmetric-key
encryption and public-key encryption. The message is encrypted using a symmetric encryption
algorithm, which requires a symmetric key. Each symmetric key is used only once and is also
called a session key. The session key is protected by encrypting it with the receiver's public key
thus ensuring that only the receiver can decrypt the session key. The encrypted message along
with the encrypted session key is sent to the recipient.
Digital signatures
PGP supports message authentication and integrity checking. The latter is used to detect whether
a message has been altered since it was completed (the message integrity property), and the
former to determine whether it was actually sent by the person/entity claimed to be the sender (a
digital signature). In PGP, these are used by default in conjunction with encryption, but can be
applied to the plaintext as well. The sender uses PGP to create a digital signature for the message
with either the RSA or DSA signature algorithms. To do so, PGP computes a hash (also called a
message digest) from the plaintext, and then creates the digital signature from that hash using the
sender's private key.
S/MIME
S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard for public key
encryption and signing of MIME data. S/MIME is on an IETF standards track and defined in a
number of documents, most importantly RFCs. S/MIME was originally developed by RSA Data
Security Inc. The original specification used the recently developed IETF MIME specification
with the de facto industry standard PKCS#7 secure message format. Change control to S/MIME
has since been vested in the IETF and the specification is now layered on Cryptographic
Message Syntax, an IETF specification that is identical in most respects with PKCS #7. S/MIME
functionality is built into the majority of modern e-mail software and interoperates between
them.
IPsec
Internet Protocol Security (IPsec) is a protocol suite for securing Internet Protocol (IP)
communications by authenticating and encrypting each IP packet of a communication session.
IPsec also includes protocols for establishing mutual authentication between agents at the
beginning of the session and negotiation of cryptographic keys to be used during the session.
IPsec is an end-to-end security scheme operating in the Internet Layer of the Internet Protocol
Suite. It can be used in protecting data flows between a pair of hosts (host-to-host), between a
pair of security gateways (network-to-network), or between a security gateway and a host
(network-to-host).[1]
Some other Internet security systems in widespread use, such as Secure Sockets Layer (SSL),
Transport Layer Security (TLS) and Secure Shell (SSH), operate in the upper layers of the
TCP/IP model. Hence, IPsec protects any application traffic across an IP network. Applications
do not need to be specifically designed to use IPsec. The use of TLS/SSL, on the other hand,
must be designed into an application to protect the application protocols.
IPsec is a successor of the ISO standard Network Layer Security Protocol (NLSP). NLSP was
based on the SP3 protocol that was published by NIST, but designed by the Secure Data
Network System project of the National Security Agency (NSA).
IPsec is officially specified by the Internet Engineering Task Force (IETF) in a series of Request
for Comment documents addressing various components and extensions. It specifies the spelling
of the protocol name to be IPsec.
o
Security architecture
The IPsec suite is an open standard. IPsec uses the following protocols to perform various
functions:[2][3]

Internet Key Exchange (IKE and IKEv2) or Kerberized Internet Negotiation of Keys
(KINK) sets up a security association (SA) by handling the negotiation of protocols and
algorithms and by generating the encryption and authentication keys to be used by
IPsec.[4][5][6]

Authentication Header (AH) to provide connectionless integrity and data origin
authentication for IP datagrams and to provide protection against replay attacks.[7][8]

Encapsulating Security Payload (ESP) to provide confidentiality, data origin
authentication, connectionless integrity, an anti-replay service (a form of partial sequence
integrity), and limited traffic flow confidentiality.[1]
Authentication Header
Authentication Header (AH) is a member of the IPsec protocol suite. AH guarantees
connectionless integrity and data origin authentication of IP packets. Further, it can optionally
protect against replay attacks by using the sliding window technique and discarding old packets
(see below).


In IPv4, the AH protects the IP payload and all header fields of an IP datagram except for
mutable fields (i.e. those that might be altered in transit). Mutable (and therefore
unauthenticated) IP header fields are DSCP/TOS, ECN, Flags, Fragment Offset, TTL and
Header Checksum.[8]
In IPv6, the AH protects the AH itself, the Destination Options extension header after the
AH, and the IP payload. It also protects the fixed IPv6 header and all extension headers
before the AH, except for the mutable fields: DSCP, ECN, Flow Label, and Hop Limit.[8]
AH operates directly on top of IP, using IP protocol number 51.[9]
The following AH packet diagram shows how an AH packet is constructed and interpreted:[7][8]
Authentication Header format
Offset Octet1
0
s
6
Octet1
1
2
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Bit10
0123456789
0
0
Next Header Payload Len
4
32
Security Parameters Index (SPI)
8
64
Sequence Number
C
96
…
…
6
3
Reserved
Integrity Check Value (ICV)
…
Next Header (8 bits)
Type of the next header, indicating what upper-layer protocol was protected. The value is
taken from the list of IP protocol numbers.
Payload Len (8 bits)
The length of this Authentication Header in 4-octet units, minus 2 (a value of 0 means 8
octets, 1 means 12 octets, etcetera). Although the size is measured in 4-octet units, the
length of this header needs to be a multiple of 8 octets if carried in an IPv6 packet. This
restriction does not apply to an Authentication Header carried in an IPv4 packet.
Reserved (16 bits)
Reserved for future use (all zeroes until then).
Security Parameters Index (32 bits)
Arbitrary value which is used (together with the source IP address) to identify the
security association of the sending party.
Sequence Number (32 bits)
A monotonically increasing sequence number (incremented by 1 for every packet sent) to
prevent replay attacks. When replay detection is enabled, sequence numbers are never
reused because a new security association must be renegotiated before an attempt to
increment the sequence number beyond its maximum value.[8]
Integrity Check Value (multiple of 32 bits)
Variable length check value. It may contain padding to align the field to an 8-octet
boundary for IPv6, or a 4-octet boundary for IPv4.
Encapsulating Security Payload
Encapsulating Security Payload (ESP) is a member of the IPsec protocol suite. In IPsec it
provides origin authenticity, integrity, and confidentiality protection of packets. ESP also
supports encryption-only and authentication-only configurations, but using encryption without
authentication is strongly discouraged because it is insecure.[10][11][12] Unlike Authentication
Header (AH), ESP does not protect the IP packet header. However, in Tunnel Mode, where the
entire original IP packet is encapsulated with a new packet header added, ESP protection is
afforded to the whole inner IP packet (including the inner header) while the outer header remains
unprotected. ESP operates directly on top of IP, using IP protocol number 50.[9]
The following ESP packet diagram shows how an ESP packet is constructed and
interpreted:[1][13]
Encapsulating Security Payload format
Offset Octet1 0
1
2
3
s
Octet1
6
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Bit10
0123456789
0
0
Security Parameters Index (SPI)
4
32
Sequence Number
C
96
6
Payload data
…
…
…
…
…
…
…
…
…
…
…
…
Padding (0-255 octets)
Pad Length
Next Header
Integrity Check Value (ICV)
…
Security Parameters Index (32 bits)
Arbitrary value which is used (together with the source IP address) to identify the
security association of the sending party.
Sequence Number (32 bits)
A monotonically increasing sequence number (incremented by 1 for every packet sent) to
protect against replay attacks. There is a separate counter kept for every security
association.
Payload data (variable)
The protected contents of the original IP packet, including any data used to protect the
contents (e.g. an Initialisation Vector for the cryptographic algorithm). The type of
content that was protected is indicated by the Next Header field.
Padding (0-255 octets)
Padding for encryption, to extend the payload data to a size that fits the encryption's
cypher block size, and to align the next field.
Pad Length (8 bits)
Size of the padding in octets.
Next Header (8 bits)
Type of the next header. The value is taken from the list of IP protocol numbers.
Integrity Check Value (multiple of 32 bits)
Variable length check value. It may contain padding to align the field to an 8-octet
boundary for IPv6, or a 4-octet boundary for IPv4.
Security association
The IP security architecture uses the concept of a security association as the basis for building
security functions into IP. A security association is simply the bundle of algorithms and
parameters (such as keys) that is being used to encrypt and authenticate a particular flow in one
direction. Therefore, in normal bi-directional traffic, the flows are secured by a pair of security
associations. The actual choice of encryption and authentication algorithms (from a defined list)
is left to the IPsec administrators.
In order to decide what protection is to be provided for an outgoing packet, IPsec uses the
Security Parameter Index (SPI), an index to the security association database (SADB), along
with the destination address in a packet header, which together uniquely identify a security
association for that packet. A similar procedure is performed for an incoming packet, where
IPsec gathers decryption and verification keys from the security association database.
For multicast, a security association is provided for the group, and is duplicated across all
authorized receivers of the group. There may be more than one security association for a group,
using different SPIs, thereby allowing multiple levels and sets of security within a group. Indeed,
each sender can have multiple security associations, allowing authentication, since a receiver can
only know that someone knowing the keys sent the data. Note that the relevant standard does not
describe how the association is chosen and duplicated across the group; it is assumed that a
responsible party will have made the choice.
Modes of operation
IPsec can be implemented in a host-to-host transport mode, as well as in a network tunnel mode.
Transport mode
In transport mode, only the payload (the data you transfer) of the IP packet is encrypted and/or
authenticated. The routing is intact, since the IP header is neither modified nor encrypted;
however, when the authentication header is used, the IP addresses cannot be translated, as this
will invalidate the hash value. The transport and application layers are always secured by hash,
so they cannot be modified in any way (for example by translating the port numbers). Transport
mode is used for host-to-host communications.
A means to encapsulate IPsec messages for NAT traversal has been defined by RFC documents
describing the NAT-T mechanism.
Tunnel mode
In tunnel mode, the entire IP packet is encrypted and/or authenticated. It is then encapsulated
into a new IP packet with a new IP header. Tunnel mode is used to create Virtual Private
Networks for network-to-network communications (e.g. between routers to link sites), host-tonetwork communications (e.g. remote user access), and host-to-host communications (e.g.
private chat).
Tunnel mode supports NAT traversal.
Cryptographic algorithms
Cryptographic algorithms defined for use with IPsec include:



HMAC-SHA1 for integrity protection and authenticity.
TripleDES-CBC for confidentiality
AES-CBC for confidentiality.
Refer to RFC 4835 for details.
Software implementations
IPsec support is usually implemented in the kernel with key management and ISAKMP/IKE
negotiation carried out from user-space. Existing IPsec implementations often include both.
There exist a number of implementations of IPsec and ISAKMP/IKE protocols. These include:










NRL[14] IPsec, one of the original sources of IPsec code.[15]
OpenBSD, with its own code derived from a BSD/OS implementation written by John
Ioannidis and Angelos D. Keromytis in 1996.
The KAME stack, that is included in Mac OS X, NetBSD and FreeBSD.
"IPsec" in Cisco IOS Software [16]
"IPsec" in Microsoft Windows, including Windows XP[17][18], Windows 2000[19],
Windows 2003[20], Windows Vista, Windows Server 2008[21], and Windows 7.[22]
o IPsec in Windows Vista and later
Authentec QuickSec toolkits[23]
IPsec in Solaris[24]
IBM AIX operating system
IBM z/OS
IPsec and IKE in HP-UX (HP-UX IPsec)



The Linux IPsec stack written by Alexey Kuznetsov and David S. Miller.
Openswan on Linux using the native Linux IPsec stack, or its own KLIPS stack.
strongSwan on Linux, FreeBSD, Mac OS X, and Android using the native IPsec stack.
Standards status
IPsec was developed in conjunction with IPv6 and is therefore mandatory in all standardscompliant implementations of IPv6,[25] but its implementation is an optional extension to IPv4.
However, because of the slow deployment of IPv6, IPsec is most commonly used to secure IPv4
traffic. IPsec protocols were originally defined in Requests for Comments RFC 1825 and RFC
1829, published in 1995. In 1998, these documents were superseded by RFC 2401 and RFC 2412
with incompatible aspects, although they were conceptually identical. In addition, a mutual
authentication and key exchange protocol Internet Key Exchange (IKE) was defined to create
and manage security associations. In December 2005, new standards were defined in RFC 4301
and RFC 4309 which are largely a superset of the previous editions with a second version of the
Internet Key Exchange standard IKEv2. These third-generation documents standardized the
abbreviation of IPsec to uppercase “IP” and lowercase “sec”. It is unusual to see any product that
offers support for RFCs 1825 and 1829. “ESP” generally refers to RFC 2406, while ESPbis
refers to RFC 4303.
Since mid-2008, an IPsec Maintenance and Extensions working group is active at the IETF.
Security considerations
Web development takes into account many security considerations, such as data entry error
checking through forms, filtering output, and encryption.[2] Malicious practices such as SQL
injection can be executed by users with ill intent yet with only primitive knowledge of web
development as a whole. Not only this, but scripts can be exploited to grant unauthorized access
to malicious users trying to collect information such as email addresses, passwords and protected
content like credit card numbers.
Some of this is dependent on the server environment (most commonly Apache or Microsoft IIS)
on which bcs the scripting language, such as PHP, Ruby, Python, Perl or ASP is running, and
therefore is not necessarily down to the web developer themselves to maintain. However,
stringent testing of web applications before public release is encouraged to prevent such exploits
from occurring.
Keeping a web server safe from intrusion is often called Server Port Hardening. Many
technologies come into play when keeping information on the internet safe bcs when it is
transmitted from one location to another. For instance Secure Socket Layer Encryption (SSL)
Certificates are issued by certificate authorities to help prevent internet fraud. Many developers
often bcs employ different forms of encryption when transmitting and storing sensitive
information. A basic understanding of information technology security concerns is often part of a
web developer's knowledge.
Because new security holes are found in web applications even after testing and launch, security
patch updates are frequent for widely used applications. It is often the job of web developers to
keep applications up to date as security patches are released and new security concerns are
discovered.
Transport Layer Security
Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are
cryptographic protocols that "provide communications security over the Internet"[1]. TLS and
SSL encrypt the segments of network connections above the Transport Layer, using symmetric
cryptography for privacy and a keyed message authentication code for message reliability.
Several versions of the protocols are in widespread use in applications like web browsing,
electronic mail, Internet faxing, instant messaging and voice-over-IP (VoIP).
TLS is an IETF standards track protocol, last updated in RFC 5246, and is based on the earlier
SSL specifications developed by Netscape Corporation.[2]
In applications design, TLS is usually implemented on top of any of the Transport Layer
protocols, encapsulating the application-specific protocols such as HTTP, FTP, SMTP, NNTP,
and XMPP. Historically it has been used primarily with reliable transport protocols such as the
Transmission Control Protocol (TCP). However, it has also been implemented with datagramoriented transport protocols, such as the User Datagram Protocol (UDP) and the Datagram
Congestion Control Protocol (DCCP), usage which has been standardized independently using
the term Datagram Transport Layer Security (DTLS).
A prominent use of TLS is for securing World Wide Web traffic carried by HTTP to form
HTTPS. Notable applications are electronic commerce and asset management. Increasingly, the
Simple Mail Transfer Protocol (SMTP) is also protected by TLS (RFC 3207). These applications
use public key certificates to verify the identity of endpoints.
TLS can also be used to tunnel an entire network stack to create a VPN, as is the case with
OpenVPN. Many vendors now marry TLS's encryption and authentication capabilities with
authorization.[citation needed] There has also been substantial development since the late 1990s in
creating client technology outside of the browser to enable support for client/server applications.
When compared against traditional IPsec VPN technologies, TLS has some inherent advantages
in firewall and NAT traversal that make it easier to administer for large remote-access
populations[citation needed].
TLS is also a standard method to protect Session Initiation Protocol (SIP) application
signaling.[citation needed] TLS can be used to provide authentication and encryption of the SIP
signaling associated with VoIP and other SIP-based applications.
[edit] Security
TLS/SSL have a variety of security measures:






Protection against a downgrade of the protocol to a previous (less secure) version or a
weaker cipher suite.
Numbering subsequent Application records with a sequence number, and using this
sequence number in the message authentication codes (MACs).
Using a message digest enhanced with a key (so only a key-holder can check the MAC).
The HMAC construction used by most TLS ciphersuites is specified in RFC 2104
(SSLv3 used a different hash-based MAC).
The message that ends the handshake ("Finished") sends a hash of all the exchanged
handshake messages seen by both parties.
The pseudorandom function splits the input data in half and processes each one with a
different hashing algorithm (MD5 and SHA-1), then XORs them together to create the
MAC. This provides protection even if one of these algorithms is found to be vulnerable]
TLS only.
SSL v3 improved upon SSL v2 by adding SHA-1 based ciphers, and support for
certificate authentication.
A vulnerability of the renegotiation procedure was discovered in August 2009 that can lead to
plaintext injection attacks against SSLv3 and all current versions of TLS. For example, it allows
an attacker who can hijack an https connection to splice their own requests into the beginning of
the conversation the client has with the web server. The attacker can't actually decrypt the clientserver communication, so it is different from a typical man-in-the-middle attack. A short-term fix
is for web servers to stop allowing renegotiation, which typically will not require other changes
unless client certificate authentication is used. To fix the vulnerability, a renegotiation indication
extension was proposed for TLS. It will require the client and server to include and verify
information about previous handshakes in any renegotiation handshakes.[5] When a user doesn't
pay attention to their browser's indication that the session is secure (typically a padlock icon), the
vulnerability can be turned into a true man-in-the-middle attack[6] This extension has become a
proposed standard and has been assigned the number RFC 5746.
There are some attacks against the implementation rather than the protocol itself:[citation needed]


Most CAs don't explicitly set basicConstraints CA=FALSE for leaf nodes, and a lot of
browsers and other SSL implementations (including IE, Konqueror, OpenSSL, etc.) don't
check the field. This can be exploited for man-in-the-middle attack on all potential SSL
connections.
Some implementations (including older versions of Microsoft Cryptographic API,
Network Security Services, and GnuTLS) stop reading any characters that follow the null
character in the name field of the certificate, which can be exploited to fool the client into
reading the certificate as if it were one that came from the authentic site, e.g.
paypal.com\0.badguy.com would be mistaken as the site of paypal.com rather than
badguy.com.
SSL v2 is flawed in a variety of ways:





Identical cryptographic keys are used for message authentication and encryption.
SSL v2 has a weak MAC construction that uses the MD5 hash function with a secret
prefix, making it vulnerable to length extension attacks.
SSL v2 does not have any protection for the handshake, meaning a man-in-the-middle
downgrade attack can go undetected.
SSL v2 uses the TCP connection close to indicate the end of data. This means that
truncation attacks are possible: the attacker simply forges a TCP FIN, leaving the
recipient unaware of an illegitimate end of data message (SSL v3 fixes this problem by
having an explicit closure alert).
SSL v2 assumes a single service, and a fixed domain certificate, which clashes with the
standard feature of virtual hosting in webservers. This means that most websites are
practically impaired from using SSL. TLS/SNI fixes this but is not deployed in
webservers as yet.
SSL v2 is disabled by default in Internet Explorer 7,[7] Mozilla Firefox 2 and Mozilla Firefox 3,[8]
and Safari. After it sends a TLS ClientHello, if Mozilla Firefox finds that the server is unable to
complete the handshake, it will attempt to fall back to using SSL 3.0 with an SSL 3.0
ClientHello in SSL v2 format to maximize the likelihood of successfully handshaking with older
servers.[9] Support for SSL v2 (and weak 40-bit and 56-bit ciphers) has been removed completely
from Opera as of version 9.5.
Secure Electronic Transaction
Secure Electronic Transaction (SET) was a standard protocol for securing credit card
transactions over insecure networks, specifically, the Internet. SET was not itself a payment
system, but rather a set of security protocols and formats that enable users to employ the existing
credit card payment infrastructure on an open network in a secure fashion. However, it failed to
gain traction. VISA now promotes the 3-D Secure scheme.
SET was developed by SETco, led by VISA and MasterCard (and involving other companies
such as GTE, IBM, Microsoft, Netscape, RSA and VeriSign) starting in 1996. SET was based on
X.509 certificates with several extensions. The first version was finalised in May 1997 and a
pilot test was announced in July 1998.
SET allowed parties to cryptographically identify themselves to each other and exchange
information securely. SET used a blinding algorithm that, in effect, would have let merchants
substitute a certificate for a user's credit-card number. If SET were used, the merchant itself
would never have had to know the credit-card numbers being sent from the buyer, which would
have provided verified good payment but protected customers and credit companies from fraud.
SET was intended to become the de facto standard of payment method on the Internet between
the merchants, the buyers, and the credit-card companies. Despite heavy publicity, it failed to
win market share. Reasons for this include:



Network effect - need to install client software (an e-wallet).
Cost and complexity for merchants to offer support and comparatively low cost and
simplicity of the existing SSL based alternative.
Client-side certificate distribution logistics.