Security Architecture for the internet Protocol

1
Security Architecture for the internet Protocol

• Dr. A. K. Aggarwal

2
Introduction

• Identifying the Need
• Basic Terminology
• Symmetric Asymmetric Encryption
• Hash Function
• Message Digest, Digital Signature, secure Digital
  Envelope
• IP Authentication Header (AH)
• Encapsulating Security Payload (ESP)header

3
Identifying the need

• 1994 Internet Architecture Board issued RFC
  1636 on security in the Internet Architecture
• Problems
• IP Spoofing
• Packet Sniffing etc
• Requirements
• Authentication (not based on IP address)
• Encryption

4
IPSec

• Nov 98
• RFC 2401 An Overview of security
  Architecture
• RFC 2404 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

5
Applications of IPSec

• Secure branch office connectivity over internet
• Secure remote access over internet
• For secure extranet with partners
• E-commerce security

6
Applications of IPSec continued

• Routing Applications
• Advertisement from an authorized router
• Neighbor -ad from an authorized router
• Redirect message from the router to which the
  original message was sent
• Routing protocols like OSPF may be run on top of
  the IPSec.

7
Basic Terminology

• Integrity
• Property of ensuring that data is transmitted
  from the source to destination without any
  alteration
• Authentication
• Confirming that the claimed sender is in fact the
  actual sender

8
Basic terminology (cont.)

• Confidentiality
• Property of communicating such that the intended
  recipients know what was being sent. No
  unintended party should be able to determine the
  message.
• Non Repudiation
• Property of a receiver being able to prove that
  the sender of some data did in fact send the data
  even though the sender might later desire to deny
  it

9
Encryption

• Encryption
• Transformation of data into some readable from to
  ensure PRIVACY
• Decryption
• Transformation of encrypted data into
  intelligible form
• Two Methods of Encryption Symmetric and
  Asymmetric key Encryption

10
Symmetric Key Encryption

• Also called Private key Encryption

Pr-key
Encrypted Message
Message
Internet
Pr-key
Encrypted Message
Message
11
Symmetric Key Encryption

• Reasonably fast processing
• But key management is difficult and less secure

12
Asymmetric Key Encryption

• Also called Public key Encryption

A
Bs public
Encrypted Message
Message
key
Internet
Bs private
Encrypted Message
Message
key
B
13
Asymmetric Key Encryption

• Can be used in many security protocols
• Key management is more secure
• But this algorithm is slow

14
Hash function

• Variable Fixed
• Size input x gt size string h
• i.e. H(x) h
• h hash value of input

15
Hash functions for use in cryptography

• Easy to compute h
• H(x) is ONE-WAY.
• i.e. given h gt computationally infeasible to
  find some input x such that H(x) h.
• H(x) is COLLISION FREE.

16
Weakly COLLISION FREE hash function

• Give a message X
• Computationally infeasible to find a message y
  such that H(x) H(y)
• Strongly COLLISION FREE hash function
• Computationally infeasible to find any two
  message x and y such that H(x) H(y)
• Hash value A digital fingerprint of the message

17
Message digest

• Fixed length hash value of a variable length
  message calculated by using a hashing algorithm
• Probability of two different messages having the
  same Message Digest should be very very slow it
  depends on the sophistication of the hashing
  algorithm used

18
Message Digest (cont)

Variable Length Message
Fixed Length Digest
Hashing Algorithm
19
Digital signature

• Digital Signatures A is to sign a Msg and send
  it to B

Decoder using Public key of A
B
Msg
Msg Encoded Digest
Msg Encoded Digest
A
Digest Algorithm
Digest
Digest Algorithm
Msg
Encoding using Private key of A
Digest
Compare
20
Message digest

• Fixed length hash value of a variable length
  message calculated by using a hashing algorithm
• Probability of two different messages having the
  same Message Digest should be very very slow it
  depends on the sophistication of the hashing
  algorithm used

21
Message Digest (cont)

Variable Length Message
Fixed Length Digest
Hashing Algorithm
22
Digital signature

• Digital Signatures A is to sign a Msg and send
  it to B

Decoder using Public key of A
B
Msg
Msg Encoded Digest
Msg Encoded Digest
A
Digest Algorithm
Digest
Digest Algorithm
Msg
Encoding using Private key of A
Digest
Compare
23
Basic terminology (cont)

