Datakommunikasjon Høsten 2001 Forelesning nr 12, 12. november 2001 Repitisjon + IPSec

Pesumliste Legges ut på kursets hjemmeside denne uken

Kommunikasjonslagene (referert til OSI) Internet-TCP/IP Application Application FTP HTTP SMTP DNS Presentation Session Transport Transport TCP UDP ICMP Network Network IP ARP Data Link Data Link PPP Physical Ethernet

IP Header Eksempel Version IHL Type of Service Total length RFC791 IP Header Version IHL Type of Service Total length DF MF Identification Fragment Offset Time to Live Protocol Header Checksum Source Address Destination Address Options Eksempel

TCP - Transmission Control Protocol TCP Header Source Port Destination Port Sequence Number Acknowledge Number Header Length U R G ACK P S H R S T S Y N F I N Reserved Window Size TCP Checksum Urgent Pointer Options

TCP - Sekvens opp- /nedkobling SYN THREE WAY HANDSHAKE SYN, ACK ACK - Data - FIN ACK HALF CLOSE FIN ACK

UDP - User Datagram Protocol UDP Header Source Port Destination Port UDP length UDP length = lengden av hele datagrammet UDP checksum UDP checksum = sjekksum av hele datagrammet

SMTP Mail Flyt

User Agent (mail program) Lese og sende mail Opsjoner: Videresending til andre Svarsfunksjon Filtrering av innkommende mail til ulike mail bokser Signatur fil Adresslister, aliases

Mail Transfer Agent (MTA) Ansvarlig for å sende mailen gjennom nettet Baseres på SMTP (Simple Mail Transfer Protocol) SMTP er en enkel ASCII protokoll Benytter TCP og port 25 for å opprette en forbindelse mellom to MTA-er

Sammensetning av en mail Envelopes Brukes av Message Transfer Agent Headers Brukes av User Agent Body Innholdet i mailen (tekst og vedlegg)

SMTP-kommandoer (RFC 821) HELO <sending-host> MAIL FROM: <from-address> RCPT TO: <to-address> DATA <tekst>. QUIT

MX-records Brukes for å fortelle omverdenen om hvem som er mail server Del av DNS (Domain Name System) MX-recorden for en domene forteller i prioritert rekkefølge hvor mailen skal sendes

POP 3 Post Office Protocol number 3 Protokoll for å hente mail fra mail server til en mail klient (f.eks Outlook eller Eudora) Bruker TCP og port 110 Baserer seg på enkle ASCII kommandoer

Internet Message Access Protocol - IMAP Mail klient Tilsvarende som POP3, men all behandling av mail foregår på mailserveren POP3 henter mailen ned til User Agent

MIME – Multipurpose Internet Mail Extension Utvidelse av SMTP for å kunne overføre filer som ikke er 7-bit ASCII MIME informasjon i mail: MIME-Version Content-Type Content-Transfer-Encoding (Content-Description) (Content-ID)

MIME – Content Type Text Image Audio Application (Word, Postscript, ) Multipart (Mixed, alternative)

MIME – Content-transfer encoding Forteller hvordan innholdet av mailen er kodet Fem forskjellige kode formater er definert 7 bits ASCII Quoted Printable base64 8 bits som inneholder linjer binær koding, 8 bit data uten linjer

Quoted Printable 7 bit ASCII med alle karakterer <33 og >127 kodes som likhetstegn + verdien av tegnet som to hexadecimale tegn eks. bokstaven ”å” kodes som =E5 Karakteresettet ISO-8859 gir å=229 desimalt 229=11100101 1110=E 0101=5 ”å” kodes som =E5

Base 64 Encoding

Base 64 transfer encoding Tre bytes med data kodes som fire 6 bits karakterer Orginale data: Hi! H i ! 01001000 01101001 00100001 (24 bit) 010010 000110 100100 100001 00010010 00000110 00100100 00100001 18 6 36 33 (desimalt) S G k h Datamengden øker med 25% Inneholder ikke kontrollkarakterer Se tabell 19.9 Radix-64 Encoding side 725

MIME eks. Word fil som vedlegg MIME-Version: 1.0 Content-Type: multipart/mixed; Content-Type: text/plain; charset="iso-8859-1" Content-Type: application/msword; Content-Transfer-Encoding: base64

