1

Internet Security Protocols

Bart PreneelJune 2003

With thanks to Joris Claessens and Walter Fumy

2

Outline

• Preliminaries: – Internet protocols, PKI, X.509, Encoding

• Application layer security (email)– PGP, S/MIME

• Transport layer security– SSL / TLS

• Network layer security– IPSec, VPN, SSH

3

Nu

mb

er o

f In

tern

et U

sers

in M

illi

on

s

0,1

1

10

100

1.000

19701960 1980 1990 2000 2010 2020

Experts

Electronic Business

e-mailTCP/IP

WWW

HTML

e-Commerce

XML

WAP

mobilebusiness

Internet Evolution

Armed Forces

Universities

Internet Standardization

• 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– http://www.ietf.org/html.charters/wg-dir.html

• RFCs– http://www.rfc-editor.org– ftp://FTP.ISI.EDU/in-notes/

IETF Standards

– Proposed Standard (PS)• stable spec • lowest level of standards track

– Draft Standard (DS)• at least two independent and

interoperable implementations– Standard (STD)

• widely, successfully usedStandard

Proposed

Draft std

Historic

Experimental

IETF Intermediate documents

• 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”

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)

Internet Protocols

Link

IP

SMTP HTTP

TCP/UDP

. . .

Network

Transport

Application

Link

IP

SMTP HTTP

TCP/UDP

. . .

• Network Layer – Internet Protocol (IP)

• Transport Layer– Transmission Control Protocol (TCP), User Datagram

Protocol (UDP)10

SP hdr data SP tlr MAC

integrity

confidentiality

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)

Internet Security Protocols

Public -Key Infrastructure

IP/ IPSec (Internet Protocol Security)

Transport Layer Security (SSH, SSL, TLS)

S/MIME

Electronic Commerce LayerSET, Ecash, ...

Transmission Control Protocol (TCP)

PEMPGPS-HTTP

User Datagram Protocol (UDP)

PKIX

SPKI

• security services depend on the layer of integration:– the mechanisms can only protect the payload and/or header

information available at this layer– header information of lower layers is not protected!! 12

Security Associations(Security Parameters

incl. Shared Keys)

Key Management and Security Association

EstablishmentProtocols

SP Architecture II: Session (Association) EstablishmentHost A Host B

SP hdr encrypted data MAC

3

13

Note on export restrictions

• 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

between “civilized nations”14

Public Key Infrastructure

• 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

15

X.509 certificate v1

• Version number• Serial number• Signature algorithm• Issuer name• Validity period• Subject name• Subject public key• Signature of the CA

16

X.509 certificate v2

• Idem +• Issuer unique identifier• Subject unique identifier• Directory Access Control

17

X.509 certificate v3

• Idem +• Extensions (each one can be critical):

– Alternative naming– More info about the key– Other identification data– CRL location information– …

18

Typical X.509 solution

CertificationAuthority

Key RecoveryAuthority

TimestampingAuthority

Card Issuing System

Directory System

RegistrationAuthority

LocalRegistrationAuthority

NotarizationAuthority

PKIUser Agent

Server Components

Administration Components

Client

4

19

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)

20

ASN.1 definition certificateCertificate ::= 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 v3subjectUniqueIdentifier [2] IMPLICIT UniqueIdentifier OPTIONAL

-- if present, version must be v2 or v3extensions [3] Extensions OPTIONAL

-- If present, version must be v3 }}

Version ::= INTEGER { v1(0), v2(1), v3(2) }CertificateSerialNumber ::= INTEGERAlgorithmIdentifier ::= SEQUENCE {

algorithm ALGORITHM.&id ({ SupportedAlgorithms}),parameters ALGORITHM.&Type ({ SupportedAlgorithms}{ @algorithm}) OPTIONAL }

Validity ::= SEQUENCE {notBefore Time,notAfter Time }

SubjectPublicKeyInfo ::= SEQUENCE {algorithm AlgorithmIdentifier,subjectPublicKey BIT STRING }

(etc)

21