• Security Association
• The association that the sender and receiver
  agree to form for security purpose.
• Associated with a set of security parameters
  relating to a given network connection and the
  destination(s).

24
Security Association

• S.A.
• a one-way relationship between a sender and a
  receiver, that affords security services to the
  traffic carried on it.
• For a peer relationship, i.e. for two-way secure
  exchange, two security associations are
  required.
• Uniquely identified by three parameters
• Security parameter Index
• IP destination address
• Security protocol identifier

25
Security Parameters Index
(continued)

• SPI
• A bit string assigned to an SA and having local
  significance only.
• The SPI is carried in AH and ESP headers to
  enable the receiving system to select the SA
  under which a received packet will be processed.
  

26
Security Parameters Index (SPI)

• An unstructured index which is used in
  conjunction with the destination address to
  identify a security Association.
• Consists of
• Authentication Algorithm its MODE
• Key for Authentication
• Encryption algorithm and its Mode

27
SPI Parameters (continued)

• Key for Encryption
• Presence/Absence and size of initialization
  vector for Encryption Algorithm
• Lifetime of key
• Lifetime of Security Association
• Source Address
• Sensitivity Level (e.g. Secret/unclassified)

28
S.A. parameters continued

• IP Destination Address
• only unicast addresses
• this is the address of the destination
  endpoint of the SA, which may be
• an end user system or
• a network system such as a firewall or a
  router
• Security Protocol Identifier
• IPSec has two protocols.
• Each of the two protocols has its own
• S.A.
• S.P.I. indicates to which of the two
  protocols, the
• given S.A. belongs.

29
IPSec Twin protocols (after slide 18)

• Twin Protocols
• AH (Authentication Header) provides
• data origin authentication,
• access control,
• rejection of replayed packets
• ESP (Encapsulating Security Payload)
• In addition ESP provides
• Confidentiality of data
• Limited traffic flow confidentiality

30
Two Modes For Both Protocols

• Transport Mode Provides Protection to upper
  layer protocols (like TCP, UDP or ICMP)
• ESP Encrypts, and optionally authenticates, the
  IP Payload but not the IP header
• AH Authenticates the IP payload and selected
  portions of the IP header (leaving out fields of
  TTL and CHECKSUM, which change during transit.)

31
Two Modes For Both Protocols contd.

• Tunnel Mode
• Protection to the entire IP packet
• May Provide tunneling between firewall (or a
  safe router) at the senders site to a firewall
  (or a safe router) at the receivers site.
• After all AH or ESP fields are added to the IP
  packet, the entire packet is considered as the
  payload and a new --outer-- IP header is
  created for the entire packet.

32
Two Modes the Tunnel Mode contd.

• Tunnel Mode continued
• ESP Encrypts, and optionally authenticates, the
  entire inner IP packet including the inner IP
  header.
• AH Authenticates the entire inner IP packet and
  selected portion of the outer IP header.

33
Security Association Data base

• In each IPSec implementation, there is a nominal
• Security Association Data base.
• The database defines the parameters associated
  with each SA.

34
S.A. Database parameters

• Sequence Number
• A 32-bit value used to generate the sequence
  number field in AH or ESP headers (required for
  all implementations).
• Used for anti-replay service
• 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 (required for all
  implementations).

35
Process of selecting Sequence Number

• On establishing a new security association, set
  sequence number to zero.
• Whenever a packet is to be sent, increment SN by
  1. Put the incremented value in the SN field.
• Thus SN field can have values from 1 to (232-1).
• On reaching the limit, the S.A. is terminated and
  a new S.A. is negotiated with a new key.

36
Window for avoiding a replay

• To avoid a replay, a fixed-sized window (default
  size 64) is created.

W
N
On receiving a packet which is authenticated, the
packet number is marked as shown.
N-W
37
Using the window for avoiding a replay

• If a packet (N 1) is received, and if it is
  authenticated, the window is moved forward.
• if the packet is to the left of the window or if
  authentication fails, the packet is discarded.

38
S.A. database parameters continued

• Anti-replay Window
• Used to determine whether an inbound AH or ESP
  packet is a replay ( required for all
  implementations).
