Unit-3

Extensible Authentication Protocol (EAP)

The Extensible Authentication Protocol (EAP), defined in RFC 3748, acts as a

framework for network access and authentication protocols.
 EAP provides a set of protocol messages that can encapsulate various authentication methods
to be used between a client and an authentication server.
 EAP can operate over a variety of network and link level facilities, including point-to-point
links, LANs, and other networks, and can accommodate the authentication needs of the
various links and networks. Figure illustrates the protocol layers that form the context for
EAP.
Authentication Methods
 EAP supports multiple authentication methods.
 EAP provides a generic transport service for the exchange of authentication information
between a client system and an authentication server.
 The basic EAP transport service is extended by using a specific authentication protocol, or
method, that is installed in both the EAP client and the authentication server.

EAP-TLS (EAP Transport Layer Security):

 EAP-TLS (RFC 5216) define show the TLS protocol can be encapsulated in EAP
messages.
 EAP-TLS uses the handshake protocol in TLS, not its encryption method.
 Client and server authenticate each other using digital certificates.
 Client generates a pre-master secret key by encrypting a random number with the
server’s public key and sends it to the server. Both client and server use the pre-
master to generate the same secret key.
EAP-TTLS (EAP Tunneled TLS):
 EAP-TTLS is like EAP-TLS, except on the server has a certificate to authenticate itself to the
client first.
 As in EAPTLS, a secure connection (the “tunnel”) is established with secret keys, but that
connection is used to continue the authentication process by authenticating the client and
possibly the server again using any EAP method or legacy method such as PAP (Password
Authentication Protocol) and CHAP (Challenge-Handshake Authentication Protocol). EAP-
TTLS is defined in RFC 5281.
EAP-GPSK (EAP Generalized Pre-Shared Key):
 EAP-GPSK, defined in RFC 5433, is an EAP method for mutual authentication and session
key derivation using a Pre-Shared Key (PSK). EAP-GPSK specifies an EAP method based
on pre-shared keys and employs secret key-based cryptographic algorithms.
 Hence, this method is efficient in terms of message flows and computational costs, but
requires the existence of pre-shared keys between each peer and EAP server. The set up of
these pairwise secret keys is part of the peer registration, and thus, must satisfy the system
preconditions.
 It provides a protected communication channel when mutual authentication is successful for
both parties to communicate over and is designed for authentication over insecure networks
such as IEEE 802.11. EAP-GPSK does not require any public-key cryptography.
 The EAP method protocol exchange is done in a minimum of four messages.
EAP-IKEv2:
 It is based on the Internet Key Exchange protocol version 2 (IKEv2)
 It supports mutual authentication and session key establishment using a variety of methods.
EAP-TLS is defined in RFC 5106.

EAP-Exchanges:
 Whatever method is used for authentication, the authentication information and
authentication protocol information are carried in EAP messages.
 RFC 3748 defines the goal of the exchange of EAP messages to be successful
authentication.
 In the context of RFC 3748, successful authentication is an exchange
of EAP messages, as a result of which the authenticator decides to allow access
by the peer, and the peer decides to use this access.
 The authenticator’s decision typically involves both authentication and authorization
aspects; the peer may successfully authenticate to the authenticator, but access may
be denied by the authenticator due to policy reasons.
indicates a typical arrangement in which EAP is used. The following components are involved:
■ EAP peer:
Client computer that is attempting to access a network.
■ EAP authenticator:
An access point or NAS that requires EAP authentication
prior to granting access to a network.
■ Authentication server:
A server computer that negotiates the use of a specific EAP method with an EAP peer,
validates the EAP peer’s credentials, and authorizes access to the network. Typically, the
authentication server is a Remote Authentication Dial-In User Service (RADIUS) server.
The authentication server functions as a backend server that can authenticate peers as a service to a
number of EAP authenticators. The EAP authenticator then makes the decision of whether to grant
access. This is referred to as the EAP pass-through mode. Less commonly, the authenticator takes
over the role of the EAP server; that is, only two parties are involved in the EAP execution.
As a first step, a lower-level protocol, such as PPP (point-to-point protocol) or IEEE 802.1X, is used
to connect to the EAP authenticator. The software entity in the EAP peer that operates at this level is
referred to as the supplicant.
EAP messages containing the appropriate information for a chosen EAP method are
then exchanged between the EAP peer and the authentication server.
EAP messages may include the following fields:
■ Code: Identifies the Type of EAP message. The codes are Request (1),
Response (2), Success (3), and Failure (4).
■ Identifier: Used to match Responses with Requests.
■ Length: Indicates the length, in octets, of the EAP message, including the Code, Identifier, Length,
and Data fields.
Data: Contains information related to authentication.
Typically, the Data field consists of a Type subfield, indicating the type of data carried, and a Type-
Data field.
The Success and Failure messages do not include a Data field.

The EAP authentication exchange proceeds as follows.

 After a lower-level exchange that established the need for an EAP exchange, the
authenticator sends a
 Request to the peer to request an identity, and the peer sends a Response with the
 identity information.
 This is followed by a sequence of Requests by the authenticator and Responses by
the peer for the exchange of authentication information.
 The information exchanged and the number of Request–Response exchanges needed
depend on the authentication method.
 The conversation continues until either the authenticator determines that it cannot
authenticate the peer and transmits an EAP Failure or the authenticator determines
that successful authentication has occurred and transmits an EAP Success.
IEEE 802.1X Port-Based Network Access Control