DER encoded certificate00000 | 30 82 02 ee 30 82 02 57 02 02 12 cf 30 0d 06 09 | 0...0..W....0...00010 | 2a 86 48 86 f7 0d 01 01 04 05 00 30 81 c4 31 0b | *. H........0..1.00020 | 30 09 06 03 55 04 06 13 02 5a 41 31 15 30 13 06 | 0. ..U....ZA1.0..00030 | 03 55 04 08 13 0c 57 65 73 74 65 72 6e 20 43 61 | .U ....Western Ca00040 | 70 65 31 12 30 10 06 03 55 04 07 13 09 43 61 70 | pe 1.0...U....Cap00050 | 65 20 54 6f 77 6e 31 1d 30 1b 06 03 55 04 0a 13 | e Town1.0...U...00060 | 14 54 68 61 77 74 65 20 43 6f 6e 73 75 6c 74 69 | .Thawte Consulti00070 | 6e 67 20 63 63 31 28 30 26 06 03 55 04 0b 13 1f | ng cc1(0&..U....00080 | 43 65 72 74 69 66 69 63 61 74 69 6f 6e 20 53 65 | Ce rtification Se00090 | 72 76 69 63 65 73 20 44 69 76 69 73 69 6f 6e 31 | rvices Division1000a0 | 19 30 17 06 03 55 04 03 13 10 54 68 61 77 74 65 | .0 ...U.... Thawte000b0 | 20 53 65 72 76 65 72 20 43 41 31 26 30 24 06 09 | S erver CA1&0$..000c0 | 2a 86 48 86 f7 0d 01 09 01 16 17 73 65 72 76 65 | *. H........serve000d0 | 72 2d 63 65 72 74 73 40 74 68 61 77 74 65 2e 63 | r-certs@thawte.c000e0 | 6f 6d 30 1e 17 0d 39 38 30 33 32 33 30 37 34 30 | om 0...9803230740000f0 | 30 39 5a 17 0d 39 39 30 33 32 33 30 37 34 30 30 | 09 Z..9903230740000100 | 39 5a 30 81 b8 31 0b 30 09 06 03 55 04 06 13 02 | 9Z 0..1.0...U....00110 | 42 45 31 10 30 0e 06 03 55 04 08 13 07 42 72 61 | BE 1.0...U....Bra00120 | 62 61 6e 74 31 0f 30 0d 06 03 55 04 07 13 06 4c | ba nt1.0...U....L00130 | 65 75 76 65 6e 31 13 30 11 06 03 55 04 0a 13 0a | eu ven1.0...U....00140 | 4b 2e 55 2e 4c 65 75 76 65 6e 31 13 30 11 06 03 | K. U.Leuven1.0...00150 | 55 04 0b 13 0a 45 53 41 54 2f 43 4f 53 49 43 31 | U. ...ESAT/COSIC100160 | 26 30 24 06 03 55 04 03 13 1d 77 77 77 2e 63 6f | &0 $..U....www.co00170 | 73 69 63 2e 65 73 61 74 2e 6b 75 6c 65 75 76 65 | sic.esat.kuleuve00180 | 6e 2e 61 63 2e 62 65 31 34 30 32 06 09 2a 86 48 | n. ac.be1402..*.H00190 | 86 f7 0d 01 09 01 16 25 6d 61 72 6b 2e 76 61 6e | .. .....%mark.van001a0 | 64 65 6e 77 61 75 76 65 72 40 65 73 61 74 2e 6b | denwauver@esat.k001b0 | 75 6c 65 75 76 65 6e 2e 61 63 2e 62 65 30 81 9f | ul euven.ac.be0..001c0 | 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 03 | 0. ..*.H.........(only first part of certifcate fits on 1 slide…)

22

Base64 00 A 17 R 34 i 51 z01 B 18 S 35 j 52 002 C 19 T 36 k 53 103 D 20 U 37 l 54 204 E 21 V 38 m 55 305 F 22 W 39 n 56 406 G 23 X 40 o 57 507 H 24 Y 41 p 58 608 I 25 Z 42 q 59 709 J 26 a 43 r 60 810 K 27 b 44 s 61 911 L 28 c 45 t 62 +12 M 29 d 46 u 63 /13 N 30 e 47 v14 O 31 f 48 w (pad) =15 P 32 g 49 x16 Q 33 h 50 y (1) *

0 0 1 1 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0

0x30 0x82 0x02

12M

08I

08I

02C

23

Base64 encoded certificate

-----BEGIN CERTIFICATE-----

MIIC7jCCAlcCAhLPMA0GCSqGSIb3DQEBBAUAMIHEMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xHTAbBgNVBAoTFFRoYXd0ZSBDb25zdWx0aW5nIGNjMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMRkwFwYDVQQDExBUaGF3dGUgU2VydmVyIENBMSYwJAYJKoZIhvcNAQkBFhdzZXJ2ZXItY2VydHNAdGhhd3RlLmNvbTAeFw05ODAzMjMwNzQwMDlaFw05OTAzMjMwNzQwMDlaMIG4MQswCQYDVQQGEwJCRTEQMA4GA1UECBMHQnJhYmFudDEPMA0GA1UEBxMGTGV1dmVuMRMwEQYDVQQKEwpLLlUuTGV1dmVuMRMwEQYDVQQLEwpFU0FUL0NPU0lDMSYwJAYDVQQDEx13d3cuY29zaWMuZXNhdC5rdWxldXZlbi5hYy5iZTE0MDIGCSqGSIb3DQEJARYlbWFyay52YW5kZW53YXV2ZXJAZXNhdC5rdWxldXZlbi5hYy5iZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr98Du8Rdw84VqS1EY77VisP1CJFpNo6vaknO9xlqX5FYfOPAy2eyKkDscIUr+g5ghc6XNjj8ukFZqnPa3+cdSWNiszhHs+KhNygBNYdvcRMSD5MLtCZZ13fgt6JZVfQXf59Ftx5u/D0NKn0TulgOGBNCopNqvj3tkaSyR6f2NsUCAwEAATANBgkqhkiG9w0BAQQFAAOBgQAT6Tly6zdSPtmhHbH+ogH7ytcEhI2giXI7wko04w6vN5Pb6maNNf7hwCBtyafQ2BcTnO0j/ci6bN7alHh9xSPVaKYGFPx9sRg6tIGrGORvK3arN5RbfFJRO7yNbyFQSaI4iSgS+Qr6sNtgFqM0TksHD6021G58uPLzrojAM8Pdbg==-----END CERTIFICATE-----

Application layer security

PGP and S/MIME

5

25

Secure email: general model

sign

Alice Bob

message

PrivKey A

PrivKey BPubKey B

PubKey A

SSAB

verify

decryptencrypt

encrypt decrypt

26

PGP or “Pretty Good Privacy”(Phil Zimmerman)

• A remarkable phenomenon

• Strong cryptographic algorithms• General purpose application• Available for many platforms• Open source

27

PGP (ctd)

• Freely available package for non-commercial use (www.pgpi.com)

• Commercial version• Patent issues resolved • Grass-root: not developed by, nor controlled

by any governmental or standards organization

28

PGP - Algorithms

• Digital signature:• Message digest:• Key exchange• Message encryption:• Key management:• Compression:• Encoding:

DSA, RSASHA-1DH (ElGamal), RSACAST, IDEA, 3DES‘web of trust’ZIP(defined) + Radix 64

29

PGP - Components

• Authentication using digital signatures• Confidentiality: one key per message;

public-key encryption• Compression: order is important!• Compatible with email: radix-64• Segmentation and reassembly

• Key generation30

A PGP MessageKey ID Bob’s PK

Ks

Timestamp

Key ID Alice’s PK

2 Leading bytes of H(M)

H(M)

Filename

Timestamp

DATA

Session key

Signature

Message

ZIP

E Ks

R64

E PKB

S SKA

6

31

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

32

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

33

PGP - Public and Private key ring

• 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

34

PGP - Trust Model

• ‘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

35

PGP Trust Model

Alice

Trusted to sign

A bit trusted to sign

Not trusted to signTrusted key

36

S/MIME

• “Secure MIME”• “Multipurpose Internet Mail Extensions”• IETF initiative• Initiated by companies• Integrates the MIME messaging standard

with PKCS #7 (originally, now CMS)

7

37

Old email: SMTP/RFC 822

• Header: “From”, “To” “Subject”, “Date”, “Message-ID”

• SMTP– no binaries– no national language characters– sometimes size limits– not all implementations conform to standard

38

MIME (RFC 2045-9)

• 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

39

MIME (RFC 2045-9)

• Transfer encodings (6)– 7bit– 8bit– binary– quoted-printable– base64– x-token

• Canonical form versus Native form

40

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 (-)

41

S/MIME Version 2

• RFC 2311-2312 (March 1998)• Uses PKCS#7• Defines new MIME-Types, e.g.

– multipart/signed– application/x-pkcs7-mime

42

S/MIME Version 3

• RFC 2630-2634 (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

43

S/MIME - Algorithms

• Digital signature:• Message digest:• Key exchange:• Message encryption:• Key management:• Compression:• Encoding:

DSA, RSAMD5, SHA-1DH (ElGamal), RSARC2, 3DESPKIX [X.509]/ASN.1/DER + Radix 64

44

S/MIME Content types

• 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

45

From: Joris Claessens <joris.claessens@esat.kuleuven.ac.be >Subject: example S/MIME messageDate: Mon, 6 Mar 2000 15:56:59 +0100MIME -Version: 1.0Content-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.9BE915C0Content-Type: text/plain;

charset="Windows -1252"Content-Transfer -Encoding: quoted-printable

This is an example of a message that is digitally signed using t he S/MIME standard.

------ =_NextPart_000_0005_01BF8784.9BE915C0Content-Type: application/x-pkcs7-signature;

name="smime.p7s"Content-Transfer -Encoding: base64Content-Disposition: attachment;

filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIIJDDCCAr8wggIooAMCAQICAwGxhTANBgkqhkiG9w0BAQQFADCBlDELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0 ZTEdMBsGA1UE...------ =_NextPart_000_0005_01BF8784.9BE915C0--

46

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

Transport layer security

SSL / TLS

48

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, …)

9

49

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• ...

50

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!

51

SSL record

Transport layerTCP/IP

AlertClient HelloServer Hello

...

Record Layer Protocol

Applicatione.g., http, telnet, ...

Handshake Protocol

ApplicationData

ApplicationProtocol

AlertProtocol

Change Cipher SpecProtocol

ApplicationData

ChangeCipher Spec

52

SSL/TLS in more detail• “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

53

Handshake: overview

Server Hello Done

Server Key Exchange

[changecipherspec]

Certificate

authentication server + exchange (pre)master secret

Certificate Request

client authentication

Finished

end handshake, integrity verification

CLIENT SERVER

Hello Request

Client Hello

start handshake, protocol version, algorithms

Certificate

Server Hello

?

Client Key Exchange

?

Certificate Verify

?

Finished

[changecipherspec]

?

54

Cryptographic algorithms

• 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

[as supported in TLS 1.0, RFC 2246; TLS cipher suite style naming]

• 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)