• AH Information
• Authentication algorithm,
• keys,
• key lifetimes, and related parameters being
  used with AH
• (required for all AH implementations).

39
S.A. database parameters continued

• ESP information
• encryption and authentication algorithm,
• keys,
• initialization values,
• the presence and absence of the initialization
  vector,
• key lifetimes, and related parameters being
  used with ESP
• (required for all ESP implementations).

40
S.A. database parameters continued

• Lifetime of this security Association
• A time interval or byte count after which an
  SA must be replaced with a new SA (and new SPI)
  or terminated
• plus an indication of which of these actions
  should occur
• (required for all implementations).

41
S.A. database parameters continued

• IPSec Protocol Mode
• Tunnel or transport
• (required for all implementations).
• Source Address
• Path MTU
• Any observed path maximum transmission unit
  (maximum size of a packet that can be transmitted
  without fragmentation)
• (required for all implementations).
• Sensitivity Level
• E.g. Secret/unclassified

42
Security Policy Database (SPD)

• SPD For relating IP traffic to specific SAs
• (or no SA in the case of traffic allowed
  to
• bypass IPSec)
• Each SPD entry defines a subset of IP traffic
• and points to an SA for that traffic.
• Each SPD entry is defined by
• a set of IP and upper-layer protocol field
  values, called selectors.
• Selectors used to filter outgoing traffic in
  order to map it into a particular SA.

43
Process followed by each IP packet

• Compare the values of the appropriate fields in
  the packet (the selector fields) against the SPD
  to find matching SPD entry, which will point to
  zero or more SAs.
• Determine the SA if any for this packet and its
  associated SPI.
• Do the required IPSec processing (i.e. AH or ESP
  processing).

44
Selectors to determine an SPD entry

• Destination IP Address may be
• a single IP address,
• an enumerated list or range of addresses, or
• a wildcard (mask) address.
• The latter two are required to support more
• than one destination system sharing the same
• SA (e.g., behind firewall).

45
Selectors continued

• Source IP Address may be
• a single IP address,
• an enumerated list or range of addresses, or
• a wildcard (mask) address.
• The latter two are required to support more
• than one source system sharing the same
• SA(e.g.behind firewall).
• User ID from the operating system.
• not a field in the IP or upper-layer headers
  but is available if IPSec is running on the same
  operating system as the user.

46
Selectors continued

• Data Sensitivity Level
• used for system providing information flow
  security (e.g., secret or unclassified).
• Transport Layer Protocol
• Obtained from the IPv4 Protocol field.
• In SPD, may be
• an individual protocol number,
• a list of Protocol numbers, or
• a range of protocol numbers

47
Selectors continued

• IPSec Protocol (AH or ESP or AH/ESP)
• If present, this is obtained from the IPv4
  Protocol.
• Source and Destination Ports may be
• individual TCP or UDP port values,
• an enumerated list of ports, or
• wildcard port.
• Type of Service (TOS)
• Obtained from the IPv4 header. This may be a
  specific IPv4 TOS value or a wildcard value.

48
Headers for IP Security Service

• IP Authentication Header (AH)
• IP Encapsulation security Payload (ESP) Header

49
IP Authentication Header(AH)

• Provides Integrity and authentication without
  confidentiality
• May provide non-repudiation if asymmetric
  encryption algorithm is used
• Uses at least 128 bit key
• The receiver verifies the correctness of the data
  upon reception

50
IP Authentication Header(AH)

• The sender computes a cryptographic
  authentication function over the datagram, using
  a secret key leaving out fields of TTL and
  CHECKSUM, which change during transit
• Location of the Header
• IP header Auth header Upper protocol (e.g.
  TCP, UDP)
• ----------------------------------------------
  --------------------

51
Authentication Data Syntax

• The AUTHENTICATION DATA field may have a variable
  number of bits.

52
IP Authentication Header(AH)

• Fields of the Authentication Header
• Next header
• 8 bit wide. Identifies the next payload after the
  authentication
• Values in this field are the set of IP Protocol
  Numbers as defined in the most recent RFC from
  ICANN ( Internet Corporation for Assigned Names
  Numbers) describing assigned Numbers. e.g.
  protocol numbers for TCP and UDP are 6 and 17
  respectively.