IEEE 802.1X Port-Based Network Access Control was designed to provide access
control functions for LANs. Table 16.1 briefly defines key terms used in the IEEE
802.11 standard. The terms supplicant, network access point, and authentication server correspond to
the EAP terms peer, authenticator, and authentication server, respectively.
Authenticator
An entity at one end of a point-to-point LAN segment that facilities authentication of the entity to the
other end of the link.
Authentication exchange
The two-party conversation between systems performing an authentication process.
Authentication process
The cryptographic operations and supporting data frames that perform the actual authentication.
Authentication server (AS)
An entity that provides an authentication service to an authenticator. This service determines, from the
credentials provided by supplicant, whether the supplicant is authorized to access the services
provided by the system in which the authenticator resides.
Authentication transport
The datagram session that actively transfers the authentication exchange between two systems.
Bridge port
A port of an IEEE 802.1D or 802.1Q bridge.
Edge port
A bridge port attached to a LAN that has no other bridges attached to it.
Network access port
A point of attachment of a system to a LAN. It can be a physical port, such as a single LAN MAC
attached to a physical LAN segment, or a logical port, for example, an IEEE 802.11 association
between a station and an access point.
Port access entity (PAE)
The protocol entity associated with a port. It can support the protocol functionality associated with the
authenticator, the supplicant, or both.
Supplicant
An entity at one end of a point-to-point LAN segment that seeks to be authenticated by an
authenticator attached to the other end of that link.
  Until the AS authenticates a supplicant (using an authentication protocol), the authenticator
only passes control and authentication messages between the supplicant and the AS; the
802.1X control channel is unblocked, but the 802.11 data channel is blocked.
 Once a supplicant is authenticated and keys are provided, the authenticator can forward data
from the supplicant, subject to predefined access control limitations for the supplicant to the
network.
 Under these circumstances, the data channel is unblocked.
As indicated in Figure 802.1X uses the concepts of controlled and uncontrolled ports. Ports are logical
entities defined within the authenticator and refer to physical network connections.
 Each logical port is mapped to one of these two types of physical ports. An uncontrolled port
allows the exchange of protocol data units (PDUs) between the supplicant and the AS,
regardless of the authentication state of the supplicant.
 A controlled port allows the exchange of PDUs between a supplicant and other systems on the
network only if the current state of the supplicant authorizes such an exchange.
 The essential element defined in 802.1X is a protocol known as EAPOL (EAP over LAN).
 EAPOL operates at the network layers and makes use of an IEEE 802 LAN, such as Ethernet
or Wi-Fi, at the link level. EAPOL enables a supplicant to communicate with an authenticator
and supports the exchange of EAP packets for authentication.

Frame Type Definition

EAPOL-EAP Contains an encapsulated EAP packet.
EAPOL- Start A supplicant can issue this packet instead of waiting for a challenge from the
authenticator.
 EAPOL- Logoff Used to return the state of the port to unauthorized when
the supplicant is finished using the network.
EAPOL- Key Used to exchange cryptographic keying information.
 The most common EAPOL packets are listed in Table .When the supplicant first connects
to the LAN, it does not know the MAC address of the authenticator. Actually it doesn’t
know whether there is an authenticator present at all.
 By sending an EAPOL-Start packet to a special group-multicast address reserved for IEEE
802.1X authenticators, a supplicant can determine whether an authenticator is present and
let it know that the supplicant is ready. In many cases, the authenticator will already be
notified that a new device has connected from some hardware notification.
For example, a hub knows that a cable is plugged in before the device sends any data. In this case the
authenticator may preempt the Start message with its own message.
 In either case the authenticator sends an EAP-Request Identity message encapsulated in an
EAPOL-EAP packet.
 The EAPOL-EAP is the EAPOL frame type used for transporting EAP packets.The
authenticator uses the EAP-Key packet to send cryptographic keys to the supplicant once it
has decided to admit it to the network. The EAP-Logoff packet type indicates that the
supplicant wishes to be disconnected from the network.
 The EAPOL packet format includes the following fields:
■ Protocol version: version of EAPOL.
■ Packet type: indicates start, EAP, key, logoff, etc.
■ Packet body length: If the packet includes a body, this field indicates the body length.
■ Packet body: The payload for this EAPOL packet. An example is an EAP packet.

IP SECURITY
IPSec provides the capability to secure communications across a LAN, across private and public
WANs, and across the Internet. Examples of its use include the following:

• Secure branch office connectivity over the Internet

• 2 Secure remote access over the Internet
• Establishing extranet and intranet connectivity with partners
• Enhancing electronic commerce security

Benefits of IPSec:

• When IPSec is implemented in a firewall or router, it provides strong security

• IPSec in a firewall is resistant to bypass if all traffic from the outside must use IP, and the
firewall is the only means of entrance from the Internet into the organization.
• IPSec is below the transport layer (TCP, UDP) and so is transparent to applications. There is
no need to change software on a user or server system when IPSec is implemented in the firewall or
router.
• IPSec can be transparent to end users. There is no need to train users on security mechanisms
• IPSec can provide security for individual users if needed.
Routing Applications
IPSec can play a vital role in the routing architecture required for internet working. The following are
examples of the use of IPSec. IPSec can assure that
• A router advertisement (a new router advertises its presence) comes from an authorized router
• A neighbor advertisement (a router seeks to establish or maintain a neighbor relationship with
a router in another routing domain) comes from an authorized router.
• A redirect message comes from the router to which the initial packet was sent.
• A routing update is not forged.
IP SECURITY ARCHITECTURE
IPSec Documents
The IPSec specification consists of numerous documents. The most important of these, issued in
November of 1998, are RFCs 2401, 2402, 2406, and 2408:
• RFC 2401: An overview of a security architecture
• RFC 2402: Description of a packet authentication extension to IPv4 and IPv6
• RFC 2406: Description of a packet encryption extension to IPv4 and IPv6
• RFC 2408: Specification of key management capabilities The documents are divided into
seven groups:
Architecture
Covers the general concepts, security requirements, definitions, and mechanisms defining IPSec
technology.
Encapsulating Security Payload (ESP):
Covers the packet format and general issues related to the use of the ESP for packet encryption and,
optionally, authentication.
Authentication Header (AH):
Covers the packet format and general issues related to the use of AH for packet authentication.
Encryption Algorithm:
A set of documents that describe how various encryption algorithms are used for ESP.
Authentication Algorithm:
A set of documents that describe how various authentication algorithms are used for AH and for the
authentication option of ESP.
Key Management:
Documents that describe key management schemes.
Domain of Interpretation (DOI):
Contains values needed for the other documents to relate to each other. These include identifiers for
approved encryption and authentication algorithms, as well as operational parameters such as key
lifetime.