10

55

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) 56

TLS in the future (1)

• TLS 1.1/2.0 ? • 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!

57

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– trust negotiation [Hess et al’02]

58

SSL/TLS: security servicesSSL/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!)

59

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

related)60

SSL/TLS: evaluationTLS 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

11

61

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 attackse.g., PKCS#1 RSA encryption [Bleichenbacher’98]

? implementation: e.g., bad randomnumber generation 62

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., www.micr0soft.com)

63

SSL/TLS: security problems (3)Web spoofing [Felten et 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

64

“Strong cryptography”

• ‘Server Gated Cryptography’– browser’s security is automatically upgraded if

server certificate contains specific extension

• Fortify, http://www.fortify.net/– 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)

65

TLS for the end-user (WWW)

• Indication of a secure session:– URL: http:// ? https://– graphics: open lock ? closed lock

• Configuration browser:– certificate and trust management– choice of ‘cipher suites’

66

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

67

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...

68

User authenticationFirst 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

69

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 proxies70

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 !

71

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

72

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

13

73

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

Network layer security

IPsec, VPN, SSH

75

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

76

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

77

IPsec - Concepts

• 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)

78

IPsec - Parameters

• 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)

14

79

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 1997HMAC: ICV = hash( K ? opad || hash( K ? ipad || data ))

