IPSec is a bundle of
protocols and algorithms defining a flexible framework in which it is the user
who selects the actual parameters of the algorithms and methods to be used. As a result, one should
assume that two IPSec implementation instances are not necessarily identical.
IPsec
is defined in RFC 2401 to 2411 and 2451.
In a communications
network, security has a few different aspects, the most important being:
Authentication
|
Making
sure that the data received is indeed coming from the expected partner
(avoiding
unauthorized sources to transmit data to a station)
|
Integrity
|
Making
sure that the data received is indeed what was transmitted by the source
(avoiding
modifications to the data by unknown parties, executed while the data
traveled from source to destination)
|
Rejection
of replayed data
|
Making
sure that receivers identify and discard packets that have been already
received
(avoiding
multiple executions of same command, generated by unknown parties)
|
Confidentiality
|
Making
sure that nobody “listens and understands” the data on its way from source to
destination
|
IPsec addresses all
the above services and defines the necessary tools for their provision.
The basic idea of
IPsec is to “mark” packets before being injected into the communications
network, and use this “mark” at the receiving side in order to decide whether
the packet arrived from the correct source (authentication), whether the packet
content is exactly the one generated by the source, without any modifications
(integrity) and whether the packet is not a replay of one of the previous
packets, already received (rejection of replayed data).
In addition, IPsec
also defines a framework for data encryption ensuring that potential
“listeners” in the network would not be able to understand the information
carried in the packet (confidentiality).
The “marking” process results in new
fields being added to the packet to be protected.
The
"marking" of the packets before their transmission may be executed
by:
- the user computer
(client), or by
- the ingress edge router
(the first router met by the transmitted packet, the router connecting the user
to the communications network)
When the user
computer is the one marking the transmitted packets, it is said that IPsec is
used in “transport mode”.
When the ingress router is doing the job
on behalf of the user (acting as a proxy IPsec entity), it is said that IPsec
is used in “tunnel mode”.
Authentication / Integrity
Check Principles
Authentication and
integrity check processes are based on the addition to the packet to be
protected of an Integrity Check Value (ICV) field allowing the receiving party
to be sure that:
a.- The packet was
indeed sent by the expected partner (authentication)
b.- The packet has not been modified
(tampered with) during its trip through the network (integrity check)
Generating
and Using the ICV
Observations:
1.- Messages
encrypted with a specific key can be correctly decoded ONLY by using the same
key.
2.- A decoding
process using a specific key, applied to a message encrypted with a different
key, results in a message different than the original one.
Generic Authentication Process Transmission
ICV is the result of
two consecutive processes executed to the packet to be protected.
- step 1 - A hash
value is calculated for the packet to be protected.
- step 2 - The hash value obtained in
step 1 is encrypted using a secret key, generating the ICV value to be added to
the packet.
IP Sec Marking Location and Protection Areas
Depending on the
specific IP Sec protocol used, and the selected mode (transport or tunnel), IP
Sec marking appears in different locations in the protected packet.
When authentication
is used, the marking protects the whole packet.
When confidentiality
marking is used, the transport and tunnel mode provide different types of
services.
In transport mode the
encryption process is executed by the end station, and routers in the network
are expected to route the encrypted packet toward its destination.
As a result, the
encrypting station cannot encrypt the IP header, as it includes the vital
information needed by routers for correct operation. The only part that can be
protected in this case is the payload itself (the upper layers).
In tunnel mode the
encryption process is executed by the ingress router, and the resulting packet
is sent via the network to another router (the other end of the tunnel) as
indicated in a NEW IP header, added by the ingress router.
As a
result, the ingress router can encrypt the whole original packet (payload and
original IP addresses). Both authentication and confidentiality services are
based on packet marking executed at transmission site, followed by decoding
executed at the receiving site.
Security
Associations (SA)
Obviously,
the receiving party should be aware of the marking executed by the transmitting
party. The two parties, have to enter into a logical relationship, known as a
“Security Association (SA)”, where the actual parameters regarding the
algorithms and keys to be used are agreed.
Security
Associations are unidirectional.
In a
bi-directional link in which both directions have to be protected by IPsec,
there will be two Security Associations: A-to-B and B-to-A.
Security
Associations are uniquely identified by fields present in the protected packet,
allowing the receiving party to associate a received packet to a specific
Security Association and (as a result) to activate the correct algorithms for
its processing.
IPSec consists of 3 major parts:
1.-
AH - Authentication Header protocol (RFC 2402): Provides
marking for authentication, integrity and replay protection
2.- ESP - Encapsulating
Security Payload (RFC 2406): Provides
marking for authentication, integrity and replay protection as well as for
confidentiality. As both authentication and encryption algorithms imply the use
of encryption keys, one more element is needed; a protocol to handle the
encryption key selection and other administrative issues related to the
creation and maintenance of a Security Association between nodes.
3.- IKE - Internet Key
Exchange (RFC 2409) : Establishes and maintains
Security Associations.
AH - Authentication Header protocol (RFC
2402)
- Next header - type of next
payload
- Payload length
- SPI - Arbitrary value that,
together with the IP DA of the packet, identifies the actual Security
Association (SA) to which the packet belongs.
- Stations identify the SA to be
used for the processing of an incoming packet, based on:
- IP DA
- SPI
- security service (as indicated
by the "protocol” value in the field preceding the security header – AH or
ESP)
- Sequence number - avoids replay
of the packet
- Authentication data - includes Integrity
Check Value (ICV), used to authenticate the packet
ESP - Encapsulating Security Payload (RFC
2406)
- SPI - Arbitrary value that,
together with the IP DA of the packet, identifies the actual Security
Association (SA) to which the packet belongs.
- Stations identify the SA to be
used for the processing of an incoming packet, based on:
- IP DA
- SPI
- security service (as indicated
by the ‘protocol” value in the field preceding the security header - AH or ESP)
- Sequence number - avoids replay
of the packet .
- Pad length
- Next header - type of payload
in the packet .
- Authentication data - includes Integrity
Check Value (ICV), used to authenticate the packet.
IKE - Internet Key Exchange protocol (RFC
2409)
The purpose of the IKE protocol is to
negotiate the protection parameters (protocols, keys, keys life time, etc.) to
be used by the partners.
IKE is a protocol built as a combination of
- ISAKMP (Internet Security Association and Key Management
Protocol) defined by NSA (National Security Agency) for the negotiation of the
SA parameters, and
- OAKLEY protocol, based on Diffie-Hellman,
for the selection of the encryption keys
For an effective protection of the data, the
parameters negotiation should be itself protected.
IKE defines therefore two different phases:
- Phase 1 - Creates a protected environment (an SA) between the
partners, to protect the negotiation of the authentication and encryption
parameters to be used in the actual data transfer phase.
Phase 1 can be executed either via the Main Mode protocol (MM) or
via the Aggressive Mode protocol (AM).
- Phase 2 - Partners negotiate the protection parameters to be
used in the data transfer phase. The negotiation is protected by the elements
defined in phase 1.
Phase 2 is executed through the protocol known as the Quick Mode.
Phase 1 Main Mode concept:
- Step a - One party sends an offer including all the parameters
needed to define a Security Association (SA), EXCEPT the keys.
Receiving party answers
with the selected parameters.
- Step b - Parties exchange their public keys and some random
sequences (nonce) to be used in step c.
- Step c - Using the keys and nonces
exchanged in step b, parties authenticate each other.
At the end of these three steps, the two
partners have been authenticated, and keys have been generated for the
protection of the messages to be exchanged in Phase 2.
At
the end of Phase 2, all the parameters and the keys necessary for operation are
defined, and partners can start the actual data transfer phase, generating AH
or ESP protected packets.
Source :
Paul
Asadoorian
Interpeak
http://www.openbsd.org/faq/faq13.html – OpenBSD Doc
http://www.freeswan.org/ – Linux
IPsec Support
http://www.ietf.org/html.charters/ipsec-charter.html
– All RFC's &
Drafts
http://www.cisco.com/warp/public/105/IPSECpart1.html
– Intro from
Cisco
http://www.counterpane.com/ipsec.pdf – An eval of
IPsec
Etkinlik 18 Aralık 2014 tarihinde TSE Genel Kurul Salonu'nunda gerçekleştirildi.,
Celil ÜNÜVER (SignalSec Kurucu ortağı) in yaptığı konuşma ile buglar, programlarda bulunan açıklıklar, kimlerin bu açıklıklarla ilgilendiği , ne amaçlar için kullanılabileceği hakkında bilgi sahibi olduk.