Fig 5.7: IP security Document overview

IPSec Services
IPSec provides security services at the IP layer by enabling a system to select required security
protocols, determine the algorithm(s) to use for the service(s), and put in place any cryptographic keys
required to provide the requested services.
Two protocols are used to provide security:
• An authentication protocol: Designated by the header of the protocol, Authentication Header
(AH);
• Encryption/authentication protocol designated by the format of the packet for that protocol,
Encapsulating Security Payload (ESP).
The services are
• Access control
• Connectionless integrity
• Data origin authentication
• Rejection of replayed packets (a form of partial sequence integrity)
• Confidentiality (encryption)
• Limited traffic flow confidentiality

Security Associations
A key concept that appears in both the authentication and confidentiality mechanisms for IP is the
security association (SA). An association is a one-way relationship between a sender and a receiver
that affords security services to the traffic carried on it.
A security association is uniquely identified by three parameters:
• Security Parameters Index (SPI)
• IP Destination Address
• Security Protocol Identifier
SA Parameters
A security association is normally defined by the following parameters:
a) Sequence Number Counter:
A 32-bit value used to generate the Sequence Number field in AH or ESP headers.
b) Sequence Counter Overflow:
A flag indicating whether overflow of the Sequence Number Counter should generate an auditable
event and prevent further transmission of packets on this SA.
c) Anti-Replay Window:
Used to determine whether an inbound AH or ESP packet is a replay.
d) AH Information:
Authentication algorithm, keys, key lifetimes, and related parameters being used with AH (required
for AH implementations).
e) ESP Information:
Encryption and authentication algorithm, keys, initialization values, key lifetimes, and related
parameters being used with ESP (required for ESP implementations).
f) Lifetime of This Security Association:
A time interval or byte count after which an SA must be replaced with a new SA or terminated, plus
an indication of which of these actions should occur .
g) IPSec Protocol Mode: Tunnel, transport.
h) Path MTU: Any observed path maximum transmission unit and aging variables.
Modes of Transfer
Both AH and ESP support two modes of use: transport and tunnel mode.
Transport Mode:
Transport mode provides protection primarily for upper-layer protocols. That is, transport mode
protection extends to the payload of an IP packet.
Tunnel Mode:
Tunnel mode provides protection to the entire IP packet. To achieve this, after the AH or ESP fields
are added to the IP packet, the entire packet plus security fields is treated as the payload of new
"outer" IP packet with a new outer IP header.
The entire original, or inner, packet travels through a "tunnel" from one point of an IP network to
another; no routers along the way are able to examine the inner IP header. Because the original packet
is encapsulated, the new, larger packet may have totally different source and destination addresses,
adding to the security.
Authentication Header
The Authentication Header provides support for data integrity and authentication of IP packets. The
Authentication Header consists of the following fields:
• Next Header (8 bits): Identifies the type of header immediately following this header.
• Payload Length (8 bits): Length of Authentication Header in 32-bit words, minus 2.
• Reserved (16 bits): For future use.
• Security Parameters Index (32 bits): Identifies a security association.
• Sequence Number (32 bits): A monotonically increasing counter value.
• Authentication Data (variable): A variable-length field (must be an integral number of 32-bit
words) that contains the Integrity Check Value (ICV), or MAC
 IPSec Authentication Header
Anti-Replay Service
 A replay attack is one in which an attacker obtains a copy of an authenticated packet and later
transmits it to the intended destination.
 When a new SA is established, the sender initializes a sequence number counter to 0. Each
time that a packet is sent on this SA, the sender increments the counter and places the value in
the Sequence Number field. Thus, the first value to be used is 1.
 If anti-replay is enabled (the default), the sender must not allow the sequence number to cycle
past 232-1 back to zero. Otherwise, there would be multiple valid packets with the same
sequence number. If the limit of 232-1 is reached, the sender should terminate this SA and
negotiate a new SA with a new key.
Integrity Check Value
The Authentication Data field holds a value referred to as the Integrity Check Value. The ICV is a
message authentication code or a truncated version of a code produced by a MAC algorithm.
Transport and Tunnel Modes
 For transport mode AH using IPv4, the AH is inserted after the original IP header and before
the IP payload
 For tunnel mode AH, the entire original IP packet is authenticated, and the AH is inserted
between the original IP header and a new outer IP header
Encapsulating Security Payload
The Encapsulating Security Payload provides confidentiality services, including confidentiality of
message contents and limited traffic flow confidentiality.
The diagram shows the format of an ESP packet. It contains the following fields:
 Security Parameters Index (32 bits): Identifies a security association.
 Sequence Number (32 bits): A monotonically increasing counter value; this provides an anti-
replay function, as discussed for AH.
 Payload Data (variable): This is a transport-level segment (transport mode) or IP packet
(tunnel mode) that is protected by encryption.
 Padding (0255 bytes): The purpose of this field is discussed later.
 Pad Length (8 bits): Indicates the number of pad bytes immediately preceding this field.
 Next Header (8 bits): Identifies the type of data contained in the payload data field by
identifying the first header in that payload (for example, an extension header in IPv6, or an upper-
layer protocol such as TCP).
 Authentication Data (variable): A variable-length field (must be an integral number of 32-bit
words) that contains the Integrity Check Value computed over the ESP packet minus the
Authentication Data field.

Scope of AH Authentication

Padding:
The Padding field serves several purposes:
 If an encryption algorithm requires the plaintext to be a multiple of some number of
bytes (e.g., the multiple of a single block for a block cipher), the Padding field is used
to expand the plaintext (consisting of the Payload Data, Padding, Pad Length, and
Next Header fields) to the required length.
  The ESP format requires that the Pad Length and Next Header fields be right aligned
within a 32-bit word. Equivalently, the ciphertext must be an integer multiple of 32
bits. The Padding field is used to assure this alignment.
 Additional padding may be added to provide partial traffic flow confidentiality by
concealing the actual length of the payload.
Transport and Tunnel Modes
 ESP service can be used. In the upper part of the figure, encryption (and optionally
authentication) is provided directly between two hosts.
 The diagram shows how tunnel mode operation can be used to set up a virtual private
