Outline. Internet Security Protocols. Internet Evolution. Internet Standardization. IETF Intermediate documents. IETF Standards.

Transcription

1 Outline Internet Security Protocols Bart Preneel June 2003 With thanks to Joris Claessens and Walter Fumy Preliminaries: Internet protocols, PKI, X.509, Encoding Application layer security ( ) PGP, S/MIME Transport layer security SSL / TLS Network layer security IPSec, VPN, SSH 2 Internet Evolution Internet Standardization Number of Internet Users in Millions ,1 TCP/IP HTML WWW WAP mobile business XML Electronic e-commerce Business Experts Armed Forces Universities ISOC/IAB/IESG/IETF Internet Engineering Task Force (IETF) IETF Working Groups Mailing List Information Scope of the Working Group Goals and Milestones Current Internet Drafts & RFCs RFCs ftp://ftp.isi.edu/in-notes/ IETF Standards IETF Intermediate documents Proposed Standard (PS) stable spec lowest level of standards track Draft Standard (DS) at least two independent and interoperable implementations Standard (STD) widely, successfully used Experimental Proposed Draft std Standard Historic Request for Comments (RFCs) with different maturity levels Experimental (E) Informational (I) Historic (H) Best Current Practice (BCP) Internet-Drafts (I-D) are working documents of the working groups and have no formal status Protocol Status (requirement level) "required", "recommended", "elective", "limited use", or "not recommended must and should 1

2 IETF Security Area (1) Area Directors: Jeffrey Schiller & Marcus Leech An Open Specification for Pretty Good Privacy (openpgp) Authenticated Firewall Traversal (aft) Common Authentication Technology (cat) IP Security Policy (ipsp) IP Security Protocol (ipsec) IP Security Remote Access (ipsra) Intrusion Detection Exchange Format (idwg) Kerberized Internet Negotiation of Keys (kink) Kerberos WG (krb-wg) Multicast Security (msec) IETF Security Area (2) Area Directors: Jeffrey Schiller & Marcus Leech One Time Password Authentication (otp) Public-Key Infrastructure (X.509) (pkix) S/MIME Mail Security (smime) Secure Network Time Protocol (stime) Secure Shell (secsh) Securely Available Credentials (sacred) Security Issues in Network Event Logging (syslog) Simple Public Key Infrastructure (spki) Transport Layer Security (tls) Web Transaction Security (wts) XML Digital Signatures (xmldsig) SMTP HTTP TCP/UDP IP Link... Internet Protocols Application Transport Network SMTP HTTP TCP/UDP Network Layer Internet Protocol (IP) Transport Layer Transmission Control Protocol (TCP), User Datagram Protocol (UDP) IP Link... Security Protocols & Services Cryptographic techniques typically utilized by a Security Protocol (unilateral or mutual) entity authentication mechanisms symmetric encipherment message authentication mechanisms key establishment mechanisms (e.g., combined with entity authentication) SP hdr data SP tlr MAC confidentiality integrity 10 Internet Security Protocols Electronic Commerce Layer SET, Ecash,... SP Architecture II: Session (Association) Establishment S-HTTP PGP PEM S/MIME PKIX Host A SP hdr encrypted data MAC Host B Transport Layer Security (SSH, SSL, TLS) SPKI Transmission Control Protocol User Datagram Protocol (UDP) (TCP) IP/ IPSec (Internet Protocol Security) Public -Key Infrastructure Security Associations (Security Parameters incl. Shared Keys) security services depend on the layer of integration: the mechanisms can only protect the payload and/or header information available at this layer Key Management and Security Association Establishment Protocols header information of lower layers is not protected!! 12 2

3 Note on export restrictions Public Key Infrastructure cryptography is weapon or dual use good thus should be export -controlled allow only short keys Until 1997: 40-bit: symmetric encryption 512-bit: asymmetric encryption Since September 2000 less restrictions, evolution towards no restrictions X.509: ITU/T standard basis for the IETF PKIX working group latest major release in 95 (v3) Certification Authorities (CA) = Trusted Third Parties (TTP), that warrant the link between a person and their public key Alternatives: SPKI/SDSI (IETF) PGP between civilized nations X.509 certificate v1 X.509 certificate v2 Version number Serial number Signature algorithm Issuer name Validity period Subject name Subject public key Signature of the CA 15 Idem + Issuer unique identifier Subject unique identifier Directory Access Control 16 X.509 certificate v3 Typical X.509 solution Idem + Extensions (each one can be critical): Alternative naming More info about the key Other identification data CRL location information Directory System Card Issuing System Registration Authority Certification Authority Key Recovery Authority Server Components Local Registration Authority Notarization Authority Administration Components PKI User Agent Client Timestamping Authority