53
IP Authentication Header(AH)

• Payload length
• 8 bits wide.
• Length of the Authentication Data field in 32-bit
  words
• Minimum value is 0 words, which is only used in
  the degenerate case of a null authentication
  algorithm.

54
IP Authentication Header(AH)

• Reserved
• 16 bits wide.
• Reserved for future use.
• Must be set to al zeros when sent.
• The value is included in the Authentication Data
  calculation, but is otherwise ignored by the
  recipient.

55
IP Authentication Header(AH)

• Security Parameters Index (SPI)
• 32-bit pseudo-random value identifying the
  security association for this datagram.
• Value 0 is reserved to indicate that no security
  association exists.
• Values in the range 1 through 255 are reserved
  for ICANN (Internet Corporation for Assigned
  Names Numbers) for future use.

56
IP Authentication Header(AH)

• Authentication Data
• Variable length field but is always an integral
  number of 32-bit words.
• An implementation normally uses combination of
  Destination Address and SPI to locate the
  Security Association, which specifies the fields
  size and use.

57
CALCULATION AUTHENTICATION DATA

• Uses a message digest algorithm e.g. MD5
• MD5 (Rivest 1991)
• INPUT a message of arbitrary length (padded so
  that the length in bytes is divisible by 16)
• Output 128 bit message digest
• 1994 Oorschot Wiener 10M m/c may take 24
  days to find a collision for MD5

58
Authentication Data

• MD5 (which produces 128bit output) or SHA 1
  Secure Hash Algorithm (which produces 160bit
  outputs) may be used. However only the first 96
  bits are sent.
• The message Authentication code, using MD5 or
  SHA-1 is calculated over
• IP header fields that do not very during transit
• AH header other than the Authentication data
• The entire upper level protocol

59
CALCULATION AUTHENTICATION DATA..

• Message digest either encrypted or is keyed
  directly
• To process an outgoing IP packet for
  authentication it uses Security Association.
• All security Association are unidirectional.
• Sending
• userid and destination Address OR-
• SPI and destination address
• determines Security Association to use.

60
CALCULATION AUTHENTICATION DATA..

• RECEIVER Authentication header processing is
  performed after reassembly of packets
• Receiver uses destination Address and SPI value
  to locate Security Association
• Receiver independently verifies Authentication
  Data field and the received data packet are
  consistent.

61
CALCULATION AUTHENTICATION DATA..

• If the processing of the authentication algorithm
  indicates the datagram
• Valid, then it is accepted.
• Invalid and MUST record the authentication
  failure in the system log or audit log. Recorded
  log data MUST include the SPI value, date/time
  received, clear-text sending address, clear-text
  Destination Address.

62
IP ENCAPSULATING SECURITY PAYLOAD(ESP)

• Provides integrity and confidentiality
• Can also provide authentication, if
  authenticating encryption algorithms are used
• Non-repudiation and protection from traffic
  analysis not provided.
• Two modes of Operation
• Tunnel mode Encapsulates an entire IP datagram
  within the ESP header

63
IP ENCAPSULATING SECURITY PAYLOAD(ESP) (cont)

• Transport mode Encapsulates an upper layer
  protocol like TCP or UDP inside ESP and then
  prepends a cleartext IP header
• Users to select the encryption algorithm
• All ESP implementations must be able to use Data
  Encryption Standard (DES) in the Cipher Block
  changing (CBC) mode
• BLOCK CIPHER
• Fixed length Secret key Fixed length
• Block of data gt Cipher

64
DES in CBC mode

• Usual Block size 64 bits
• Uses INITIALISATION VECTOR c0
• A plaintext block of data Xor-ed with previous
  ciphertext block and then encrypted.

65
CBC DES Operation

• ------- m( i-1 ) m (i) ----------------

En
En
--------------- c( i-1 ) c (i) En (m (i)
EXOR c (i-1) )
66
ENCAPULATING SECURITY PAYLOAD (ESP) SYNTAX

• ESP appears anywhere after the IP header and
  before the final transport-layer protocol.
• ICANN assigned Protocol Number 50 to ESP
• Header immediately preceding an ESP header will
  always contain value 50 in its next header or
  protocol (IPv4) field
• ESP consists of an unencrypted header followed by
  encrypted data.