network.
 In this example, an organization has four private networks interconnected across the Internet.
 Hosts on the internal networks use the Internet for transport of data but do not interact with
other Internet-based hosts.
 By terminating the tunnels at the security gateway to each internal network, the configuration
allows the hosts to avoid implementing the security capability. The former technique is
support by a transport mode SA, while the latter technique uses a tunnel mode SA. Transport
Mode ESP:
 For this mode using IPv4, the ESP header is inserted into the IP packet immediately prior to
the transport-layer header (e.g., TCP, UDP, ICMP) and an ESP trailer (Padding, Pad Length,
and Next Header fields) is placed after the IP packet; if authentication is selected, the ESP
Authentication Data field is added after the ESP trailer.
 The entire transport-level segment plus the ESP trailer are encrypted. Authentication covers
all of the cipher text plus the ESP header.
 For this mode using IPv4, the ESP header is inserted into the IP packet immediately prior to
the transport-layer header (e.g., TCP, UDP, ICMP) and an ESP trailer (Padding, Pad Length,
and Next Header fields) is placed after the IP packet; if authentication is selected, the ESP
Authentication Data field is added after the ESP trailer.
 The entire transport-level segment plus the ESP trailer are encrypted. Authentication covers
all of the cipher text plus the ESP header.
 Transport mode operation provides confidentiality for any application that uses it, thus
avoiding the need to implement confidentiality in every individual application. This mode of
operation is also reasonably efficient, adding little to the total length of the IP packet. One
drawback to this mode is that it is possible to do traffic analysis on the transmitted packets.
 Fig 5.10: Transport mode

Tunnel Mode ESP

 Tunnel mode ESP is used to encrypt an entire IP packet. For this mode, the ESP header is
prefixed to the packet and then the packet plus the ESP trailer is encrypted. This method can
be used to counter traffic analysis.
 Because the IP header contains the destination address and possibly source routing directives
and hop-by-hop option information, it is not possible simply to transmit the encrypted IP
packet prefixed by the ESP header. Intermediate routers would be unable to process such a
packet.
 Therefore, it is necessary to encapsulate the entire block (ESP header plus cipher text plus
Authentication Data, if present) with a new IP header that will contain sufficient information
for routing but not for traffic analysis.
COMBINING SECURITY ASSOCIATIONS
An individual SA can implement either the AH or ESP protocol but not both. Sometimes a particular
traffic flow will call for the services provided by both AH and ESP. Further, a particular traffic flow
may require IPsec services between hosts and, for that same flow, separate services between security
gateways, such as firewalls.
Security associations may be combined into bundles in two ways:
Transport adjacency:
Refers to applying more than one security protocol to the same IP packet without invoking tunneling.
This approach to combining AH and ESP allows for only one level of combination; further nesting
yields no added benefit since the processing is performed at one IPsec instance: the (ultimate)
destination.
Iterated tunneling:
Refers to the application of multiple layers of security protocols effected through IP tunneling. This
approach allows for multiple levels of nesting, since each tunnel can originate or terminate at a
different IPsec site along the path.
The two approaches can be combined, for example, by having a transport SA between hosts travel
part of the way through a tunnel SA between security gateways.
One interesting issue that arises when considering SA bundles is the order in which authentication and
encryption may be applied between a given pair of endpoints and the ways of doing so. We examine
that issue next. Then we look at combinations of SAs that involve at least one tunnel.
Authentication plus Confidentiality
Encryption and authentication can be combined in order to transmit an IP packet that has both
confidentiality and authentication between hosts. We look at several approaches.
ESP with Authentication Option
 This approach is illustrated in diagram. In this approach, the user first applies ESP to the data
to be protected and then appends the authentication data field. There are actually two
subcases:
 Transport mode ESP: Authentication and encryption apply to the IP payload delivered to the
host, but the IP header is not protected.
 Tunnel mode ESP: Authentication applies to the entire IP packet delivered to the outer IP
destination address (e.g., a firewall), and authentication is performed at that destination. The
entire inner IP packet is protected by the privacy mechanism for delivery to the inner IP
destination.
For both cases, authentication applies to the cipher text rather than the plaintext.
Transport Adjacency
 Another way to apply authentication after encryption is to use two bundled transport SAs,
with the inner being an ESP SA and the outer being an AH SA.
 In this case, ESP is used without its authentication option. Because the inner SA is a transport
SA, encryption is applied to the IP payload.
 The resulting packet consists of an IP header (and possibly IPv6 header extensions) followed
by an ESP.AH is then applied in transport mode, so that authentication covers the ESP plus
the original IP header (and extensions) except for mutable fields.
The advantage of this approach over simply using a single ESP SA with the ESP authentication option
is that the authentication covers more fields, including the source and destination IP addresses.
The disadvantage is the overhead of two SAs versus one SA.
Fig 5.11: Protocol Operation for ESP Basic Combinations of Security Associations
The IPsec Architecture document lists four examples of combinations of SAs that must be supported
by compliant IPsec hosts (e.g., workstation, server) or security gateways (e.g. firewall, router).
These are illustrated in Figure .
The lower part of each case in the figure represents the physical connectivity of the elements; the
upper part represents logical connectivity via one or more nested SAs. Each can be either AH or ESP.
For host-to-host SAs, the mode may be either transport or tunnel; otherwise it must be tunnel mode.
Case 1: All security is provided between end systems that implement IPsec.
For any two end systems to communicate via an SA, they must share the appropriate secret keys.
Among the possible combinations are
• AH in transport mode
• ESP in transport mode
• ESP followed by AH in transport mode (an ESP SA inside an AH SA)
• Any one of a, b, or c inside an AH or ESP in tunnel mode
We have already discussed how these various combinations can be used to support authentication,
encryption, authentication before encryption, and authentication after encryption.
Case 2:
 Security is provided only between gateways (routers, firewalls, etc.) and no hosts implement
IPsec. This case illustrates simple virtual private network support.
 The security architecture document specifies that only a single tunnel SA is needed for this
