by Denis Trček

I've read this book as part of my IPI exam studies. It explains how some protocols security work. It's a bit out of date since protocols change every year. It gives, however, basic insight into network security and how to manage information system security.

Since it was read as part of my studies, I've taken some notes and combined with subjects presented in IPI slides and Wikipedia.

Feel free to read through my notes on the subject :)








work in progress ...

ISAKMP (Internet Security Association and Key Management Protocol)

• defines procedures and packet formats to establish, negotiate, modify and delete Security Associations (SAs)
  
• defines payloads for exchanging key generation and authentication data
• provides a consistent framework for transferring key and authentication data which is independent of the key generation technique, encryption algorithm and authentication mechanism

Each message consists of a header that is followed by at least one payload.

Header format

• initiator cookie - cookie of initiator, notification or deletion of SA
• responder cookie - null if first message
• next payload - first payload type in the message
• MjV, MnV - major and minor version of currently used ISAKMP
• exchange type - how keys will be exchanged
  • base type, identity protection, authentication only, aggressive type
• flags - indicators of specific options
• message ID - unique identifier
• length - total length of the message (header + payloads) in bytes

Payload format

• generic header

  • next payload - 0 for the last payload in the message, other values define the type of the following payload
  • reserved - for the future
  • payload length - length of the payload (including generic header) in bytes

• payload

Payload types

• Security association (SA) payload
  • parameters: interpretation domain, situation
  • negotiation of security parameters for a SA
• Proposal (P) payload
  • parameters: serial number, protocol ID, security parameter indicator (SPI), SPI size, number of transforms (cryptographic algorithms), transforms statement
  • used in SA negotiation phase
  • indicates whether ESP or AH is going to be used with this SA
• Transform (T) payload
  • parameters: transform ID, security association attributes
  • for security association and transforms negotiation
• Key exchange (KE) payload
  • parameters: data for key exchange
  • support for various key exchange techniques
• Certificate (CERT) payload
  • parameters: certificate encoding type (X.509, PHP, SPKI), certificate
  • used for transportation of digital signed certificates and other relevant information
• Certificate request (CR) payload
  • parameters: certificate type, number of certificates, certificates, number of CAs and CAs
  • provides means to request certificates
• Hash payload
  • contains hash values of the message
  • assures integrity
  • serves to authenticate entities during negotiation
• Signature (SIG) payload
  • parameters: digital signature
  • uses the same data as hash payload
  • data is signed - non-repudiation
• Identification (ID) payload
  • parameters: identification and types of data
  • used for identification (e.g. IP number)
• Nonce payload
  • serves to protect against replies
• Notification payload
  • parameters: interpretation domain (DOI), protocol ID, security parameters index (SPI), SPI size, notification type, notification data
  • serves to transmit informational data (errors, status ...)
• Deletion (D) payload
  • parameters: DOI, protocol ID, quantity and size of SPI, SPIs
  • SAs that the sender has deleted from its database and are invalid

ISAKMP types

• Base exchange
  • simultaneous key and authentication material exchange
  • first two messages use cookies and establish an SA with agreed protocol and transforms; both use nonces to prevent replay attacks
  • last two messages exchange keys, user IDs, payload for authentication of keys, IDs and nonces from first two msgs
  • provides no identity protection
  • requires only four exchanges
• Identity protection exchange
  • first two messages establish the SA
  • second two perform key exchange (prevention of replays trough use of nonces)
  • computation of secret session key
  • encrypted messages are exchanged enabling authentication
• Authentication only exchange
  • provides mutual authentication
  • no key exchange
  • first two messages establish SA
  • responder transfers its ID in second message (this one is authenticated)
  • in the third message initiator transmits its authenticated ID
• Aggressive exchange
  • minimal number of exchanges
  • does not provide identity protection
  • initiator proposes an SA, protocol and transforms and provides its ID in first message
  • responder indicates its acceptance of SA with a particular protocol and transform, completes key exchange and authenticates transferred data
  • initiator transmits authentication result encrypted with the session key
