p2 prerequisites protocols and standardssecurity.hsr.ch › mse › lectures ›...

1

P2 Protocols, Technologies and Standards

• Secure network protocols for the OSI stack

P2.1 WLAN Security

• WPA, WPA2, IEEE 802.11i, IEEE 802.1X

P2.2 IP Security

• IPsec transport mode (host-to-host), ESP and AH

• IPsec tunnel mode (VPN), ESP and AH

• IPsec ESP payload

P2.3 Internet Key Exchange

• Security Associations

• IKEv1 Main Mode and Quick Mode

• IKEv1 Aggressive Mode

• IKEv2 IKE_SA_INIT, IKE_AUTH, and CREATE_CHILD_SA messages

• Advantages of IKEv2 over IKEv1

P2.4 Transport Layer Security

• Secure Sockets

• TLS record protocol

• TLS handshake protocol

• TLS session resumption

• SSL/TLS Versions

3

Network Layer Security (IPsec)

• Security by encryption/signature implemented in the Kernel.

• Difficult to make authentication data available to the application because

the IKE keying daemon runs as a separate process.

Transport Layer Security (SSL/TLS)

• Security by encryption/signature implemented in the Userland.

• Feasible to make authentication data available to the application,

e.g. via environment variables because the SSL/TLS handshake process

is integrated into the secure socket serving the application.

Application Layer Security (WS-Security)

• Security by encryption/signature implemented in the Userland.

• If the WS-Security layer is terminated by the application itself then all

authentication data is fully available.

6

IEEE 802.1x Port-Based Network Access Control

• IEEE 802.1x can be used for wireless authentication using a RADIUS server

for authenticating client credentials.

• IEEE 802.1x is a draft standard fo port-based network acess control, to provide

authenticated access for Ethernet networks. Port-based network access control

utilizes the physical characteristics of the switched LAN infrastructure in order to

provide a means of authenticating devices attached to a LAN port, and for

preventing access to that port in cases where the authentication process fails.

• A LAN port, also denoted as a Port Access Entity, can adopt one of two roles in

an access control interaction: supplicant or authenticator:

• The supplicant is a port that requests access to services accessible via the

authenticator's port.

• An authenticator is a port that enforces authentication before allowing access

to services accessible via that port.

• In addition, the authentication server performs the authentication function to check

the supplicant's credentials on behalf of the authenticator. It then responds to the

authenticator, indicating whether the supplicant is authorized to access the

authenticator's services. The authentication server may be a separate entity or

ist functions may be co-located with the authenticator.

Source: http://www.microsoft.com/hwdev/tech/network/wireless/IEEE802Net.asp

8

Authenticity of IP connections

• In order to prevent IP spoofing and connection hijacking, as well as to secure the

content of IP datagrams against any unauthorized modifications, all IP datagrams

sent over the Internet should be authenticated.

Privacy of IP connections

• In order to guarantee privacy, all IP datagrams sent over the Internet should be

encrypted by employing strong cryptography.

Encryption and Authentication

• Encryption without authentication is vulnerable to various attacks. Therefore

encryption must always be combined with authentication.

9

IP Authentication Header (AH)

• The IPsec AH Protocol is specified in RFC 4302.

• AH protects both IP header and IP payload against modifications by computing

a keyed message authentication code (MAC) over most octets of the IP datagram.

• Excluded from the cryptographic checksum are the following mutable header fields:

• Type of Service (TOS)

• Fragment Offset (always zero since AH is applied to non-fragmented packets, only)

• Flags

• Time to Live (TTL)

• IP header checksum

The above header fields could possibly get modified by intermediate routers

en-route from source to destination.

• The secured checksum is transmitted in the AH header, together with an arbitrary

32 bit Secure Parameters Index (SPI) uniquely identifying the Security Association

and a 32 bit Sequence Number preventing replay attacks.

• The AH header has the structure of an IPv6 extension header but can also be

carried over IPv4.

• Not only TCP and UDP but any transport layer protocol can be protected by AH.