case. The tunnel could support AH, ESP, or ESP with the authentication option.
 Nested tunnels are not required, because the IPsec services apply to the entire inner packet.
Case 3:
 This builds on case 2 by adding end-to-end security. The same combinations discussed for
cases 1 and 2 are allowed here.
 The gateway-to-gateway tunnel provides either authentication, confidentiality, or both for all
traffic between end systems.
 When the gateway-to- gateway tunnel is ESP, it also provides a limited form of traffic
confidentiality. Individual hosts can implement any additional IPsec services required for
given applications or given users by means of end-to-end SAs.
Case 4:
 This provides support for a remote host that uses the Internet to reach an organization‟s
firewall and then to gain access to some server or workstation behind the firewall.
 Only tunnel mode is required between the remote host and the firewall. As in case 1, one or
two SAs may be used between the remote host and the local host.
SECURE SOCKET LAYER(SSL) /TRANSPORT LAYER
SECURITY(TLS)
SSL Architecture
SSL is designed to make use of TCP to provide a reliable end-to-end secure service.
The SSL Record Protocol provides basic security services to various higher-layer protocols. In
particular, the Hypertext Transfer Protocol (HTTP), which provides the transfer service for Web
client/server interaction, can operate on top of SSL. Three higher-layer protocols are defined as part of
SSL: the Handshake Protocol, The Change Cipher Spec Protocol, and the Alert Protocol.

Fig 5.15: SSL Protocol Stack

Two important SSL concepts are the SSL session and the SSL connection, which are defined in the
specification as follows:
Connection:
A connection is a transport (in the OSI layering model definition) that provides a suitable type of
service. For SSL, such connections are peer-to-peer relationships. The connections are transient.
Every connection is associated with one session.
Session:
An SSL session is an association between a client and a server. Sessions are created by the Handshake
Protocol. Sessions define a set of cryptographic security parameters, which can be shared among
multiple connections. Sessions are used to avoid the expensive negotiation of new security parameters
for each connection.
A session state is defined by the following parameters
Session identifier
• Peer certificate
• Compression method
• Cipher spec
• Master secret
• Is resumable
A connection state is defined by the following parameters:
• Server and client random
• Server write MAC secret
• Client write MAC secret
• Server write key
• Client write key.
• Initialization vectors
• Sequence numbers
SSL Record Protocol
The SSL Record Protocol provides two services for SSL connections:
Confidentiality:
The Handshake Protocol defines a shared secret key that is used for conventional encryption of SSL
payloads.
Message Integrity:
 The Handshake Protocol also defines a shared secret key that is used to form a message
authentication code (MAC).
 The diagram indicates the overall operation of the SSL Record Protocol. The Record Protocol
takes an application message to be transmitted, fragments the data into manageable blocks,
optionally compresses the data, applies a MAC, encrypts, adds a header, and transmits the
resulting unit in a TCP segment. Received data are decrypted, verified, decompressed, and
reassembled and then delivered to higher-level users.
 The first step is fragmentation. Each upper-layer message is fragmented into blocks of 214
bytes (16384 bytes) or less. Next, compression is optionally applied. Compression must be
lossless and may not increase the content length by more than 1024 bytes. In SSLv3 (as well
as the current version of TLS), no compression algorithm is specified, so the default
compression algorithm is null.
The next step in processing is to compute a message authentication code over the compressed data.
The final step of SSL Record Protocol processing is to prepend a header, consisting of the following
fields:
• Content Type (8 bits): The higher layer protocol used to process the enclosed fragment.
• Major Version (8 bits): Indicates major version of SSL in use. For SSLv3, the value is 3.
• Minor Version (8 bits): Indicates minor version in use. For SSLv3, the value is 0.
• Compressed Length (16 bits): The length in bytes of the plaintext fragment (or compressed
fragment if compression is used). The maximum value is 214 + 2048.
 Fig 5.16: SSL Record Protocol Operation Change Cipher Spec Protocol
This protocol consists of a single message which consists of a single byte with the value
1.Alert Protocol
The Alert Protocol is used to convey SSL-related alerts to the peer entity.
Each message in this protocol consists of two bytes The first byte takes the value warning(1) or
fatal(2) to convey the severity of the message. The second byte contains a code that indicates the
specific alert.
• unexpected_message: An inappropriate message was received.
• bad_record_mac: An incorrect MAC was received.
• decompression_failure: The decompression function received improper input (e.g., unable to
decompress or decompress to greater than maximum allowable length).
• handshake_failure: Sender was unable to negotiate an acceptable set of security parameters
given the options available.
• illegal_parameter: A field in a handshake message was out of range or inconsistent with other
fields.
The remainder of the alerts is the following:
• Close notify: Notifies the recipient that the sender will not send any more messages on this
connection. Each party is required to send a close_notify alert before closing the right side of a
connection.
• No certificate: May be sent in response to a certificate request if no appropriate certificate is
available.
• bad_certificate: A received certificate was corrupt (e.g., contained a signature that did not
verify).
• unsupported_certificate: The type of the received certificate is not supported.
• certificate_revoked: A certificate has been revoked by its signer.
• certificate_expired: A certificate has expired.
• certificate_unknown: Some other unspecified issue arose in processing the certificate,
rendering it unacceptable.
Handshake Protocol
This protocol allows the server and client to authenticate each other and to negotiate an encryption
and MAC algorithm and cryptographic keys to be used to protect data sent in an SSL record. The
Handshake Protocol is used before any application data is transmitted.
The Handshake Protocol consists of a series of messages exchanged by client and server.
Establish Security Capabilities
This phase is used to initiate a logical connection and to establish the security capabilities that will be
associated with it. The exchange is initiated by the client, which sends a client_hello message with the
following parameters:
1. Version:
The highest SSL version understood by the client.
2. Random: A client-generated random structure, consisting of a 32-bit timestamp and 28 bytes
generated by a secure random number generator. These values serve as nonces and are used during
key exchange to prevent replay attacks.
3.Session ID: A variable-length session identifier. A nonzero value indicates that the client wishes to
update the parameters of an existing connection or create a new connection on this session.
4. CipherSuite: This is a list that contains the combinations of cryptographic algorithms supported by
the client, in decreasing order of preference.
5. Compression Method: This is a list of the compression methods the client supports. After sending
the client_hello message, the client waits for the server_hello message, which contains the same
parameters as the client_hello message.
Server Authentication and Key Exchange
The server begins this phase by sending its certificate; The certificate message is required for any
agreed-on key exchange method except anonymous Diffie-Hellman.
Next, a server_key_exchange message may be sent if it is required. The certificate request message
includes two parameters: certificate_type and certificate_authorities.
Client Authentication and Key Exchange
 If the server has requested a certificate, the client begins this phase by sending a certificate