67
ESP SYNTAX

• Encrypted data includes both the protected ESP
  header fields and the protected user data, which
  is either an entire IP datagram or an upper-layer
  protocol frame (e.g. , TCP or UDP).
• lt-- Unencrypted --gtlt---- Encrypted ----gt
• -----------------------------------------------
  ---------------------
• IP Header Other IP headers ESP header
  Encrypted data
• -----------------------------------------------
  ---------------------

68
ESP SYNTAX

• Encryption and authentication algorithms, and the
  precise format of the opaque Transform Data
  associated with them are known as transforms.
• Designed to support new transforms in the future
  to support new or additional cryptographic
  algorithms.
• The transforms are specified by themselves
  rather than in the main body of this
  specification.

69
IPSec ESP format
70
Fields of the ESP

• SPI is a 32-bit Pseudo-random value identifying
  the security association for this datagram. SPI
  is the only mandatory transform-independent
  field.
• IV is also usually not encrypted.
• OPAQUE PART
• -------------------------------------------------
  --------------
• Initialization Vector (IV)
• ---------------------
• Payload Data
• ---------------------
• padding pad Length Payload type
• ---------------------

71
Initialization vector (IV)

• Size of this field is variable, although it is
  constant for all DES-CBC datagrams of the same
  SPI and IP destination.
• Octets are sent in network order (most
  significant octet first).
• Size MUST be a multiple of 32-bits. Size of 32
  and 64 bits are required to be supported.
• Size is expected to be indicated by the key
  management mechanism.

72
Initialization Vector (IV)

• When size is 32-bits, a 64-bit IV is formed from
  32-bit value followed by (concatenated with)
  bit-wise complement of 32-bit value.
• Value should not repeat during lifetime of
  encryption session key.
• Even when a full 64-bit IV is used, the session
  key should be changed at least as frequently as
  232 datagrams.

73
Payload Data

• Size is variable.
• Prior to encryption and after decryption, this
  field begins with IP protocol/ payload header
  specified in the payload Type field.
• Note that in the case of IP-in-IP encapsulation,
  this will be another IP header.

74
Padding

• Size is variable.
• After decryption, it MUST be ignored.
• PAD LENGTH Indicates the size of the Padding
  field. It does not include the Pad Length and
  Payload type fields.
• Value typically ranges from 0 to 7, but may be up
  to 255 to permit hiding of the actual data length.

75
Payload Type

• Indicates contents of Payload Data field, using
  IP Protocol/payload value.
• Values of IP Protocol/payload are specified in
  most recent Assigned Numbers.
• e.g., when encrypting an entire IP datagram
  (Tunnel-mode), this field will contain the value
  4, which indicates IP-in-IP encapsulation.

76

• Total/payload Length in the encapsulating IP
  header reflects length of the encrypted data,
  plus the SPI, IV, padding, Pad Length, and
  Payload Type octets.
• Octets are mapped to DES blocks in network order
  (most significant octet first).
