The architecture Encapsulating security payload Authentication header(AH) HTTP authentication: web security Client response WWW-authenticate Back to SSl

1. NETWORK SECURITY
NAME OF THE STAFF : Mrs. M. FLORANCE DYANA
NAME OF THE STUDENT : S.MAREESWARI,
J.GAYATHRI DEVI,
R.KAVITHA.
REGISTER NUMBER : CB17S 250393
CB17S 250370
CB17S 250383
SUBJECT CODE : P8MCA27
CLASS : III BCA-A
BATCH : 2017-2020
YEAR : 2019-2020

3.  Introduction
 The architecture
 Encapsulating security payload
 Authentication header(AH)
 HTTP authentication: web security
 Client response
 WWW-authenticate
 Back to SSl

4. Introduction
 IP Packets have no inherent security. It is relatively easy to forge the addresses of IP
packets, modify the contents of IP packets, replay old packets, and inspect the contents
of IP packets in transit. Therefore, there is no guarantee that IP datagrams received are
 (1) from the claimed sender (the source address in the IP header);
 (2) that they contain the original data that the sender placed in them; or
 (3) that the original data was not inspected by a third party while the packet was being
sent from source to destination. IP Sec is a method of protecting IP datagrams.
 This protection takes the form of data origin authentication, connectionless data
integrity authentication, data content confidentiality, antireplay protection, and limited
traffic flow confidentiality

5. The architecture
 The Architecture Document for IP Sec, RFC2401, defines the base architecture
upon which all implementations are built.
 It defines the security services provided by IP Sec, how and where they can be
used, how packets are constructed and processed, and the interaction of IP Sec
processing with policy.
 The IP Sec protocols—AH and ESP—can be used to protect either an entire IP
payload or the upper-layer protocols of an IP payload. This distinction is
handled by considering two different “modes” of IP Sec transport mode is
used to protect upper-layer protocols; tunnel mode is used to protect entire IP
datagrams. .

6.  ESP is the IP Sec protocol that provides confidentiality, data integrity, and
data source authentication of IP packets, and also provides protection
against replay attacks.
 It does so by inserting a new header—an ESP header—after an IP header
(and any IP options) and before the data to be protected, either an upper-
layer protocol or an entire IP datagram, and appending an ESP trailer.
 ESP is a new IP protocol and an ESP packet is identified by the protocol
field of an IP header. If its value is 50 it’s an ESP packet and immediately
following the IP header is an ESP header.
 Since ESP provides both confidentiality and authentication, it has multiple
algorithms defined in its SA—one for confidentiality called a cipher
Encapsulating security payload

7. Authentication header(AH)
 Like ESP, AH provides data integrity, data source authentication, and
protection against replay attacks.
 It does not provide confidentiality.
Because of this the AH header is much simpler than ESP; it is merely a
header and not a header plus trailer. In addition, all of the fields in the AH
header are in the clear.
 RFC2402 defines the current incarnation of AH while RFC1826
described an older, deprecated version of AH. The important features of
AH specified in that RFC remain in the new document—providing data
integrity and data source authentication of IP packets—but new features
and clarification of some issues raised with RFC1826 were added.
For example, antireplay protection is now an integral part of the
specification and a definition of using AH in tunnel mode was added.

8. HTTP authentication: web security
 Protect web content from those who don’t have a “need to know”
 Require users to authenticate using a user id/password before they
are allowed access to certain URLs
 HTTP/1.1 requires that when a user makes a request for a
protected resource the server responds with a authentication
request header
 WWW-Authenticate
contains enough pertinent information to carry out a
“challenge-response” session between the user and the
server

9. Client response
 Well established clients like Firefox, Internet Explorer …. will
respond to the challenge request (WWW-Authenticate) by
presenting the user with a small pop-up window with data entry
fields for
 User id
 password
 a Submit button and a Cancel button
 entering a valid user id and password will post the data to the
server, the server will attempt authentication and if authenticated
will serve the originally requested resource.

10. www-authenticate
 The authentication request received by the browser will look something like:
 WWW-Authenticate = Basic realm=“default tRealm”
 Basic indicates the HTTP Basic authentication is requested
 realm indicates the context of the login
 realms hold all of the parts of security puzzle
 Users
 Groups
 ACLs (Access Control Lists)
 Basic Authentication
 userid and password are sent base 64 encoded (might as well be plain text)
 hacker doesn’t even need to unencode all he has to do is “replay” the blob of
information he stole over and over ( this is called a “replay attack”)

11. www-authenticate
 Secure Sockets Layer (SSL)
 Invented by Netscape and made public domain for everyone’s user.
 Public Key Cryptography
 owner of a private key sends a public key to all who want to communicate
with him (keys are both prime factors of a large (1024 bit) number). Owner
keeps the private key secret and uses it to decrypt information sent to him
that has been encrypted with the public-key
 RSA algorithm is most notable public-key cipher algorithm
 Digital Certificates
 issued by a disinterested third party (ex. Verisign)
 the Certificate contains the public-key for the specific Web Server and a
digital signature of the certifying authority

12. Back to SSL
 Once a secure session is established the source requests the
destinations certificate ( sent in the http header (uncncrypted))
 once the source accepts the authenticity of the certificate it uses
the public-key from the certificate to encrypt the generated
session key for protecting the conversation between the source
and destination.
 Session is encrypted using a symmetric cipher (slow)
 conversation is encrypted using an asymmetric cipher (fast)