message. Next is the client_key_exchange message, which must be sent in this phase.
 Finally, in this phase, the client may send a certificate_verify message to provide explicit
verification of a client certificate.
SSL Handshake Protocol Message Types
Message Type Parameters
hello_request null
client_hello version, random, session id, cipher suite, compression method
server_hello version, random, session id, cipher suite, compression method
certificate chain of X.509v3 certificates
server_key_exchange parameters, signature
SSL Handshake Protocol Message Types
Message Type Parameters
certificate_request type, authorities
server_done null
certificate_verify signature
client_key_exchange parameters, signature
finished hash value
 Fig 5.17: Handshake Protocol Action
Finish
 This phase completes the setting up of a secure connection. The client sends a
change_cipher_spec message and copies the pending CipherSpec into the current CipherSpec.
 The client then immediately sends the finished message under the new algorithms, keys,
 and secrets.
Cryptographic Computations Master Secret Creation
The shared master secret is a one-time 48-byte value (384 bits) generated for this session by means of
secure key exchange. The creation is in two stages.
First, a pre_master_secret is exchanged. Second, the master_secret is calculated by both parties. For
pre_master_secret exchange, there are two possibilities:
RSA:
A 48-byte pre_master_secret is generated by the client, encrypted with the server's
public RSA key, and sent to the server. The server decrypts the ciphertext using its private key
to recover the pre_master_secret.
Diffie-Hellman:
Both client and server generate a Diffie-Hellman public key. After these are
exchanged, each side performs the Diffie-Hellman calculation to create the shared
pre_master_secret.

WEB SECURITY
 Web Security may be defined as technological and managerial procedures
applied to computer systems to ensure the availability, integrity, and
confidentiality of information.
 It means that protection of integrity, availability and confidentiality of
computer assets and services from associated threats and vulnerabilities.
The security of the web is divided into two categories
(a) computer security,
(b) network security.
In generic terms, computer security is the process of securing a single, standalone
computer; while network security is the process of securing an entire network of computers.
(a) Computer Security:
Technology and managerial procedures applied to computer systems to ensure the
availability, integrity, and confidentiality of the data managed by the computer.
(b) Network Security:
 Protection of networks and their services from unauthorised modification
destruction, or disclosure and provision of assurance that the network
performs its critical functions correctly and that are nor harmful side effects.
  The major points of weakness in a computer system are hardware, software,
and data.
Web services and its advantages
• Web services provide interoperability between various software applications
running on disparate platforms/operating systems.
• Web services use open standards and protocols. Protocols and data formats are
text-based where possible, which makes it easy for developers to understand.
• By utilising HTTP, web services can work through many common firewall
security measures without having to make changes to the firewall filtering rules.
• Web services allow software and services from different companies and
locations to be combined easily to provide an integrated service.
• Web services allow the reuse of services and components within an
infrastructure.
• Web services are loosely coupled thereby, facilitating a distributed approach to
application integration.
WS-Security
 WS-Security (Web Services Security) is a communications protocol providing a
means for applying security to Web Services Originally developed by IBM,
Microsoft, and VeriSign, the protocol is now officially called WSS.
 The protocol contains specifications on how integrity and confidentiality can be
enforced on Web Services messaging.
Three basic security concepts important to information on the Internet are
 Confidentiality,
 Integrity
 Availability.

Confidentiality

 Confidentiality is the requirement that private or confidential information should not

to be disclosed to unauthorised individuals.
 Confidentiality protection applies to data in storage, during processing, and while in transit.

Integrity has two facts:

Data Integrity:

 This property, that data has not been altered in an unauthorised manner while in storage,
during processing or while in transit.
 Another aspect of data integrity is the assurance that data can only be accessed and altered by
those authorised to do so. Often such integrity is ensured by use of a number referred to as a
 Message Integrity Code or Message Authentication Code.
These are abbreviated as MIC and MAC respectively.

System Integrity:

 This quality that a system has when performing the intended function in an unimpaired
manner, free from unauthorised manipulation.
 Integrity is commonly an organisations most important security objective, after
availability.
 Integrity is particularly important for critical safety and financial data
used for activities such as electronic funds transfers, air traffic control, and financial
accounting.

Availability

Availability is a requirement intended to assure that systems work promptly and

service is not denied to authorised users. This objective protects against:
Intentional or accidental attempts to either:
- perform unauthorised deletion of data or
- otherwise cause a denial of service or data.

Authentication

 Authentication is proving that a user is whom s/he claims to be. That proof may
involve something the user knows (such as a password), something the user has (such
as a “smartcard”), or something about the user that proves the person’s identity (such
as a fingerprint).

Authorisation

 Authorisation is the act of determining whether a particular user (or computer system)
has the right to carry out a certain activity, such as reading a file or running a program.
 Authentication and authorisation go hand in hand. Users must be authenticated before
carrying out the activity they are authorised to perform.

Accountability (to be individual level)

 Accountability is the requirement that actions of an entity may be traced uniquely to

that entity.
 Accountability is often an organisational policy requirement and directly
supports repudiation, deterrence, fault isolation, intrusion detection and prevention,
and after action recovery and legal action.

Assurance

 Assurance is the basis for confidence that the security measures, both technical and