Hypertext Transfer Protocol HTTP Benyttes av WWW Protokoll for overføring av HTML Kan overføre tekst, lyd, bilder osv. Transaksjonsorienter klient/tjener protokoll Vanligvis mellom en Web browser (klient) og Web server (tjener) Benytter TCP Tilstandsløs Hver transaksjon behandles separat (Keep-Alive) En ny TCP forbindelse for hver transaksjon Terminerer forbindelsen når transaksjonen er komplett

HTTP eksempel (GET) (REQUEST METODE) Line 1: GET / HTTP/1.1 (REQUEST HEADER PARAMETER) Line 2: Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */* Line 3: Accept-Language: en Line 4: Accept-Encoding: gzip, deflate Line 5: If-Modified-Since: Wed, 26 Sep 2001 09:30:23 GMT Line 6: If-None-Match: "502728de6d46c11:1c8e” Line 7: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4. 0; TUCOWS) Line 8: Host: intranett.halden.scandpower.no (GENERAL HEADER FIELD) Line 9: Connection: Keep-Alive

HTTP eksempel (response) Line 1: HTTP/1.1 200 OK Line 2: Server: Microsoft-IIS/4.0 Line 3: Date: Sun, 04 Nov 2001 16:20:09 GMT Line 4: Content-Type: application/x-javascript Line 5: Accept-Ranges: bytes Line 6: Last-Modified: Fri, 02 Nov 2001 13:58:51 GMT Line 7: ETag: "80f66b80a663c11:1c8e" Line 8: Content-Length: 14481

Telnet og Rlogin Innlogging fra en maskin til en annen over nettet Benytter seg av klient-tjener begrepet Telnet er en standard applikasjon som er implementert i alle TCP/IP applikasjoner Rlogin kommer fra Berkley Unix og ble utviklet for pålogging mellom to Unix systemer Telnet er mer kompleks enn Rlogin

FTP (File Transfer Protocol) Internett standard for filoverføring FTP protokoll Kontroll forbindelse Server gjør en ”passive open” på port 21 Klient gjør en ”active open” til port 21 Data overføres fra port 20 på FTP serveren

DNS - Domain Name System RFC1034, RFC1035 Mapper mellom hostnavn og IP-adresse (og omvendt) Benyttes av TCP/IP applikasjoner Distribuert, hierarkisk Benytter både TCP og UDP som transport, port nummer 53 Eksempler DNS Query DNS Reply hostnavn = (subdomain name +) domain name URL: <protokoll>://<domain name>/<filnavn (inkl. directories)>

DNS - Domain Name System RFC1034, RFC1035 Distribuert Ingen navneserver har lagret all informasjon Et nett (firma, organisasjon o.l) har en eller flere navneservere Inneholder hele eller deler av egne definisjoner Håndterer også forespørsler utenfra Hierarkisk Hvis egen server ikke har nødvendig informasjon, sendes forespørselen til nivået over Et overliggende nivå vil gjenkjenne nok til å kunne velge underliggende nivå for forespørsel. Skal ha mer enn en navneserver som dekker samme område, en primary og en eller flere secondaries.

DNS - Domain Name System RFC1034, RFC1035 Unnamed root COM EDU GOV MIL NET ORG ARPA AE NO ZW Top Level Domains IN-ADDR 36 136 69 196 YAHOO PEOPLE NO SCANDPOWER WWW Second Level Domains .gov og .mil er reservert for USAs myndigheter og militære Generic Domains Country Domains ARPA - Special Domain for address-to-name mappings

DNS - Domain Name System RFC1034, RFC1035 Resultat fra en ekstern forespørsel kan lagres i lokal navneserver til senere bruk En DNS respons vil inneholde informasjon om kilden er autoritativ eller ikke. DNS-record inneholder: Name - domain name TTL - hvor lenge man kan ha denne recorden cashed Class - IN the Internet system Type - A Host adresse - CNAME Canonical name, et alias - HINFO kommentarfelt (CPU og OS for maskinen) - MX Mailserver for domenet - NS Autoritativ navneserver for domenet - PTR Peker til annen del av navneområdet - SOA Starten på en - WKS Well Known Services; hvilke tjenester som er tilgjengelige for denne maskinen Rdata Avhengig av ‘Type’ (IP-adresse, domenenavn eller hostnavn).

DNS Resource Records A: navn til IP-adress mapping PTR: IP-adresse til navn mapping (reverse lookup) CNAME (Canonical name) Alias for et annet navn f.eks. Intranett = lou.halden.scandpower.no MX Mail Excange Record NS Name Server record

Sikkerhet Autentisering (identifikasjon) Aksesskontroll (aksess til ressurser) Konfidensialitets (informasjon holdes hemmelig) Integritetstjeneste (data skal være korrekte) Tilgjengelighet (informasjonen skal være tilgjengelig for de som er autorisert) CIA – Confidentiality Integrity Availability

Symmetrisk kryptering Alice Bob Secret Key Cleartext Ciphertext Cleartext Encryption Algorithm Encryption Algorithm Encipher Decipher BOB og ALICE benytter samme hemmelige nøkkel

Another Key to Encipher Asymmetrisk kryptering BOB benytter ALICE sin offentlige nøkkel ALICE benytter sin private nøkkel Alice Bob One Key to Encipher Another Key to Encipher Cleartext Ciphertext Cleartext Encryption Algorithm Encryption Algorithm Encipher Decipher BOB og ALICE benytter forskjellige nøkler

Krypteringsalgoritmer Symmetriske: DES (Data Encryption Standard) RC2 IDEA CAST BLOWFISH Public-Key (assymetriske) RSA ELGAMAL

HASH funksjon En hash funksjon tar som input en vilkårlig melding med variabel lengde Output er alltid en melding med fast lengde SHA-1 (Secure Hash Function) Output er alltid 160 bit MD5 (Message Digest no 5) Output er alltid 128 bit

Krav til HASH funksjon Må kunne benyttes på en datablokk av vilkårlig størrelse Må produsere en melding med fast lengde uavhengig av lengden av input Det må ikke være mulig å gjenskape den opprinnelige teksten basert på resultatet av hash funksjonen To forskjellige meldinger må ikke kunne gi samme resultat fra hash funksjonen

Melding sendt til Alice En veis hash (1) Bob Tekst Hash Algoritme Digest Tekst Melding sendt til Alice Digest

En veis hash (2) Alice Mottatt tekst Digest Hash Algoritme Digest Hvis Digest = Digest Mottatt tekst OK! Sikrer integritet, dvs at teksten ikke er endret under overføring

Autentisering Message Authentication Code Hvordan vet Alice at meldingen kommer fra Bob ? Bob kombinerer hash funksjonen med symmetrisk eller asymmetrisk kryptering (Hash + kryptering) Resultat = MAC, Message Authentication Code Hash Algorithm + Secret key

Secret key Autentisering (Felles hemmelig nøkkel) Bob Melding + Secret key Hash Algorithm MAC In the case of a secret key cryptography used for authentication, the message is concatenated with the secret key, and the hash function is applied to this concatenation. The result of this operation is the Message Authentication Digest. Melding Melding som sendes Alice MAC

Secret key Autentisering (Felles hemmelig nøkkel) Alice Melding + Melding MAC Secret key Hash Algorithm MAC Once Alice receives the authenticated message, she reapplies the hash function to the concatenation (message + secret key). She compares the recalculated MAC to the MAC calculated by Bob. If the results agree, the secret key used by the sender is the same as that used by Alice for recalculating the MAC. The message was therefore truly sent by Bob. = Hvis MAC MAC OK !

Public key Autentisering (signatur, bruk av privat og offentlig nøkkel) Bob Encryption Bob’s Private key Tekst Hash Algorithm Digest *  ^1 ’ In the case of public key cryptography, the message digest calculated by Bob is ciphered with his secret key. The MAC obtained, which takes the name of digital signature, is joined to the message. Tekst Melding sent til Alice *  ^1 ’

Public key Autentisering (signatur, bruk av privat og offentlig nøkkel) Alice Tekst *  ^1 ’ Hash Algorithm Digest Hvis = Decryption Bob’s Public key OK ! Alice receives the signed message; she recalculates the digest, and deciphers the signature with Bob’s public key. If the two digests agree, the signature received was truly calculated with Bob’s private key. Bob really is the sender of the message. Digest

IPSec – IP Security Sikkerhetsmekanisme for beskyttelse av VPN VPN – Virtual Private Network VPN over Internett Mellom avdelingskontorer Mellom hjemmekontor og jobb Mellom leverandør og kunde

IPSec sikkerhetstjenester Konfidensialitet Informasjonen krypteres Integritet En veis hash funksjon Autentisering MAC (hash + hemmelighet) Digital signatur

To sikkerhetsprotokoller AH (Authentication Header) RFC2402 Data Integritet Autentisering ESP (Encapsulating Security Payload) RFC 2406 Konfidensialitet

To former for IPSec : Transport and Tunnel Mode Transport Mode IP Header Data Original IP Header IPSec Header Data Tunnel Mode Optional Encryption Outer IP Header Inner IP Header New IP Header IPSec Header Original IP Header Data Optional Encryption

Eksempel : Transport Mode IPSec Host IPSec Host Internet Untrusted Network IPSec Data IP Header Transport Mode in only applicable to Hosts. It is not available for Security Gateways. When a Security Gateway works in Transport Mode, it acts as a host : the traffic is destined to itself. In transport mode, the IPSec header is inserted after the IP header and before an upper layer protocol (e.g., TCP, UDP, ICMP, etc).

Eksempel : Tunnel Mode IPSec System IPSec System Internet Untrusted Network IP Header IPSec Data Tunnel Mode is applicable to Hosts and Security Gateways. Security Gateways only support tunneled mode. The outer IP source and destination addresses identify the "endpoints" of the tunnel. The inner IP source and destination addresses identify the original sender and recipient of the datagram. IP tunneling mode allows to use public IP addresses in the new outer IP header, while the existing private IP addresses of the original packet are maintained. The new packet is routed in the Internet according to the outer public address ; the public IP header is then deleted by the IPSec Gateway and the original packet is routed in the intranet according to the private IP header. The original IP datagram is not changed at the end of the tunnel except the TTL field that is decremented, and the Checksum field that is recomputed because of the TTL change.

Beskyttelse avhengig av “Mode” og Protokoll AH ESP Authentication / Integrity Encrypted Tunnel Mode New IP Header AH Original IP Header New IP Header ESP Original IP Header Authentication / Integrity Authentication / Integrity Encrypted Original IP Header Header AH Original IP Header Header ESP Transport Mode With IPSec tunneled mode : If AH is employed, the outer IP header is protected (authenticated), as well as the entire original IP packet. In case of ESP, the protection is afforded only to the tunneled IP packet, not to the new outer IP header. With Transport Mode : If AH is used, the original IP header and the data payload are protected (authenticated). If ESP is employed, no protection is afforded to the IP original header, but data payload are authenticated and may be encrypted. To sum up, ESP do not protect the outer IP header, AH protects the entire IP datagram (including the outer IP Header, and except mutable fields, such as TTL and Checksum) but do not offer encryption services. Authentication / Integrity

Authentication Header (AH) IP Header AH Payload 8 bits Next Header Payload Length Reserved Security Parameters Index (identifiserer SA) Sequence Number (Antireplay) The Protocol Type of the outer IP header contains the value 51. Next Header : 8 bits field containing the next payload type after the AH Header Payload Length : 8 bits field containing the length of the AH header Reserved : Field reserved for future use Security Parameter Index (SPI) : Arbitrary 32-bit value that, in combination with the destination IP address (outer header) and the security protocol, uniquely identifies the Security Association for this datagram. The SPI value is selected by the destination systemat the SA establishment. The values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use. Sequence Number : 32-bit field containing an increasing counter value. It is mandatory and is always present even if the receiver does not choose to enable the anti-replay service. The Sequence Number is initialized to 0 when the SA is established. Then the first packet will have a Sequence Number of 1. Authentication Data : Variable length field containing the Integrity Check Value (ICV). The algorithm used to compute the ICV is specified by the Security Association. A compliant implementation must support HMAC-MD5 and HMAC-SHA-1 algorithm. The ICV is computed over : the immutable or predictable fields of the outer IP header (Version, IP Header Length, Total Length, Identification, Protocol, Source and Destination Address) ; mutable fields are set to 0 (TOS, Flags, Fragment Offset, TTL, Header Checksum). the AH header (with the field Authentication Data set to 0) the upper level protocol data inserted after the AH header. Authentication Data (resultat av f.eks HMAC-MD5) 32 bits

Encapsulating Security Payload (ESP) IP Header ESP Header Payload ESP Trailer ESP Auth Security Parameters Index (SPI) Sequence Number Authentication Payload Data Encryption Padding Pad Length Next Header Authentication Data (variable size) The Protocol Type of the outer IP header contains the value 50. Security Parameter Index (SPI) : Arbitrary 32-bit value In combination with the destination IP address (outer header) and security protocol (AH), it uniquely identifies the Security Association for this datagram. The SPI value is selected by the destination system at the SA establishment. The values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use. Sequence Number : 32-bit field containing an increasing counter value It is mandatory and is always present even if the receiver does not choose to enable the anti-replay service for a particular SA. The Sequence Number is initialized to 0 when the SA is established. Then the first packet will have a Sequence Number of 1. Payload Data : Data included in the original IP packet If the encryption service is selected, and if the encryption algorithm requires cryptographic synchronization, an Initialization Vector (IV) is included at the beginning of the Payload Data field. Padding : Some encryption algorithm requires the plaintext to be a multiple number of a block size. The padding is then used to fill the plaintext until it reachs an appropriate size. The plaintext consist of the Payload Data, the Pad Length, and the Next Header fields. Pad Length : Size in number of byte of the Padding field Next Header : 8 bits field containing the type of data in the Payload Data field Authentication Data : Optional variable length field containing the Integrity Check Value (ICV). The field is present only if the authentication service is specified by the SA. The algorithm used to compute the ICV is specified by the Security Association. A compliant implementation must support HMAC-MD5 and HMAC-SHA-1 algorithm. The ICV is computed over the ESP packet minus the Authentication Data field : SPI Sequence Number + Padding + Pad Length + Next Header. If the encryption service is selected, the last 4 fields are in cyphertext form, as the encryption is applied before authentication. 32 bits 8 bits

SA- Security Association SA = All informasjon som trengs for å etablere en sikker forbindelse Valg av sikkerhetsmekanismer: ESP or AH beskyttelse Krypteringsalgoritme Hash funksjon Valg av autentiseringsmetode Autentisering av partene Valg av krypterings- og autentiseringsnøkler

Security Databases To Security Databases ifm IPSec Security Association Database (SAD) Benyttes på en allerede oppsatt forbindelse Security Policy Database (SPD) Definerer den policy som skal benyttes mellom f.eks to subnett, eller to IP-adresser.

SAD - Security Association Database For hver SA (Security Association): Identifier : Outer destination IP-address Security Protocol (AH eller ESP) SPI (Security Parameter Index) Parameters Authentication algorithm and keys Encryption algorithm and keys Lifetime (hvor lenge kryptonøklene er gyldige) Security Protocol Mode (tunnel or transport) Anti-replay service (sekvensnummer)

SPD - Security Policy Database Hver regel inneholder: Selectors: Destination IP Address Source IP Address Name Transport Layer Protocol (protocol number) Source and Destination Ports The policy : Discard the packet, bypass or process IPSec For IPSec Processing : Security Protocol and Mode Enabled Services (anti-replay, authentication, encryption) Algorithms (for authentication and/or encryption)

Security Association Etablering Security Associations forhandles: Manuelt IPSec kun mellom et lite antall maskiner Automatisk Skalerer bra Automatisk forhandling om SA er spesifisert i: ISAKMP RFC 2408 IKE (Internet Key Exchange) RFC 2409

Automatisk SA forhandling IKE definerer to faser: Fase 1 : Etablering av en sikker forbindelse mellom partene Kalles ISAKMP Security Association ISAKMP SA negotiation Nøkkelutveksling Autentisering Fase 2 : IPSec SA forhandling i ISAKMP kanalen som ble etablert i fase 1

Internet Key Exchange Fase 1: Fase 2 Main mode To meldinger for algoritmer og autentiseringsmetoder To meldinger for utveksling av offentlige Diffie-Hellman nøkler To meldinger for autentisering Aggressive mode (raskere enn Main mode) Ingen beskyttelse av autentiseringen Fase 2 Quick mode Oprettelse av IPSec SA

Diffie-Hellman: Nøkkelutvekslingsprotokoll Protokoll som benyttes til å utveksle en DH hemmelig nøkkel mellom partene Denne nøkkelen benyttes så til symmetrisk kryptering Symmetrisk kryptering er 100 ganger raskere i SW og 1000 ganger raskere i HW enn asymmetrisk kryptering

Diffie-Hellman DH private key Bob’s DH public key Alice’s DH DH Secret key

Cisco - IPSec inbound ESP SA: spi: 0x62910BD(103354557) transform: esp-des esp-sha-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2000, flow_id: 1, crypto map: telenor-map sa timing: remaining key lifetime (k/sec): (4607999/2780) IV size: 8 bytes replay detection support: Y outbound ESP SA: spi: 0x217B2368(561718120) transform: esp-des esp-sha-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2001, flow_id: 2, crypto map: telenor-map sa timing: remaining key lifetime (k/sec): (4607999/2780) IV size: 8 bytes replay detection support: Y

IPSec og brannmurer IPSec AH - IP protocol ID 51 IPSec ESP - IP protocol ID 50 IKE - UDP port 500