The Protocol field in the original IP header is set to the decimal value 51,

designating the AH protocol and the Next Header field in the AH header carries

the original protocol number(e.g. 1 for ICMP, 6 for TCP, 17 for UDP), identifying

the transport layer payload carried in the IP datagram.

10

IP Encapsulating Security Payload (ESP)

• The IPsec ESP Protocol is specified in RFC 4303.

• ESP encrypts the transport payload of the IP datagram using a strong symmetric

encryption algorithm (IDEA, 3DES, AES, etc.).

• An ESP trailer is appended prior to encryption in order to align the payload data

to a 4-byte boundary required by the ESP packet format. It may also be used

to adapt the plaintext size to the block size of the block cipher (e.g. 64 bits for 3DES).

• Since IP packets could get lost, the encrypted payload is usually preceded by an

initialization vector (IV) that is used by the receiver to initialize the block cipher

algorithm used for the decryption of each IP payload.

• The ESP header has the structure of an IPv6 extension header but can also be

carried over IPv4. Similar to the AH header it contains a 32 bit Secure Parameters

Index (SPI) and a 32 bit Sequence Number.

• Any transport layer protocol can be encapsulated by ESP. The Protocol field in

the original IP header is set to the decimal value 50, designating the ESP protocol

and the Next Header field in the ESP header carries the original protocol number

identifying the transport layer protocol carried in the encrypted IP payload.

• Optionally the ESP payload can be authenticated by computing a keyed message

digest over the body of the IP datagram and appending the MAC value as

authentication data at the end of the encrypted payload. The IP header is not

included in the checksum and therefore is not protected.

• In the case of an IPsec transport mode application where besides encryption also

the protection of the IP header is required, the ESP and AH protocols can be

cascaded by first encrypting the original IP payload using ESP and then authenticating

both the original IP header and the ESP payload using AH.

11

Virtual Private Networks

• A Virtual Private Network (VPN) can be used by an enterprise to connect its subnets

or individual hosts located at various sites over shared public or semi-public

communication channels. Compared to dedicated leased lines a VPN solution can

offer significant cost savings without incurring any compromises regarding security

requirements.

• VPNs can be realised using the Layer 2 Tunneling Protocol (L2TP) defined by

the IETF or the now obsolete Point-to-Point Tunneling Protocol (PPTP).

Layer 2 tunnels are often transported over IP based networks using UDP as a

transport medium but emulating a link layer dial-in line from source to destination.

• An elegant and increasingly popular VPN solution is based on layer 3 mechanisms

using secure IP tunnels based on the IPsec protocol suite.

IPsec Tunnels

• Two enterprise subnets can be securely connected with each other over the public

Internet using an encrypted and authenticated IPsec tunnel. IP packets from a host

on the local subnet to a host on the remote subnet are forwarded to the local Security

Gateway (SG) which in turn tunnels the IP packets to the Security Gateway on the

remote end of the IPsec tunnel where they are delivered to the destination host.

The hosts belonging to the subnets are not aware of any security mechanisms. For

them the Security Gateways have the function of simple routers.

• The encapsulation provided by the IPsec tunnels allows the use of private network

addresses (e.g. 10.0.1.0/24 in one subnet and 10.0.2.0/24 in the second subnet)

which are normally not routable over the Internet.

13

ESP Overhead 3DES AES

• SPI 4 4

• Sequence Number 4 4

• IV 8 16

• Padding (worst-case) 7 15

• Pad Length / Next Header 2 2

• Authentication Data 12 12

-- --

IPsec Transport Mode 37 53 bytes

• Outer IP Header 20 20

-- --

IPsec Tunnel Mode 57 73 bytes

MTU 1443 1427 bytes

==== ====

Usually Path MTU discovery based on "fragmentation needed" ICMP messages"

automatically reduces the MTU from a standard LAN MTU of 1500 bytes down to

a payload data size that does not lead to fragmentation when the IPsec overhead is

added.

18

SA1i Suite of cryptographic proposals for the IKE SA