operational, work as intended to protect the system and the information it processes.
Assurance is essential, without its other objectives cannot be met.
Web Security Threats
Threats Consequences Countermeasures
Integrity Modification of user Loss of information Cryptographi
data Trojan horse Compromise of c
browser machine checksums
Modification of Vulnerability to all
memory Modification other threats
of
message traffic in
transit
Confidentialit Eavesdropping on Loss of Encryption, web
y the Net Theft of info information Loss proxies
from server Theft of of privacy
data from client Info
about network
configuration
Info about which
client talks to server
Denial Killing of user Disruptive Difficult to prevent
of threads Flooding Annoying Prevent
Service machine with Bogus user from getting
requests work done
Filling up disk
or memory
Isolating
Machine by
 DNS
attacks
Authenticatio Impersonation of Misrepresentation Cryptographi
n legitimate users of user Belief that c techniques
Data forgery false information is
valid

Two types of attacks are:

 Passive attacks include eavesdropping on network traffic between browser and server and
gaining access to information on a Web site that is supposed to be restricted.
 Active attacks include impersonating another user, altering messages in transit between client
and server, and altering information on a Web site.
WEB TRAFFIC SECURITY APPROACHES
One way to provide Web security is to use IP Security.
The advantage of using IPSec is that it is transparent to end users and applications and
provides a general-purpose solution.

WEB APPLICATION SECURITY SERVICES

 SECURE SHELL APPLICATIONS(SSH)
 Secure Shell (SSH) is a protocol for secure network communications designed to be
relatively simple and inexpensive to implement.
 The initial version, SSH1 was focused on providing a secure remote logon facility to replace
TELNET and other remote logon schemes that provided no security. SSH also provides a
more general client/server capability and can be used for such network functions as file
transfer and e-mail.
SSH is organized as three protocols that typically run on top of TCP
Transport Layer Protocol:
Provides server authentication, data confidentiality, and data integrity with forward secrecy (i.e., if a
key is compromised during one session, the knowledge does not affect the security of earlier
sessions).The transport layer may optionally provide compression.
Transport Layer Protocol:
 Provides server authentication, data confidentiality, and data integrity with forward secrecy
(i.e., if a key is compromised during one session, the knowledge does not affect the security
of earlier sessions).
 The transport layer may optionally provide compression.
User Authentication Protocol: Authenticates the user to the server.
Connection Protocol: Multiplexes multiple logical communications channels
over a single, underlying SSH connection.
 Fig :- SSH Transport Layer Protocol Packet Exchanges

This fig illustrates the sequence of events in the SSH Transport Layer Protocol.
 First, the client establishes a TCP connection to the server. This is done via the TCP protocol
and is not part of the Transport Layer Protocol.
 Once the connection is established, the client and server exchange data, referred to as packets,
in the data field of a TCP segment. Each packet is in the following format.
Packet length:
Length of the packet in bytes, not including the packet length
and MAC fields.
Padding length:
Length of the random padding field.
Payload:
Useful contents of the packet. Prior to algorithm negotiation, this field is uncompressed.
If compression is negotiated, then in subsequent packets, this field is compressed.
Random padding:
Once an encryption algorithm has been negotiated, this field is added. It contains random
bytes of padding so that that total length of the packet (excluding the MAC field) is a multiple
of the cipher block size, or 8 bytes for a stream cipher.
Message authentication code (MAC):
 If message authentication has been negotiated, this field contains the MAC value.
 The MAC value is computed over the entire packet plus a sequence number, excluding the
MAC field.
 The sequence number is an implicit 32-bit packet sequence that is initialized to sequence
number is an implicit 32-bit packet sequence that is initialized to zero for the first packet and
incremented for every packet.The sequence number is not included in the packet sent over the
TCP connection.
 Once an encryption algorithm has been negotiated, the entire packet (excluding the MAC
field) is encrypted after the MAC value is calculated.
 The SSH Transport Layer packet exchange consists of a sequence of steps
The first step, the identification string exchange, begins with the client sending a packet with
an identification string of the form:
SSH-proto version-software version SP comments CR LF
where SP, CR, and LF are space character, carriage return, and line feed, respectively.

Algorithm negotiation.

Each side sends an SSH_MSG_KEXINIT containing lists of supported algorithms in the

order of preference to the sender. There is one list for each type of cryptographic algorithm.
The algorithms include key exchange, encryption, MAC algorithm, and compression
algorithm.
Key exchange.
 The specification allows for alternative methods of key exchange, but at present, only
two versions of Diffie-Hellman key exchange are specified. Both versions are defined
in RFC 2409 and require only one packet in each direction. The following steps are
involved in the exchange.
  In this, C is the client; S is the server; is a large safe prime; is a generator for a
subgroup of GF( ); is the order of the subgroup; V_S is S’s identification string; V_C
is C’s identification string;
 K_S is S’s public host key; I_C is C’s SSH_MSG_KEXINIT message and I_S is S’s
 SSH_MSG_KEXINIT message that have been exchanged before this part begins. The
 values of , , and are known to both client and server as a result of the algorithm
 selection negotiation. The hash function hash() is also decided during algorithm
 negotiation.
 As a result of these steps, the two sides now share a master key K. In addition, the
server has been authenticated to the client, because the server has used its private key
to sign its half of the Diffie-Hellman exchange.
 Finally, the hash value H serves as a session identifier for this connection. Once
computed, the session identifier is not changed, even if the key exchange is
performed again for this connection to obtain fresh keys.
 The end of key exchange is signaled by the exchange of SSH_MSG_NEWKEYS
 packets.
 At this point, both sides may start using the keys generated from , as discussed
subsequently.
Service request.
 The client sends an SSH_MSG_ SERVICE_REQUEST packet to request either
the User Authentication or the Connection Protocol.
 Subsequent to this, all data is exchanged as the payload of an SSH Transport
Layer packet, protected by encryption and MAC.