with ipad = 0x363636... ; opad = 0x5C5C5C...80

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

81

IPsec - AH Transport 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

Integrity

(only header fields that are not changed or are changed in a predictable manner)

AH (..., Seq. Num., ICV) upper layer data

82

IPsec - AH Tunnel mode

IP hdr upper layer data

New IP hdr

Integrity(only header fields that are not changed or are changed in a predictable manner))

AH (..., Seq. Num., ICV) IP hdr upper layer data

83

IPsec - ESP header

• 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

84

IPsec - ESP Transport mode

IP hdr ESP hdr

IP hdr upper layer data

Integrity

Confidentiality

upper layer data ESP tlr ICV

15

85

IPsec - ESP Tunnel mode

IP hdr upper layer data

new IP hdr ESP hdr IP hdr upper layer data ESP tlr ICV

Integrity

Confidentiality

86

IPsec - Key management

• 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

87

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

• cookies for anti-clogging 88

IPsec: Key management

• protection suite (negotiated)– encryption algorithm– hash algorithm– authentication method:

• preshared keys, DSA, RSA, encrypted nonces

– Diffie Hellman group: 5 possibilities

IKE - Main Mode with Digital Signatures

SIG r = Signature on H( master, gy || gx || ... || ID r )

Initiator Responder

proposed attributes