4 Encoding Abstract Syntax Notation.1 (ASN.1) Distinguished Encoding Rules (DER) ftp://ftp.rsa.com/pub/pkcs/ascii/layman.asc Also Basic Encoding Rules (BER) Base64 format (also PEM format) ASN.1 definition certificate Certificate ::= SIGNED { SEQUENCE { version [0] Version DEFAULT v1, serialnumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectpublickeyinfo SubjectPublicKeyInfo, issueruniqueidentifier [1] IMPLICIT UniqueIdentifier OPTIONAL, -- if present, version must be v2 or v3 subjectuniqueidentifier [2] IMPLICIT UniqueIdentifier OPTIONAL -- if present, version must be v2 or v3 extensions [3] Extensions OPTIONAL -- If present, version must be v3 }} Version ::= INTEGER { v1(0), v2(1), v3(2) } CertificateSerialNumber ::= INTEGER AlgorithmIdentifier ::= SEQUENCE { algorithm ALGORITHM.&id ({SupportedAlgorithms}), parameters ALGORITHM.&Type OPTIONAL } Validity ::= SEQUENCE { notbefore Time, notafter Time } SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectpublickey BIT STRING } (etc) DER encoded certificate ee cf 30 0d W a f7 0d c4 31 0b *.H a U...ZA c e U...Western Ca pe1.0...u...cap f 77 6e 31 1d 30 1b a 13 e Town1.0...U f 6e c Thawte Consulti e b 13 1f ng cc1(0&..u f 6e Certification Se f 6e 31 rvices Division1 000a U...Thawte 000b Server CA1&0$.. 000c0 2a f7 0d *.H...serve 000d0 72 2d e 63 [email protected] 000e0 6f 6d 30 1e 17 0d om f a 17 0d Z a b8 31 0b Z U e BE1.0...U...Bra e f 30 0d c bant1.0...u...l e a 13 0a euven1.0...u b 2e 55 2e 4c e K.U.Leuven b 13 0a f 43 4f U...ESAT/COSIC d e 63 6f &0$..U e e 6b 75 6c sic.esat.kuleuve e 2e e a n.ac.be1402..*.h f7 0d d b 2e e...%mark.van 001a e e 6b [email protected] 001b0 75 6c e 2e e f uleuven.ac.be c0 30 0d a f7 0d *.H... (only first part of certifcate fits on 1 slide ) 00 A 17 R 34 i 51 z Base64 01 B 18 S 35 j C 19 T 36 k D 20 U 37 l E 21 V 38 m F 22 W 39 n G 23 X 40 o H 24 Y 41 p I 25 Z 42 q J 26 a 43 r K 27 b 44 s L 28 c 45 t M 29 d 46 u 63 / 13 N 30 e 47 v 14 O 31 f 48 w (pad) = 15 P 32 g 49 x 16 Q 33 h 50 y (1) * 0x30 0x82 0x M 08 I 08 I 02 C Base64 encoded certificate -----BEGIN CERTIFICATE----- MIIC7jCCAlcCAhLPMA0GCSqGSIb3DQEBBAUAMIHEMQswCQYDVQQGEwJaQTEVMBMG A1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xHTAbBgNVBAoT FFRoYXd0ZSBDb25zdWx0aW5nIGNjMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNl cnzpy2vzierpdmlzaw9umrkwfwydvqqdexbuagf3dgugu2vydmvyienbmsywjayj KoZIhvcNAQkBFhdzZXJ2ZXItY2VydHNAdGhhd3RlLmNvbTAeFw05ODAzMjMwNzQw MDlaFw05OTAzMjMwNzQwMDlaMIG4MQswCQYDVQQGEwJCRTEQMA4GA1UECBMHQnJh YmFudDEPMA0GA1UEBxMGTGV1dmVuMRMwEQYDVQQKEwpLLlUuTGV1dmVuMRMwEQYD VQQLEwpFU0FUL0NPU0lDMSYwJAYDVQQDEx13d3cuY29zaWMuZXNhdC5rdWxldXZl bi5hyy5izte0mdigcsqgsib3dqejarylbwfyay52yw5kzw53yxv2zxjazxnhdc5r dwxldxzlbi5hyy5iztcbnzanbgkqhkig9w0baqefaaobjqawgykcgyear98du8rd w84vqs1ey77visp1cjfpno6vakno9xlqx5fyfopay2eykkdsciur+g5ghc6xnjj8 ukfzqnpa3+cdswniszhhs+khnygbnydvcrmsd5mltczz13fgt6jzvfqxf59ftx5u /D0NKn0TulgOGBNCopNqvj3tkaSyR6f2NsUCAwEAATANBgkqhkiG9w0BAQQFAAOB gqat6tly6zdsptmhhbh+ogh7ytcehi2gixi7wko04w6vn5pb6mannf7hwcbtyafq 2BcTnO0j/ci6bN7alHh9xSPVaKYGFPx9sRg6tIGrGORvK3arN5RbfFJRO7yNbyFQ SaI4iSgS+Qr6sNtgFqM0TksHD6021G58uPLzrojAM8Pdbg== -----END CERTIFICATE----- Application layer security PGP and S/MIME 23 4