KEi Initiatior public factor for the Diffie-Hellman Key Exchange

Ni Initiator Nonce

SA1r Selection of a cryptographic proposal for the IKE SA

KEr Responder public factor for the Diffie-Hellman Key Exchange

Nr Responder Nonce

IDi Initiator ID

Certi Initiator Certificate (optional)

IDr Desired Responder ID (optional)

Authi Initiator Authentication (RSA, PSK, or EAP)

SA2i Suite of cryptographic proposals for the Child SA (ESP and/or AH)

TSi Initiator Traffic Selectors (subnets behind the Initiator)

TSr Responder Traffic Selectors (subnets behind the Responder)

IDr Responder ID

Certr Responder Certificate (optional)

Authr Responder Authentication (RSA, PSK, or EAP)

SA2r Selection of a cryptographic proposal for the Child SA (ESP and/or AH)

TSi Initiator Traffic Selectors (subnets behind the Initiator, optional narrowing)

TSr Responder Traffic Selectors (subnets behind the Responder, optional narrowing)

19

N Rekeying Notification (optional)

SAi Suite of cryptographic proposals for the Child SA (ESP and/or AH)

Ni Initiator Nonce

KEi Initiatior public factor for the Diffie-Hellman Key Exchange (optional PFS)


TSr Responder Traffic Selectors (subnets behind the Responder

SA1r Selection of a cryptographic proposal for the IKE SA

Nr Responder Nonce

KEr Responder public factor for the Diffie-Hellman Key Exchange (optional PFS)


TSr Responder Traffic Selectors (subnets behind the Responder

20

IKEv1 Standards

• RFC 2407: IPsec Domain of Interpretation for ISAKMP (IPsec DoI)

• RFC 2408: Internet Security Association and Key Management Protocol (ISAKMP)

• RFC 2409: Internet Key Exchange (IKE)

IKEv2 Standards

• RFC 4306: Internet Key Exchange (IKEv2) Protocol

• RFC 4555: IKEv2 Mobility and Multihoming Protocol (MOBIKE)

• RFC 4718: IKEv2 Clarifications and Implementation Guidelines

23

SSL/TLS Protocol Layer

• The Secure Sockets Layer (SSL) is inserted between the Transport layer

and the Application Layer (with communication layers defined according to

Tanenbaum!). In contrast to IPsec which is a Layer 3+ protocol based directly

on IPv4 or IPv6, SSL is a Layer 4+ protocol based directly on a TCP transport

mechanism.

• The SSL/TLS protocol offers secure sockets to SSL-aware applications.

The TCP/IP stack of the client and server platforms does not have to be modified!

• The SSL/TLS protocol is responsible for the following tasks:

- Fragmentation of application data streams into SSL/TLS PDUs

- Compression of PDUs before encryption

- Authentication of PDUs

- Encryption of PDUs

24

The TLS Record Protocol is sandwiched between a reliable Transport layer (that

means TCP and not UDP) and the Application layer. Though the TLS Handshake

Protocol is not really an application protocol, it sits above the TLS Record Protocol in

the stack, and its messages are encapsulated by the TLS Record Protocol.

A single TLS record may be up to 16384 bytes in length.

A TLS message may span multiple TLS records. A TLS certificate message may in

principle be as long as 16MB.

The TLS Handshake Messages allow the server and the client to authenticate each

other and to negotiate an encryption algorithm and cryptographic keys before the

application protocol transmits or receives its first byte of data. Thus, when a TLS client

and server first start communicating, they agree on a protocol version, select

cryptographic algorithms, optionally authenticate each other, and use public key

cryptography techniques to generate shared secrets. The TLS Handshake provides

the negotiated security parameters for the Application Message exchange.

The TLS Application Message exchange uses a keyed-hash MAC (Message

Authenticity Code), or HMAC, to protect the message's data integrity. An HMAC

algorithm takes a secret key and a message and generates a hash. (There are other

types of MAC algorithms.) Calculation of the HMAC with the same hash algorithm at

the recipient's end of the communication would detect tampering with the data. And,

because the recipient of the message with the MAC also has the secret key, the

recipient can verify authenticity of the message, which is the second feature included

in the RFC's term "reliable". This means that the message could only have been sent

by someone with the same key.

The record layer fragments information blocks into TLS Plaintext records (Record

PDUs) carrying data in chunks of 2^14 bytes or less. Client message boundaries are

not preserved in the record layer (i.e., multiple client messages of the same

ContentType may be coalesced into a single TLSPlaintext record, or a single

message may be fragmented across several records).

Application data is segmented into “Application Data Segments” and packed into

“Record PDUs”. The Application Data in the Record PDU may be compressed.

(However, compression is not often used.) Each PDU is integrity checked with a

keyed Message Authentication Code (MAC). Then the packet is padded to a length

which fits to the encryption scheme.

The padding data is added to force the length of the plaintext to be an integral

multiple of the block cipher's block length. The padding may be any length up to 255

bytes long, as long as it results in the TLSCiphertext.length being an integral multiple

of the block length. Each unit in the padding data vector must be filled with the

padding length value. Legal values range from zero to 255, inclusive. This length

specifies the length of the padding field itself.

Length: Length of Application data (excluding the protocol header, and the MAC

and padding trailers)

MAC: 20 bytes for the SHA-1-based HMAC, 16 bytes for the MD5-based HMAC.

Padding: Variable length ; last byte contains the padding length

25

26

TLS Handshake Protocol

• The TLS session state is controlled by the TLS handshake protocol that runs on

top of the TLS record layer. When a TLS client and a TLS server first start

communicating, they agree on a protocol version, select cryptographic algorithms,

optionally authenticate each other, and use public-key encryption techniques to

generate shared secrets.

• The client starts with a ClientHello message to which the server must respond

with a ServerHello message – otherwise a fatal error occurs and the connection

fails. The following attributes are established: Protocol Version, Session ID, Cipher

Suite, and Compression Method. Additionally, two random values are generated

and exchanged ClientHello-Random RC and ServerHello-Random RS.

• Next the server usually sends its X.509 server certificate in an optional Certificate

message. If no certificate is sent, then an optional ServerKeyExchange message

may be sent instead, containing the server part of a Diffie-Hellman (DH) secret.

If the server insists on a client side authentication an optional CertificateRequest

message is appended. The server indicates the end of the server hello phase by

sending a ServerHelloDone message.

• If the server has sent a CertificateRequest message, the client must send either

its X.509 client certificate in a Certificate message or a ‘no certificate‘ alert.

If the client has received a server certificate containing the server‘s public RSA

key, the client encrypts a randomly chosen premaster secret with it and sends it

to the server in a ClientKeyExchange message. Alternatively the clients can send

its part of a DH key exchange. Each side can now form a shared master secret.

• The client then emits a ChangeCipherSpec message announcing that the new

parameters have been loaded, followed by a Finished message already encrypted

with the new settings. The server does the same on its side.

• The encrypted exchange of application data can now be started.

Source: Stephen Thomas, SSL and TLS Essentials, Wiley Computer Publishing

27

Resuming a TLS Session

• When the client and server decide to resume a previous session or duplicate an

existing session (instead of negotiating new security parameters) the message flow

is as follows:

• The client sends a ClientHello using the Session ID of the session to be resumed.

The server then checks its session cache for a match. If a match is found, and the

server is willing to re-establish the connection under the specified session state, it

will send a ServerHello with the same Session ID value. Using the cached master

secret and the fresh client hello and server hello nonces, new session key material

is generated. At this point, both client and server must send change cipher spec

messages and proceed directly to the finished messages. Once the re-establishment

is complete, the client and server may begin to exchange application layer data.

If a Session ID match is not found, the server generates a new session ID and the

TLS client and server perform a full handshake.

Source: RFC 2246 – TLS Protocol Version 1.0

p2 prerequisites protocols and standardssecurity.hsr.ch › mse › lectures ›...

Documents