Transcript Left Focus Test Slide

Internet Security –
Where are we Heading?
Wolfgang Schneider
GMD Darmstadt
Layered Approach to Security
Application Security
Network Security
Public Key
Infrastructure
Operating System Security
Physical Security
2
Types of Standards
Framework/
Architecture
High Level API
Protocols
Legal &
Regulatory
Low Level API
Algorithms
3
IETF Security
 Cornerstones:
 IP layer VPNs (IPsec)
 Secure web access (TLS)
 Secure E-mail (S/MIME)
 Public Key Infrastructure (PKIX)
 Plus XMLSIG, OPGP, SSH, CAT, DNSSEC, ...
4
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 antireplay
 Separate security association negotiation and key
management protocol: IKE
5
IPsec Path Options
Mobile
HOST
A
HOST 6
B
ROUTER 3
B
B
INTERNET
ROUTER 2
A
C
HOST 8
A
ROUTER 1
C
HOST 7
A
C
A
HOST 1
A
HOST 2
B
HOST 3
C
6
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
7
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
8
What’s Next for IPsec?





Standard policy language?
Inter-domain policy negotiation
Security gateway discovery
Public key certificate syntax conventions
Routing for VPNs
9
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
10
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
11
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
12
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 webbased 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
13
S/MIME Standards
 S/MIME v2 (RFC 2312)
 S/MIME v3 (RFC 2633)
 Cryptographic Message Syntax (RFC 2630)
 Certificate handling conventions (RFC 2312,
2632)
 Enhanced services (RFC 2634)
14
Internet Message Protocol Layers
Originator
Recipient
S/MIME
Content
S/MIME
Content
MIME
MIME
RFC 822
RFC 822
SMTP
Mail Routing
SMTP
SMTP
TCP
Transport
TCP
TCP
Transport Transport
IP
Network
Service
Host
IP
Network
Service
Router
IP
Network
Service
IP
Network
Service
Mail Relay Host
SMTP
TCP
Transport
IP
Network
Service
Host
15
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)
16
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
17
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
18
S/MIME Enhanced Security Services
 Optional features provide functionality similar
to 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
19
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, ...
20
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
21
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
22
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
23
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!
24
PKIX
 Certificate & CRL syntax and processing (RFC 2459)
 CMP - Certificate Management Protocols (RFC 2510)
 OCSP - Online Certificate Status Protocol (RFC
2560)
 CRMF – Cert Request Message Format (RFC 2511)
 Certification policies & practices (RFC 2527informational)
25
More PKIX
 LDAPv2 Schema & Operational Protocols
(RFC 2587 & 2559)
 HTTP/FTP Ops (RFC 2585)
 CMC – Cert Management Messages (RFC
xxxx)
 Qualified Certificates (RFC xxxx)
 Time stamping, notarization, ...
26
Still PKIX
 PKIX is now the basis of most major PKI
developments and deployments
 PKIX has still open interoperability issues
 ISOish growth, very complex and generic
 Various PKIX profiles
 Very slow deployment
27
Architecture?
 The IETF has many security area WGs and
some other WGs are addressing security
issues
 But, they lack a consistent, comprehensive
architecture, e.g., many protocols overlap in
functionality!
28
The future?
29