5 Secure general model message sign verify Alice PrivKey A PubKey A encrypt decrypt Bob PGP or Pretty Good Privacy (Phil Zimmerman) A remarkable phenomenon Strong cryptographic algorithms General purpose application Available for many platforms Open source SS AB encrypt decrypt PubKey B PrivKey B PGP (ctd) PGP - Algorithms Freely available package for noncommercial use ( Commercial version Patent issues resolved Grass-root: not developed by, nor controlled by any governmental or standards organization Digital signature: Message digest: Key exchange Message encryption: Key management: Compression: Encoding: DSA, RSA SHA-1 DH (ElGamal), RSA CAST, IDEA, 3DES web of trust ZIP (defined) + Radix PGP - Components A PGP Message Authentication using digital signatures Confidentiality: one key per message; public-key encryption Compression: order is important! Compatible with radix-64 Segmentation and reassembly Key generation 29 Session key Signature Message Key ID Bob s PK Ks Timestamp Key ID Alice s PK 2 Leading bytes of H(M) H(M) Filename Timestamp DATA E PKB S SKA ZIP E Ks R

6 PGP - Key identifier Do not transmit public key with message save space Assign a Key ID to each public key public key s least significant 64 bits One or more User IDs per public key Private key: private keyring, encrypted using key derived from passphrase PGP - Correct public key? Directly from owner physically get the key from B (practical limitations) verify a key by phone (fingerprint) Via introducer of public key obtain B s key from a mutual trusted individual D = PGP approach obtain B s key from a trusted CA = X.509, S/MIME approach PGP - Public and Private key ring PGP - Trust Model Timestamp Key ID: 64 bits Public Key Owner Trust User ID Key Legitimacy Signatures Signature Trust Timestamp Key ID: 64 bits Public Key Encrypted private key User ID Trust flag byte owner trust field (assigned by user) signature trust field ( = owner trust field, if corresponding public key is in ring) key legitimacy field (computed) Revocation done by user him/herself PGP Trust Model S/MIME Trusted to sign A bit trusted to sign Not trusted to sign Alice Trusted key 35 Secure MIME Multipurpose Internet Mail Extensions IETF initiative Initiated by companies Integrates the MIME messaging standard with PKCS #7 (originally, now CMS) 36 6

7 Old SMTP/RFC 822 MIME (RFC ) Header: From, To Subject, Date, Message-ID SMTP no binaries no national language characters sometimes size limits not all implementations conform to standard 37 New header fields (5) MIME-Version Content -Type Content -Transfer-Encoding Content -ID Content -Description Content formats (15): text, multipart, message, image, video, audio, application multipart: mixed, parallel, alternative, digest 38 MIME (RFC ) Transfer encodings (6) 7bit 8bit binary quoted-printable base64 x-token Canonical form versus Native form 39 Public Key Cryptographic Standards (PKCS) Initiative of RSA Data Security PKCS #7: specifies how to apply public-key cryptography to obtain the desired security services types of messages: Data EnvelopedData SignedData SignedandEnvelopedData DigestedData (Clear-signed data) EncryptedData (-) 40 S/MIME Version 2 RFC (March 1998) Uses PKCS#7 Defines new MIME-Types, e.g. multipart/signed application/x-pkcs7-mime S/MIME Version 3 RFC (June 1999) Cryptographic Message Syntax (CMS) derived from PKCS#7 Security extensions signed receipts security labels (e.g., for authorization) secure mailing lists signing certificate attribute

8 S/MIME - Algorithms S/MIME Content types Digital signature: Message digest: Key exchange: Message encryption: Key management: Compression: Encoding: DSA, RSA MD5, SHA-1 DH (ElGamal), RSA RC2, 3DES PKIX [X.509] / ASN.1/DER + Radix Enveloped data: RecipientInfo Signed data (can be combined with previous) more than one signer ``Signerinfo : certificate Clear Signing also readable without S/MIME capability Registration request Certificates-Only message 44 From: Joris Claessens <[email protected]> Subject: example S/MIME message Date: Mon, 6 Mar :56: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="----=_nextpart_000_0005_01bf8784.9be915c0" This is a multi-part message in MIME format =_NextPart_000_0005_01BF8784.9BE915C0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable This is an example of a message that is digitally signed using the S/MIME standard =_NextPart_000_0005_01BF8784.9BE915C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJDDCCAr8w ggiooamcaqicawgxhtanbgkqhkig9w0baqqfadcbldelmakga1uebhmcwkexftatbgnvbagtdfdl c3rlcm4gq2fwzteumbiga1uebxmlrhvyymfudmlsbguxdzanbgnvbaotblroyxd0ztedmbsga1ue =_NextPart_000_0005_01BF8784.9BE915C0-- PGP versus S/MIME general model + compression (orig.) completely independent freely available application (stand-alone; plug-ins exist) web of trust revocation by user key ID personal use general model, no compression standardized, company driven integrated in for example Netscape and Microsoft hierarchical trust revocation by CA whole certificate is included commercial/organizational use SSL / TLS Transport layer security SSL / TLS Mainly in context of WWW security, i.e., to secure the HyperText Transfer Protocol (HTTP) But, in between application layer and TCP, thus can be used to secure other applications than HTTP too (IMAP, telnet, ftp, ) 48 8

9 Other WWW security protocols PCT: Microsoft s alternative to SSL S-HTTP: S/MIME-like protocol SET: for credit card transactions XML-Signature: PKCS#7-based signature on XML documents SSL / TLS Secure Sockets Layer (Netscape) SSL 2.0: security flaws! SSL 3.0: still widely used Transport Layer Security (IETF) TLS 1.0: adopted SSL 3.0 with minor changes RFC 2246, 01/99 (PS) TLS: security at the transport layer can be used (and is intended) for other applications too end-to-end secure channel, but nothing more... data is only protected during communication no non-repudiation! 50 Application e.g., http, telnet,... SSL/TLS in more detail Handshake Protocol Client Hello Server Hello... Change Cipher Spec Protocol Change Cipher Spec Record Layer Protocol SSL record Transport layer TCP/IP Alert Protocol Alert Application Data Application Protocol Application Data Record layer protocol fragmentation compression (not in practice) cryptographic security: encryption? data confidentiality MAC? data authentication [no digital signatures!] Handshake protocol client and server authentication establish cryptographic keys (for encryption and MAC) negotiation of cryptographic algorithms Handshake: overview CLIENT SERVER Hello Request Client Hello Server Hello Certificate Certificate Client Key Exchange Server Key Exchange Certificate Verify Certificate Request [changecipherspec] Server Hello Done Finished [changecipherspec] Finished? start handshake, protocol version, algorithms? authentication server + exchange (pre)master secret? client authentication? end handshake, integrity verification 53 Cryptographic algorithms [as supported in TLS 1.0, RFC 2246; TLS cipher suite style naming] Server/client authentication RSA DSS Key establishment RSA, RSA_EXPORT DH_DSS, DH_RSA, DH_RSA_EXPORT DHE_DSS, DHE_RSA, DHE_RSA_EXPORT DH_anon Encryption algorithms RC4_128, RC4_40 RC2_CBC_40 IDEA_CBC DES_CBC 3DES_EDE_CBC DES40_CBC Hash algorithms? HMAC MD5 SHA (=SHA-1) 54 9

10 More IETF TLS Usage of TLS in HTTP: upgrade to TLS within HTTP/1.1 (RFC 2817, 05/00) HTTP over TLS (RFC 2818, May 2000) Addition of ciphers: Kerberos cipher suites (RFC 2712, 10/99; 11/00) ECC cipher suites (03/01) AES (01/01) misc. ciphers: MISTY1 (03/01), Camellia (10/00) extensions for OpenPGP keys (03/01) Other: wireless extensions (11/00) TLS Delegation (02/01) SRP for TLS authentication (02/01) 55 TLS 1.1/2.0? TLS in the future (1) Some possible TLS enhancements, discussed within the IETF TLS WG: RSA-OAEP identity protection [note that this is already indirectly possible by authenticating within a DH_anon session] cipher suites for compression missing cipher suites (not all combinations possible) Backward compatibility remains very important! 56 TLS in the future (2) TLS 1.1 Internet Draft, October 2002 security fixes and clarifications SSL/TLS is still in evolution! Enhancements currently considered within IETF new cipher suites: e.g., AES wireless support (see WAP-WTLS) and other extensions password-based authentication and key exchange (SRP) Other enhancements proposed in literature performance improvements: batching [ShachamBoneh 01] and fast-track [ShachamBoneh 02] user (identity) privacy [PersianoVisconti 00] client puzzles [DeanStubblefield 01] to counter denial-of-service attacks SSL/TLS: security services SSL/TLS only provides: entity authentication data confidentiality data authentication SSL/TLS does not provide: non-repudiation unobservability (identity privacy) protection against traffic analysis secure many-to-many communications (multicast) security of the end-points (but relies on it!) trust negotiation [Hess et al 02] SSL/TLS: security? TLS 1.0 is the result of a public reviewing process: several problems have been identified in earlier versions (SSL 2.0/3.0) and have been solved SSL/TLS is practically secure Some caveats (in order of importance): bad implementation; e.g., random number generation PKCS#1 attack (use other padding scheme: OAEP; server error messages should contain less information) version / cipher suite roll back attempts (due to backward compatibility; disable export algorithms if possible) traffic analysis: e.g., length of ciphertext might reveal useful info plenty of known plaintext (both SSL/TLS and HTTP 59 related) SSL/TLS: evaluation TLS 1.0 provides a good level of security result of a public reviewing process: several problems have been identified in earlier versions (SSL 2.0/3.0) and have been addressed Some remaining security problems though: downgrade attacks cryptographic attacks PKI related problems web spoofing platform and users 60 10

11 SSL/TLS: security problems (1) Downgrade attacks [WagnerSchneier 96]? ciphersuite downgrade (U.S. export restrictions!)? version rollback (serious security flaws in SSL 2.0)? insecure default configuration of browser and web server Cryptographic attacks? better encrypt-then-authenticate instead of authenticate-then-encrypt?? too detailed error messages (combined with cryptographic weaknesses)? oracle attacks e.g., PKCS#1 RSA encryption [Bleichenbacher 98] SSL/TLS: security problems (2) PKI related problems? root certificates are distributed via browser authenticity of root certificates?? secure update of existing root certificates? secure addition of new root certificates?? wrong browser trust model (which root certificate?) attacker may easily add extra root certificates!? manual verifications: certificate chain and fingerprint? compromise of private keys? certificate revocation through CRLs or OCSP (Online)?!? CAs must be trusted to issue certificates to right entities? danger of spoofed certificates (e.g., implementation: e.g., bad randomnumber generation SSL/TLS: security problems (3) Web spoofing [Feltenet al 97] [YuanYeSmith 01]? limited visual indications? no clear distinction between content and status information? user is easily fooled by attacker: (secure) connection with attacker instead of intended site? attacker may be able to impersonate user! (e.g., replay of username/password) should not be possible with SSL/TLS client authentication Platform and user? lack of trusted operating system? most users are not educated / security-aware 63 Strong cryptography Server Gated Cryptography browser s security is automatically upgraded if server certificate contains specific extension Fortify, small program with which crippled Netscape browser can be upgraded Other solutions install secure proxy at client side applet does all crypto (cfr. e-banking solutions) 64 TLS for the end-user (WWW) Indication of a secure session: URL: graphics: open lock? closed lock Configuration browser: certificate and trust management choice of cipher suites Security in transport layer Transparent for application Pro: can be used for all TCP-based applications, without modifying them Con: authentication is one, but who/what to trust, is important Non-repudiation? In practice: (partially) integrated in application

12 Non-repudiation Legally only if in application, thus not provided by SSL/TLS SSL/TLS secures the communication channel, but not the exchanged messages SSL/TLS does not use digital signatures in the first place (except for client authentication) For electronic business, more advanced security protocols are needed User authentication First authentication, then authorization! SSL/TLS client authentication: during handshake, client digitally signs a specific message that depends on all relevant parameters of secure session with server software devices, smart cards or USB tokens can be deployed through standardized cryptographic interfaces supported by browsers (Netscape: PKCS#11; MSIE: PC/SC) PKCS#12 key container provides software mobility Usually another mechanism on top of SSL/TLS 68 Network address based Authenticate (groups of) users based on (ranges of) IP addresses, host names, and/or domain names Issues: Mapping of users to limited set of network addresses is not possible in many (open) applications Vulnerable to TCP/IP network problems: IP spoofing, DNS attacks,... Problem of web proxies 69 Fixed passwords HTTP/1.0 Basic Authentication password is sent at each request Form based fixed password scheme session authenticator in cookie various schemes exist, which are not always secure e.g., Microsoft Passport single sign-on service Inherent weaknesses brute-force and dictionary attacks password guessing and social engineering SSL/TLS needed to protect password and authenticator Still widely used: very easy and cheap; works with standard browser Password managers! 70 Dynamic passwords Passwords that are only used once passwords cannot be replayed or re-used when compromised SSL/TLS still needed for authentication of web server List of independent random one-time passwords difficult to (securely) maintain for the user Chain of dependent one-time passwords extra software needed at client side or with hardware token 71 Challenge/response User proves his identity to the server by demonstrating knowledge of a secret, not by just sending this secret to the server, but by producing the proper response to a challenge of the server, using this secret Symmetric schemes: e.g., MAC on time or random challenge HTTP/1.1 Digest Authentication Asymmetric schemes: e.g., digital signature on random challenge SSL/TLS Client Authentication Often implemented with hardware tokens 72 12

13 Hardware tokens Special-purpose tokens e.g., Digipass: can perform challenge/response authentication, and can calculate MACs e.g., SecurID: response to current time General-purpose tokens mobile phone: user authentication via mobile network PDAs or other programmable devices Smart cards and USB tokens can be deployed for SSL/TLS Client Authentication through standardized interfaces supported by browsers Bank cards and electronic purses 73 Network layer security IPsec, VPN, SSH IPsec Security Architecture for the Internet Protocol RFC 2401 (PS), 11/98 IP Authentication Header (AH) RFC 2402 (PS), 11/98 IP Encapsulating Security Payload (ESP) RFC 2406 (PS), 11/98 Internet Key Exchange (IKE) RFC 2409 (PS), 11/98 Application layer protocol for negotiation of Security Associations (SA) and Key Establishment Large and complex (48 documents) Mandatory for IPv6, optional for IPv4 75 IPsec - Security services Access control Connectionless integrity Data origin authentication Rejection of replayed packets (a form of partial sequence integrity) Confidentiality Limited traffic flow confidentiality 76 IPsec - Concepts IPsec - Parameters Security features are added as extension headers that follow the main IP header Authentication header (AH) Encapsulating Security Payload (ESP) header Security Association (SA) Security Parameter Index (SPI) IP destination address Security Protocol Identifier (AH or ESP) 77 sequence number counter sequence counter overflow anti-replay window AH info (algorithm, keys, lifetimes,...) ESP info (algorithms, keys, IVs, lifetimes,...) lifetime IPSec protocol mode (tunnel or transport) path MTU (maximum transmission unit) 78 13

14 IPsec: Cryptographic techniques AH: HMAC-MD5-96, HMAC-SHA1-96 ESP:DES-CBC, NULL encryption, HMAC-MD5-96, HMAC-SHA1-96 (recommended: 3DES-CBC) RFC 2403 (PS), November 1998 HMAC-MD5-96 (mandatory) RFC 2404 (PS), November 1998 HMAC-SHA-1-96 (mandatory) RFC 2104 (I), February 1997 HMAC: ICV = hash( K? opad hash( K? ipad data )) with ipad = 0x ; opad = 0x5C5C5C IPsec - Modes Transport (host-to-host) ESP: encrypts and optionally authenticates IP payload, but not IP header AH: authenticates IP payload and selected portions of IP header Tunnel (between security gateways) after AH or ESP fields are added, the entire packet is treated as payload of new outer IP packet with new outer header used for VPN 80 IPsec - AH Transport mode IPsec - AH Tunnel mode Security Parameters Index: identifies SA Sequence number: anti-replay Integrity Check Value: data authentication using HMAC-SHA-1-96 or HMAC-MD5-96 IP hdr upper layer data IP hdr upper layer data New IP hdr AH (..., Seq. Num., ICV) IP hdr upper layer data Integrity (only header fields that are not changed or are changed in a predictable manner)) IP hdr AH (..., Seq. Num., ICV) upper layer data Integrity (only header fields that are not changed or are changed in a predictable manner) IPsec - ESP header IPsec - ESP Transport mode Security Parameters Index: identifies SA Sequence number: anti-replay Encrypted payload data: data confidentiality using DES, 3DES, RC5, IDEA, CAST, Blowfish Padding: required by encryption algorithm (additional padding to provide traffic flow confidentiality) Integrity Check Value : data authentication using HMAC-SHA-1-96 or HMAC-MD5-96 IP hdr IP hdr upper layer data ESP hdr upper layer data ESP tlr ICV Confidentiality Integrity

15 IPsec - ESP Tunnel mode IPsec - Key management IP hdr upper layer data new IP hdr ESP hdr IP hdr upper layer data ESP tlr ICV Confidentiality Integrity Manual Automated procedure / framework Internet Security Association and Key Management Protocol (ISAKMP), RFC 2408 (PS) key exchange mechanism: Internet Key Exchange (IKE) Oakley: DH + cookie mechanism to thwart clogging attacks SKEME IPsec: Key management IPsec: Key management IKE defines 5 exchanges Phase 1: establish a secure channel Main mode Aggressive mode Phase 2: negotiate IPSEC security association Quick mode (only hashes, PRFs) Informational exchanges: status, new DH group Based on 5 generic exchanges defined in ISAKMP protection suite (negotiated) encryption algorithm hash algorithm authentication method: preshared keys, DSA, RSA, encrypted nonces Diffie Hellman group: 5 possibilities cookies for anti-clogging IKE - Main Mode with Digital Signatures IKE - Main Mode with Digital Signatures K derived from Initiator master = prf( N i N r, g xy ) SIG i = Signature on H( master, g x g y... ID i ) proposed attributes selected attributes g x, N i g y, N r E(K, ID i, [Cert(i)], SIG i ) E(K, ID r, [Cert(r)], SIG r ) H is equal to prf or the hash function tied to the signature algorithm (all inputs are concatenated) Responder SIG r = Signature on H( master, g y g x... ID r ) mutual entity authentication mutual implicit and explicit key authentication mutual key confirmation joint key control identity protection freshness of keying material perfect forward secrecy of keying material non-repudiation of communication 90 15

16 IPsec Overview Much better than previous alternatives IPsec documents hard to read Committee design: too complex ESP in Tunnel mode probably sufficient Simplify key management Clarify cryptographic requirements and thus difficult to implement (securely) VPN? Virtual Private Network Connects a private network over a public network. Connection is secured by tunneling protocols. The nature of the public network is irrelevant to the user. It appears as if the data is being sent over the private network VPN - Common use Transit Internetwork Remote user access over the Internet Virtual Private Network Connecting networks over the Internet Connection computers over an intranet Logical Equivalent Remote user access over the Internet Connecting networks over the Internet Virtual Private Network Virtual Private Network Internet Internet Branch Office Corporate Hub ISP Dedicated Link to ISP Dedicated Link to ISP Corporate Hub Dedicated or Dial-Up Link to ISP Dedicated Link to ISP You can use existing local Internet connections. No need for long distance connections You can use existing local Internet connections. No need for long distance connections or leased lines

17 Connecting computers over an intranet Virtual Private Network Corporate Internetwork VPN Server Secured or Hidden Network Provides easy client access to secured or hidden networks within the corporate network 97 VPN - Basic requirements User authentication and user authorization Data authentication and data confidentiality Key management Encapsulation data of private network is encapsulated in packets suited for transmission over the public network. (tunneling protocol) Address management assign a client s address on the private net 98 Tunneling Tunneling protocols Payload Tunnel Endpoints Transit Internetwork Header Transit Internetwork Tunnel Payload Layer 2, data link layer, PPP frames PPTP: Point -to-point Tunneling Protocol (Microsoft) L2TP: Layer 2 Tunneling Protocol Layer 3, network layer, IP packets IPSec, tunnel mode Tunneled Payload PPTP: Point-to-Point Tunneling Protocol L2TP: Layer 2 Tunneling Protocol MPPE: Microsoft Point -to-point Encryption Encapsulation: PPP in GRE (Generic Routing Encapsulation) header and IP header

18 SSH - General Tatu Ylonen, Helsinki University, Also IETF working group (SecSH) Version 2: several Internet Drafts available SSH - Goals Allow secure communication over insecure networks: secure replacements for the r-tools secure X11 sessions arbitrary TCP/IP port forwarding over encrypted channels? can be used for setting up VPN SSH - Protocols SSH Secure login Transport layer protocol: server authentication (host public key + server public key) key exchange cryptographic data protection User authentication protocol: username/password public-key authentication of the user public-key authentication of the user s host Connection protocol: interactive login sessions remote execution of commands Example: logging in from MS Windows to a machine running Linux with Putty 19:58:42 Looking up host "lagrange.esat.kuleuven.ac.be" 19:58:42 Connecting to port 22 19:58:45 Server version: SSH OpenSSH_3.4p1 Debian 1:3.4p1-1 19:58:45 We claim version: SSH-2.0 -PuTTY-Release-0.53b 19:58:45 Using SSH protocol version 2 19:58:45 Doing Diffie-Hellman group exchange 19:58:45 Doing Diffie-Hellman key exchange 19:58:46 Host key fingerprint is: 19:58:46 ssh-rsa 1024 bf:7d:02:8d:4c:84:9f:fb:6b:e1:cd:cb:6a:49:5a:c5 19:58:46 Initialised AES-256 client->server encryption 19:58:46 Initialised AES-256 server ->client encryption 19:58:51 Keyboard-interactive authentication refused 19:58:59 Sent password 19:58:59 Access granted Protocol negotiation Session key exchange Host authentication Cipher negotiation Client authentication 106 SSH Secure POP3 tunnel Use SSH client to setup a tunnel from localhost:110 to mailserver:110 Setup the mail client to connect to (localhost) instead of the mail server. Data transmitted to localhost will be delivered through the SSH tunnel to the mail server on port 110. The mail server will reply back through the SSH tunnel. Final remarks

19 Some observations IPSec is really transparent, SSL/TLS only conceptually, but not really in practice SSH, PGP: stand-alone applications, immediately and easy to deploy and use Network security: solved in principle Electronic commerce security: more is needed! 109 More information (1) William Stallings, Cryptography and Network Security - Principles and Practice, Second Edition, 1999 Nagand Doraswamy, Dan Harkins, IPSEC - The New Security Standard for the Internet, Intranets, and Virtual Private Networks, Prentice Hall, IETF web site: e.g., IETF-TLS Working Group More information (2) Java Security (2nd edition) W3C Security (incl WWW Security FAQ) E-Commerce Security, Weak Links, Best Defenses Security Technologies for the World Wide Web