KEY GENERATION
The keys used for encryption and MAC (and any needed IVs)
are generated from the shared secret key , the hash value from the key exchange
, and the session identifier, which is equal to unless there has been a subsequent
key exchange after the initial key exchange. The values are computed as follows.
Initial IV client to server: HASH(K || H || F || session_id)
• Initial IV server to client: HASH(K || H || E || session_id)
• Encryption key client to server: HASH(K || H || D || session_id)
• Encryption key server to client: HASH(K || H || C || session_id)
• Integrity key client to server: HASH(K || H || B || session_id)
• Integrity key server to client: HASH(K || H || A || session_id)
where HASH() is the hash function determined during algorithm negotiation.
User Authentication Protocol
The User Authentication Protocol provides the means by which the client is authenticated to the
server.
MESSAGE TYPES AND FORMATS
Three types of messages are always used in the User
Authentication Protocol. Authentication requests from the client have the format:
byte SSH_MSG_USERAUTH_REQUEST (50)
string user name
string service name
string method name
... method specific fields
where user name is the authorization identity the client is claiming, service name
is the facility to which the client is requesting access (typically the SSH
Connection Protocol), and method name is the authentication method being used
in this request.
The first byte has decimal value 50, which is interpreted as SSH_MSG_USERAUTH_REQUEST.
If the server either (1) rejects the authentication request or (2) accepts the request but requires one or
more additional authentication methods, the server sends a message with the format:
byte SSH_MSG_USERAUTH_FAILURE (51)
name-list authentications that can continue
Boolean partial success where the name-list is a list of methods that may productively continue the
dialog. If the server accepts authentication, it sends a single byte message: SSH_MSG_
USERAUTH_SUCCESS (52).
MESSAGE EXCHANGE
The message exchange involves the following steps.
1. The client sends a SSH_MSG_USERAUTH_REQUEST with a requested method
of none.
2. The server checks to determine if the user name is valid. If not, the server returns
SSH_MSG_USERAUTH_FAILURE with the partial success value of false. If the user name is valid,
the server proceeds to step 3.
3. The server returns SSH_MSG_USERAUTH_FAILURE with a list of one or more
authentication methods to be used.
4. The client selects one of the acceptable authentication methods and sends a
SSH_MSG_USERAUTH_REQUEST with that method name and the required
method-specific fields. At this point, there may be a sequence of exchanges to
perform the method.
5. If the authentication succeeds and more authentication methods are required, the
server proceeds to step 3, using a partial success value of true. If the authentication
fails, the server proceeds to step 3, using a partial success value of false.
6. When all required authentication methods succeed, the server sends a
SSH_MSG_USERAUTH_SUCCESS message, and the Authentication Protocol is
over.
AUTHENTICATION METHODS
The server may require one or more of the following
authentication methods.
• publickey:
The details of this method depend on the public-key algorithm chosen. In essence, the client sends a
message to the server that contains the client’s public key, with the message signed by the client’s
private key. When the server receives this message, it checks whether the supplied key is acceptable
for authentication and, if so, it checks whether the signature is correct.
• password: The client sends a message containing a plaintext password,
which is protected by encryption by the Transport Layer Protocol.
• hostbased:
Authentication is performed on the client’s host rather than the client itself.
Thus, a host that supports multiple clients would provide authentication for all its clients.
This method works by having the client send a signature created with the private key of the client
host.
Thus, rather than directly verifying the user’s identity, the SSH server verifies the identity of the client
host—and then believes the host when it says the user has already authenticated on the client side.

HTTP Standards
HTTPS (HTTP over SSL) refers to the combination of HTTP and SSL to implement secure
communication between a Web browser and a Web server.
The HTTPS capability is built into all modern Web browsers.
Its use depends on the Web server supporting HTTPS communication. For example, search engines
do not support HTTPS.
The principal difference seen by a user of a Web browser is that URL (uniform resource locator)
addresses begin with https:// rather than http://. A normal HTTP connection uses port 80. If HTTPS is
specified, port 443 is used, which invokes SSL.
16.4 / HTTPS 507
When HTTPS is used, the following elements of the communication are
encrypted:
• URL of the requested document
• Contents of the document
• Contents of browser forms (filled in by browser user)
• Cookies sent from browser to server and from server to browser
• Contents of HTTP header
HTTPS is documented in RFC 2818, HTTP Over TLS. There is no fundamental change in using
HTTP over either SSL or TLS, and both implementations are referred to as HTTPS.
Connection Initiation
 For HTTPS, the agent acting as the HTTP client also acts as the TLS client.
 The client initiates a connection to the server on the appropriate port and then sends the TLS
ClientHello to begin the TLS handshake.
 When the TLS handshake has finished, the client may then initiate the first HTTP request. All
HTTP data is to be sent as TLS application data. Normal HTTP behavior, including retained
connections, should be followed.
 We need to be clear that there are three levels of awareness of a connection in HTTPS. At the
HTTP level, an HTTP client requests a connection to an HTTP server by sending a connection
request to the next lowest layer.
 Typically, the next lowest layer is TCP, but it also may be TLS/SSL. At the level of TLS, a
session is
 established between a TLS client and a TLS server. This session can support one or more
connections at any time.
 As we have seen, a TLS request to establish a connection begins with the establishment of a
TCP connection between the TCP entity on the client side and the TCP entity on the server
side.

Connection Closure
 An HTTP client or server can indicate the closing of a connection by including the
following line in an HTTP record: Connection: close. This indicates that the
connection will be closed after this record is delivered.
 The closure of an HTTPS connection requires that TLS close the connection
with the peer TLS entity on the remote side, which will involve closing the underlying TCP
connection.
 At the TLS level, the proper way to close a connection is for each side to use the TLS alert
protocol to send a close_notify alert. TLS implementations must initiate an exchange of
closure alerts before closing a connection.
 A TLS implementation may, after sending a closure alert, close the connection without
waiting for the peer to send its closure alert, generating an “incomplete close”.
 Note that an implementation that does this may choose to reuse the session. This should only
be done when the application knows (typically through detecting HTTP message boundaries)
that it has received all the message data that it cares about.
 HTTP clients also must be able to cope with a situation in which the underlying TCP
connection is terminated without a prior close_notify alert and without a Connection: close
indicator. Such a situation could be due to a programming error on the server or a
communication error that causes the TCP connection to drop.
 However, the unannounced TCP closure could be evidence of some sort of attack. So
the HTTPS client should issue some sort of security warning when this occurs.