selected attributes

gx, Ni

gy, Nr

E(K, IDi, [Cert(i)], SIGi )

E(K, IDr, [Cert(r)], SIGr )

H is equal to prf or the hash function tied to the signature algorithm (all inputs are concatenated)

K derived frommaster = prf( N i || N r , gxy )

SIGi = Signature on H( master, gx || gy || ... || ID i )

90

IKE - Main Mode with Digital Signatures

• 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

16

91

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)

92

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.

93

Transit Internetwork

LogicalEquivalent

Virtual Private Network

94

VPN - Common use

• Remote user access over the Internet

• Connecting networks over the Internet

• Connection computers over an intranet

95

Remote user access over the Internet

• You can use existing local Internet connections.• No need for long distance connections

ISP

Internet

Corporate Hub

Virtual Private Network

Dedicated Link to ISPDedicated Link to ISP

96

Connecting networks over the Internet

BranchOffice

CorporateHub

Internet

Virtual Private Network

Dedicated or Dial-Up Link to ISP

Dedicated Link to ISP

• You can use existing local Internet connections.• No need for long distance connections or leased

lines

17

97

Connecting computers over an intranet

Corporate Internetwork

Virtual Private Network

Securedor

Hidden Network

VPNServer

• Provides easy client access to secured or hidden networks within the corporate network

98

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

99

Tunneling

Transit Internetwork

Tunnel Endpoints

Payload Payload

TunneledPayload

Transit Internetwork

Header

Tunnel

100

Tunneling protocols

• “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

101

PPTP: Point-to-Point Tunneling Protocol

• MPPE: Microsoft Point -to-Point Encryption• Encapsulation: PPP in GRE (Generic Routing

Encapsulation) header and IP header.

102

L2TP: Layer 2 Tunneling Protocol

18

103

SSH - General

• Tatu Ylonen, Helsinki University, 1990.• Also IETF working group (SecSH)• Version 2: several Internet Drafts available

104

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

105

SSH - Protocols

• 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– ...

106

• 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 134.58.189.104 port 22– 19:58:45 Server version: SSH-1.99 -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

SSH – Secure login

Protocol negotiation

Session key exchange

Host authentication

Cipher negotiation

Client authentication

107

SSH – Secure POP3 tunnel

• Use SSH client to setup a tunnel fromlocalhost:110 to mailserver:110

• Setup the mail client to connect to 127.0.0.1(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

109

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!

110

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, 1999.

• IETF web site: www.ietf.org– e.g., IETF-TLS Working Group

http://www.ietf.org/html.charters/tls-charter.html

111

More information (2)• Java Security (2nd edition)

http://www.securingjava.com/• W3C Security (incl WWW Security FAQ)

http://www.w3.org/Security/• “E-Commerce Security, Weak Links, Best

Defenses”http://www.cigital.com/books/ecs/

• “Security Technologies for the World Wide Web”http://www.esecurity.ch/Books/wwwsec.html