• Informational exchange
  
  • one way communication
  • data convey for SA management

Secure Socket Layer - SSL

Secure Sockets Layer (SSL) is predecessor of Transport Layer Security (TLS).

Cryptographic protocol that provides secure communications on the Internet for such things as web browsing, e-mail, Internet faxing, instant messaging and other data transfers. There are slight differences between SSL and TLS, but they are essentially the same.

Session

Session can contain multiple connections that are identified by cryptographic parameters - that enables more efficient deployment (negotiation and creation of cryptographic parameters are resource consuming tasks).

Typically, only the server is authenticated while the client remains unauthenticated; this means that the end user can be sure with whom it is communicating.

Session state is defined by:

• session identifier (byte sequence chosen by a server)
• peer certificate (X.509)
• compression algorithm (compression usually applied before encryption)
• cipher specification (defines session encryption) and calculation details for MACs
• 48 bytes master secret shared between client and server
• flag indicating session ability to initiate new connection (is resumable)

SSL connection state is defined by:

• random sequence chosen by the server and client (for each conn)
• server secret key used for MACs computation (sent to the client)
• client secret key used for MACs computation (sent to the server)
• server write key - symmetric data encryption key used by the server
• client write key - symmetric data encryption key used by the client
• initialization vectors for block ciphers - used in a chaining mode
• sequence numbers - on the interval between 0 and 2^64-1

Simple TLS handshake

1. client sends a ClientHello message
   - specifying the highest TLS protocol version it supports,
   - a random number,
   - a list of suggested cipher suites and
   - compression methods
2. server responds with a ServerHello message
   - containing the chosen protocol version,
   - a random number,
   - cipher suite,
   - compression method from the choices offered by the client
   The server may also send a session id as part of the message to perform a resumed handshake.
3. server sends its Certificate message
   - depending on the selected cipher suite, this may be omitted by the server
4. server sends a ServerHelloDone message
   - indicating it is done with handshake negotiation
5. client responds with a ClientKeyExchange message
   - contains a PreMasterSecret, public key, or nothing - Again, this depends on the selected cipher
6. client and server compute common secret - "master secret" using random numbers and PreMasterSecret
   - all other key data is derived from this master secret (and the client- and server-generated random values)
7. client now sends a ChangeCipherSpec record
   - this is telling the server, "Everything I tell you from now on will be encrypted."
   - note that the ChangeCipherSpec is itself a record-level protocol
8. client sends an encrypted Finished message
   - containing a hash and MAC
9. server will attempt to decrypt the Client's Finished message, and verify the hash and MAC
   - if the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down
10. server sends a ChangeCipherSpec and its encrypted Finished message
    - client performs the decryption and verification
11. "handshake" is complete and the Application protocol is enabled
    - application messages exchanged between Client and Server will be encrypted

SSL Handshake

• meant for client - server authentication and verification
• before any application data is exchanged
• steps 1-7

SSL Change Cipher Spec

• simplest protocol in SSL family
• copies pending state in the current state
• steps 7-11

SSL Record

• provides operational confidentiality and message integrity
• operating steps
  1. application data fragmentation (and lossless compression is applied)
  2. MAC is calculated over shared secret key, padding bits, sequence number, higher level protocol, length of compressed fragment and compressed fragment itself
  3. encryption is applied
  4. SSL Record header is prepared (to enable inverse operation)
• SSL Record header fields
  - major and minor version of SSL protocol
  - higher level protocol being served by SSL
  length of the fragment

SSL Alert

• used to signal alerts to the peer entity
• each message consists of two bytes (first is meant for alert type, second holds additional info)
• alerts can be
  - warnings
  - fatal errors (SSL terminates connection, other connections can continue, but new ones cannot be created)

Secure / Multipurpose Internet Mail Extension - S/MIME