1 Internet Security Protocols Bart Preneel June 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 Number of Internet Users in Millions 0,1 1 10 100 1.000 1970 1960 1980 1990 2000 2010 2020 Experts Electronic Business e-mail TCP/IP WWW HTML e-Commerce XML WAP mobile business 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 used Standard 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”
19
Embed
Internet Evolution Internet Standardizationeuler.fd.cvut.cz/.../slides/InternetSecurity.pdf · Internet Security Protocols ... e-Commerce XML WAP m obile business Internet Evolution
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
– 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
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) *
• 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
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
? ciphersuite downgrade (U.S. export restrictions!)? version rollback (serious security flaws in SSL 2.0)? insecure default configuration of browser and web server
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)
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)
• 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)
• 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