Internet Security – Where are we Heading?
description
Transcript of Internet Security – Where are we Heading?
![Page 1: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/1.jpg)
Wolfgang Schneider
Internet Security – Where are we Heading?
GMD Darmstadt
![Page 2: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/2.jpg)
2
Layered Approach to Security
Application Security
Network Security
Physical Security
Operating System Security
Public Key Infrastructure
![Page 3: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/3.jpg)
3
Types of Standards
Framework/Architecture
High Level API
Protocols
Low Level API
Algorithms
Legal &Regulatory
![Page 4: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/4.jpg)
4
IETF Security
Cornerstones:Cornerstones: IP layer VPNs (IPsec)IP layer VPNs (IPsec) Secure web access (TLS)Secure web access (TLS) Secure E-mail (S/MIME)Secure E-mail (S/MIME) Public Key Infrastructure (PKIX)Public Key Infrastructure (PKIX)
Plus XMLSIG, OPGP, SSH, CAT, DNSSEC, ...Plus XMLSIG, OPGP, SSH, CAT, DNSSEC, ...
![Page 5: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/5.jpg)
5
IPsec Overview
Adopted as Proposed Standards by the IETF: RFCs 2401-2412 (12/98)
IPv4 and IPv6 compatible formats Authentication Header (AH) for (whole datagram)
integrity and authenticity, and optional anti-replay Encapsulating Security Payload (ESP) for modular
confidentiality, authentication, integrity, and anti-replay
Separate security association negotiation and key management protocol: IKE
![Page 6: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/6.jpg)
6
HOST 2B
HOST 8
HOST 6MobileHOST
IPsec Path Options
AHOST 1 HOST 3
C
C HOST 7A
B
ROUTER 1C
INTERNET
C
A
ROUTER 2A
A
A ROUTER 3
BB
![Page 7: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/7.jpg)
7
IPsec Access Control
Security Policy Databases (SPDs) Separate for inbound and outbound traffic for each interface SPD entry specifies:
drop bypass IPsec (protocols & algorithms)
Traffic characterized by selectors: source/destination IP addresses (also bit masks & ranges) next protocol source/destination ports User or system ID (must map to other selectors in a
security gateway) In a host, mapping can be done at connection establishment In a security gateway, mapping must be checked for each
packet
![Page 8: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/8.jpg)
8
IKE: Internet Key Exchange Protocol
IKE is the default key management protocol for IPSEC, based on three key management protocols: ISAKMP, Oakley, and SKEME
IKE encompasses algorithms for key establishment, SA parameter negotiation, identification & authentication
Variable number of messages exchanged, depending on mode (Main, Aggressive, Quick)
One IKE SA between a pair of IPsec implementations can support later user traffic SA establishment
![Page 9: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/9.jpg)
9
What’s Next for IPsec?
Standard policy language? Inter-domain policy negotiation Security gateway discovery Public key certificate syntax conventions Routing for VPNs
![Page 10: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/10.jpg)
10
Secure Sockets Layer (SSL)
Developed by Netscape to secure web browsing Designed to be a “session layer” protocol over TCP --
individual session can span multiple TCP connections
Based on client-server (vs. peer) communication model
Aimed at being algorithm independent -- supports multiple encryption, authentication-integrity, and key exchange algorithms
Transport Layer Security (TLS) protocol in IETF (despite the misnomer!) is standards-based successor
![Page 11: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/11.jpg)
11
SSL Security Services & Algorithms Confidentiality
– Block Cipher (RC2, DES, 3DES, Skipjack)– Stream Cipher (RC4)
Server Authentication– based on use of server X.509 certificate, roots in browsers
Client Authentication– optional, supported only if client certificates are available
Strict Message Sequencing– relies on TCP
Compression– optional, currently not generally implemented
![Page 12: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/12.jpg)
12
Enhancements in TLS
SSL has been adopted and enhanced by IETF Transport Layer Security (TLS) Working Group into the TLS protocol
TLS v.1.0 is an enhancement of SSL v.3.0 Major changes in TLS v1.0
– required algorithm support for DSA and D-H, RSA optional– use of HMAC vs. SSL-defined keyed MAC algorithm– modified key generation algorithm uses both MD5 and SHA-1
with HMAC as a pseudo-random function– use of both MD5 and SHA-1 in RSA signatures– more complete set of error alerts
![Page 13: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/13.jpg)
13
TLS Summary
Status -- – SSL v.3.0 [11/96] is the current version– TLS 1.0 is a proposed standard, RFC 2246
Popularity -- designed for securing HTTP, now used to protect multiple applications
Not architecturally appropriate? -- TCP/IP does not have a session layer but SSL was motivated by web-based transactions and time-to-market considerations
Basic Services -- server authentication, message encryption & integrity
Deployed algorithms -- RSA and RC4 IESG Direction -- DSS signature, DH key generation,
DES encryption to become default mechanisms
![Page 14: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/14.jpg)
14
S/MIME Standards
S/MIME v2 (RFC 2312)S/MIME v2 (RFC 2312) S/MIME v3 (RFC 2633)S/MIME v3 (RFC 2633) Cryptographic Message Syntax (RFC 2630)Cryptographic Message Syntax (RFC 2630) Certificate handling conventions (RFC 2312, Certificate handling conventions (RFC 2312,
2632)2632) Enhanced services (RFC 2634)Enhanced services (RFC 2634)
![Page 15: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/15.jpg)
15
HostHost
Originator
Router Mail Relay Host
Recipient
IPNetworkService
TCPTransport
RFC 822
IPNetworkService
MIME
SMTP
S/MIMEContent
RFC 822
MIME
TCPTransport
IPNetworkService
SMTP
S/MIMEContent
Mail RoutingSMTP SMTP
TCPTransport
IPNetworkService
TCPTransport
IPNetworkService
Internet Message Protocol Layers
![Page 16: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/16.jpg)
16
What Are S/MIME Messages?
Combinations of two separately defined formats– (1) MIME entities– (2) Cryptographic Message Syntax (CMS) objects
S/MIME entity formats– one for enveloped (i.e., encrypted) – provides confidentiality
and key distribution services – two for signed – each provides integrity and data origin
authentication services– nested combinations of signed and encrypted formats – may nest in any order to any “reasonable” depth– multiple nesting is used to construct S/MIME Enhanced
Security Services (details later)
![Page 17: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/17.jpg)
17
S/MIME Version 2
RFC 2311 – S/MIME Version 2 Message Specification, which is based on . . .
RFC 2315 – PKCS #7: Cryptographic Message Syntax Version 1.5
– Public-Key Cryptography Standards (PKCS): specifications begun in 1991 by RSA Laboratories and other industry and academic participants
– PKCS #7: a general syntax for data that may have cryptography applied to it, e.g., digital signatures
– defines a “digital envelope for a recipient” :(1) data encrypted in a content encryption key (CEK)(2) CEK encrypted in a second key, known to the recipient
![Page 18: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/18.jpg)
18
S/MIME Version 3
RFC 2633 – S/MIME Version 3 Message Specification, which is based on . . .
RFC 2630 – Cryptographic Message Syntax– enhancements to PKCS #7– adds attribute certificates, key agreement methods– adds encapsulation syntax for data protection– adds multiple, nested encapsulations
S/MIME uses three of the CMS data types– enveloped data– signed data– just plain data
S/MIME adds signed and unsigned attributes
![Page 19: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/19.jpg)
19
S/MIME Enhanced Security Services
Optional features provide functionality similarto the SDNS Message Security Protocol
– signed receipts– security labels– secure mailing lists
These features interact– Mail List Agents (MLAs) enforce access controls based on
security labels– MLAs can override the message originator’s requests for
signed receipts
![Page 20: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/20.jpg)
20
The BGP Security Problem
BGP is the critical infrastructure for Internet, inter-domain routing
Benign configuration errors have wreaked havoc for portions of the Internet address space
The current system is highly vulnerable to human errors, as well as a wide range of attacks
At best, BGP uses point-to-point keyed MAC, with no automated key management
Most published BGP security proposals have been pedagogic, not detailed, not deployable
Solutions must take into account Internet topology, size, update rates, ...
![Page 21: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/21.jpg)
21
BGP Security Requirements
Verification of address space “ownership” Authentication of Autonomous Systems (AS) Router authentication and authorization (relative to an
AS) Route and address advertisement authorization Route withdrawal authorization Integrity and authenticity of all BGP traffic on the wire Timeliness of BGP traffic
![Page 22: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/22.jpg)
22
Securing UPDATE messages
A secure UPDATE consists of an UPDATE message with a new, optional, transitive path attribute for route authorization
This attribute consists of a signed sequence of route attestations, nominally terminating in an address space attestation
This attribute is structured to support both route aggregation and AS sets
Validation of the attribute verifies that the route was authorized by each AS along the path and by the ultimate address space owner
![Page 23: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/23.jpg)
23
Distributing Certificates, CRLs, & AAs
Putting certificates & CRLs in UPDATEs would be redundant and make UPDATEs too big
Same is true for address attestations Solution: use servers for these data items
– replicate for redundancy & scalability – locate at NAPs for direct (non-routed) access – download options:
» whole certificate/AA/CRL databases» queries for specific certificates/AAs/CRLs
To minimize processing & storage overhead, NOCs should validate certificates & AAs, and send processed extracts to routers
![Page 24: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/24.jpg)
24
S-BGP Summary
The transmission and processing costs of S-BGP are not significant
The proposed distribution mechanisms for certificates, CRLs, and AAs is viable
Storage overhead exceeds the capacity of existing routers, but adding adequate storage is feasible, especially for ISP BGP speakers
Testing and deployment issues– Cisco handling of optional, transitive path attributes– Intra-domain distribution of S-BGP attribute
But deployment poses a chicken and egg problem!
![Page 25: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/25.jpg)
25
PKIX
Certificate & CRL syntax and processing (RFC 2459)Certificate & CRL syntax and processing (RFC 2459) CMP - Certificate Management Protocols (RFC 2510)CMP - Certificate Management Protocols (RFC 2510) OCSP - Online Certificate Status Protocol (RFC OCSP - Online Certificate Status Protocol (RFC
2560)2560) CRMF – Cert Request Message Format (RFC 2511)CRMF – Cert Request Message Format (RFC 2511) Certification policies & practices (RFC 2527-Certification policies & practices (RFC 2527-
informational)informational)
![Page 26: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/26.jpg)
26
More PKIX
LDAPv2 Schema & Operational Protocols LDAPv2 Schema & Operational Protocols (RFC 2587 & 2559)(RFC 2587 & 2559)
HTTP/FTP Ops (RFC 2585)HTTP/FTP Ops (RFC 2585) CMC – Cert Management Messages (RFC CMC – Cert Management Messages (RFC
xxxx)xxxx) Qualified Certificates (RFC xxxx)Qualified Certificates (RFC xxxx) Time stamping, notarization, ...Time stamping, notarization, ...
![Page 27: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/27.jpg)
27
Still PKIX
PKIX is now the basis of most major PKI PKIX is now the basis of most major PKI developments and deploymentsdevelopments and deployments
PKIX has still open interoperability issuesPKIX has still open interoperability issues ISOish growth, very complex and genericISOish growth, very complex and generic Various PKIX profilesVarious PKIX profiles Very slow deploymentVery slow deployment
![Page 28: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/28.jpg)
28
Architecture?
The IETF has many security area WGs and The IETF has many security area WGs and some other WGs are addressing security some other WGs are addressing security issuesissues
But, they lack a consistent, comprehensive But, they lack a consistent, comprehensive architecture, e.g., many protocols overlap in architecture, e.g., many protocols overlap in functionality!functionality!
![Page 29: Internet Security – Where are we Heading?](https://reader035.fdocuments.us/reader035/viewer/2022062814/568167f6550346895ddd70d8/html5/thumbnails/29.jpg)
29
The future?