• Octet 0 (modulo 8) of payload corresponds to bits
  1-8 of 64-bit DES input block, while octet 7
  (modulo 8) corresponds to bits (57-64 of the DES
  input block.

77
   
ESP HEADER
   
78
ESP Trailer
End of payload
Padding
Padding
Type of Payload 8 bits
Pad length 8 bits
Padding

Note 1 Padding can be 0 to 255 Bytes
2 The trailer consist of the padding and two
field of pad length and type of payload
79
ESP Transport Mode
Transport layer header data
ESP AUTH
IP header
ESP header
ESP Trailer
TLH D and ESP trailer are encrypted ESP HEADER
and encrypted TLH D and ESP TRAILER are
authenticated
80
ESP procedure

• Steps
• Add ESP trailer to the the payload.
• Encrypt the payload and the trailer.
• Add the ESP header.
• Create Authentication data on
• ESP header
• Payload
• ESP trailer
• Add the Authentication data after the trailer.
• Add the IP header after changing PROTOCOL value
  to 50.

81
ESP Transport vs Tunnel Mode

Authenticated
Encrypted
ESP trlr
ESP auth
Orig IP hdr
Data
ESP hdr
TCP
IPv4
TRANSPORT MODE
Authenticated
Encrypted
ESP auth
ESP trlr
New IP hdr
Orig IP hdr
TCP
ESP hdr
Data
TUNNEL MODE
82
Key Management

• A typical requirement
• 4 keys
• 2 keys for duplex communication between two
  applications for AH
• 2 keys for duplex communication between two
  applications for ESP
• Two types of key management
• manual
• automated

83
Key Management Default

• Oakley Key Determination protocol
• based on Diffie-Hellman algorithm
• Oakley Exchange Examples A number of methods are
  allowed under the protocol.
• We consider the method, called the Aggressive
• Key Exchange. (known as aggressive because it
• uses the exchange of only three messages.)

84
Clogging Attacks Cookies

• Clogging Attack The attacker, using a spoofed
  address, sends the public Diffie-Hellman key to
  the victim. The victim performs modular
  exponentiation to compute the secret key. If a
  flood of such messages is sent to the victim, his
  machine would be clogged in uselessly computing
  the secret keys for each of the messages.
• To avoid it, cookies are used.

85
A Cooky

• The issuing host should use a local secret
  information to generate the cooky.
• Usually it is obtained by generating a hash on a
  combination of the following
• IP source and destination addresses
• UDP source and destination ports
• A locally generated secret number
• The cooky is not stored by the sender. But he can
  regenerate it to verify it.
• The proper use of such a cooky can avoid
  swamping of a victim by randomly generated source
  addresses.

86
Three Steps of Aggressive Oakley Key
Exchange

• Step 1 The initiator sends
• Cooky
• The group to be used
• Initiators public Diffie-Hellmans key
• The encryption algorithms that it can use for PK
  encryption Hash Authentication
• Identifiers of I and R
• Is nonce
• I adds his signature by signing all the above
  except the cooky.

87
The Second Step of Aggressive Oakley Key
Exchange

• Step 2On receipt, R verifies using Is public
  key. R acknowledges back, by echoing back
• Is cooky identifier nonce group.
• The responder sends
• Cooky
• The group to be used
• Rs public Diffie-Hellmans key
• The selected encryption algorithms, out of the
  list sent by the initiator
• Identifiers of R
• Rs nonce
• R adds his signature by signing two nonces,
  two identifiers two public D-H keys group
  selected algorithms.

88
The Third Step of Aggressive Oakley Key
Exchange

• Step 3 On receipt of the message, I verifies
  using Rs public key.
• Nonce values ensure that it is not a replay of
  an earlier message.
• I sends a message to R indicating that it has
  received its public key.

89
Aggressive Oakley Key Exchange

• I-gtR CKY1, OK_KEYX, GRP, gx, EHAO, NIDP, Idi ,
  IDR, Ni,
• Ski Idi IDR Ni GRPEHAO
• R-gtI CKYR, CKYi, OK_KEYX, GRP, gy , EHAS, NIDP,
  IDR, IDi,, NR, NI,
• SKR IDR Idi NR Ni GRP gy
  gX EHAS
• I-gtR CKYI, CKYR, OK_KEYX, GRP, gX , EHAS,
  NIDP, IDi,, IDR, NI, NR,
• Ski Idi IDR Ni NR GRP gy
  gX EHAS

90
Aggressive Oakley Key Exchange
Notation

• I Initiator
• R Responder
• CKYi , CKYR Initiator, resonder, cookies
• OK_KEYX Key exchange message type
• GRP Name of Diffie-hellman group for this
  exchange
• gX , gy public key of initiator, responder
  gXy session key from this exchange
• EHAO, EHAS Encryption, hash, authentication
  functions, offered and selected
• NIDP Indicates encryption is not used for
  remainder of this message
• Idi , IDR Identifier for initiator, responder
• Ni , NR Random nonce supplied by initiator,
  responder for this exchange
• Skix, SKRX Indicates the signature over X
  using the private key(signing key) of
  initiator, responder

91
ISAKMP Formats Header and Generic
Payload Header

0
8
16
24
31
Bit
Initiator Cookie
Responder Cookie
Next Payload
Mj ver
Mn Ver
Exchange type
Flags
Message ID
Length
0
8
16
31
Bit
Reserved
Next payload
Payload length
92
ISAKMP format details

• The detailed description of the fields is left
  out as a home work exercise.