Transcript T-110.455 Network Application Frameworks and XML Security and

T-110.455 Network Application
Frameworks and XML
Security and Naming
9.3.2005
Sasu Tarkoma
Based on slides by Pekka Nikander
Contents

Basic Security


Security in two flavours



Managed & opportunistic
Layered-model revisited
Names in Context


Review of network security
Case Studies
Summary
Efficiency
Certificate authorities
Digital signatures
Symmetric encr.
Cryptography
X.509 certificates
Public keys
Security
MACs and hashing
Core technologies
Integration
Function
Firewalls
SSL/TLS
Kerberos
IPSEC
Short Review of Security

Fundamentals

Authentication


Authorization


Encryption
Integrity


Policies, certificates, Access Control Lists
(ACL)
Privacy


Passwords, signatures, certificates
Digests, hash functions
Confidentiality

Signatures
Policy vs. Mechanism

Security policy




Security mechanisms


A statement of what is and/or is not allowed.
Policies can be abstract, informal, or very
formal
Requirements of a system
A procedure, tool or method of enforcing the
policy
Trust that mechanisms work


Each mechanism implements a subset of the
policy.
Union of all mechanisms implements full
policy.
Correctness vs. Security

Program correctness


Program security



Program satisfies specification
Properties preserved when attacked
presence of malicious entities (adversaries)
Security analysis

Need models



system, adversary
Need to identify security properties
The properties should be maintained even if
attacked
Basic Security Mechanisms

Session protection: integrity &
confidentiality


Key agreement


IPsec IKE&IKEv2, TLS “key” protocol
Key distribution & trust management


IPsec AH & ESP, TLS “session” protocol
X.509, SDSI/SPKI, KeyNote2
Authorization

X.509: Attribute Certificates, SAML: XML
authorization framework, XACML
Problems in security I

Authentication



Access control



collusion (keys get shared)
identity theft
collusion (keys get shared)
naming attacks (DNS, DB corruptions)
Protocol / mechanism failure




Eavesdropping, sniffing, reflection
Man-in-the-middle
Design errors (logic errors)
Network related problems (firewalls, NATs)
Problems in security II

Authorization


Audit
Audit trail altered / overloaded
 Access control / authentication failures
New directions and challenges
 Distributed systems (wide-area)
 Multi-vendor application layer interoperability
issues
 Web Services (topic of next lectures)


Management is challenging
TLS / SSL I





Connection-oriented protocol for
application-layer sessions
1. SSL-protected page is opened
2, Client verifies server certificate.
 Client must trust the certificate
authority that signed the certificate.
 CA public key installed in the browser
3. Server performs optional client
authentication
4. Possession of private key is verified.
 Client generates a challenge,
encrypts it with the server’s public
key, asks for the response
TLS / SSL II




5. Optional reverse challenge
6. Client and server agree to a shared
secret for symmetric encryption.
7. Session ID is agreed upon.
Note that steps 4-5 are processor
intensive. One solutions: session ID is
cached.
Security: IPsec


IP Security (IPsec)
End-to-end, below congestion control

Authentication Header (AH)



ESP (Encapsulating Security Payload)






Integrity and authenticity
Problems with NATs
Transport-mode: higher level payload
• host-to-host
Tunnel-mode: payload is IP packet
• network-to-network
Mostly in tunnel mode, VPNs
AH and ESP may be combined
Contains a complex policy control model
Does not work for IP control traffic
IKE


IPSec separates key management into
IKE / IKE v2
Security Association (SA)


relationship between two or more entities that
describes how the entities will use security
services to communicate securely
Internet Key Exchange (IKE)

negotiates the IPSec security associations
(SAs)

IKE creates an authenticated, secure tunnel

negotiates the security association for IPSec

authentication, establishment of shared keys
Public Key Systems

N entities requires O(N) asymmetric keys



Private key of X - Prv(A)
Public key of X - Pub(a)
Management issues

Creation of public/private key pairs


Distribution of public keys


Host, server, trusted 3rd party
On disk, email, directories, ..
Revoking public keys

Distribution of periodic revocation lists
PKI

Public Key Infrastructure (PKI)

Makes public keys available to applications




PKIs integrate digital certificates, public-key
cryptography, and certificate authorities into a total,
enterprise-wide network security architecture
Key-pair is bound to an identifier in a way that
makes it useful for applications
Public keys are about identification


Security operations: encryption, digital signatures
And with the host/identity split they are also about
naming
The identifier in this case uniquely
specifies the entity within some context
or environment


Does not need to reveal actual identity
Does not need to be global
Key Management

Out of band key setup


Public-key infrastructure (PKI)


Can be used for some keys (Kerberos)
Uses a small number of keys for signing
certificates
Protocols for session keys



Generate short-lived session keys
Should avoid extended use of important
secret
Should not use the same key for encryption
and signing
Protocol Engineering

Engineering security protocols for open
distributed environments is difficult






Man-in-the-middle attacks
Modification attacks
Replay attacks
Reflection attacks
Formal methods and empirical testing
Divide and conquer is essential to
development

But common belief is that security properties
do not compose
Needham-Schroeder Public Key Protocol
-1
Every agent has a public
key
Ka
and
private
key
Ka
A key used once: nonce
The public keys of A and B are known
{ A, NonceA }Kb
A
{ NonceA, B, NonceB }Ka
B
{ NonceB}Kb
Result: A and B share two numbers
Numbers can be used to compute a session key
(concatenation, XOR, ..)
Needham-Schroeder Public
Key Protocol cont.

Basic protocol is vulnerable to attacks

An intruder can convince B it is A

May be fixed by adding B’s name to the
second message --> A will see a discrepancy
Diffie-Hellman Key
Agreement
*, p and g are public
Vulnerable
p is a prime and g is a generator
of Zpto
man-in-the-middle attack
Authenticated
DH requires
ga mod p
digital signatures and
certificates
A
Pick random a,
K = (gb mod p)a = gab mod p
gb mod p
B
Pick random b,
K = (ga mod p)b = gab mod p
After KE A and B share gab mod p not known to other parties
Public-Key Certificates


A public-key certificate is an official
document that stands to authenticate the
binding of a particular entity with the
public-key identified in the certificate
Certificate







is not secret
identifies the owner
contains the certified public-key
contains the validity period
may contain usage policy
may contain extension fields
is signed by a known authority (the
Certification Authority (CA))
X.509 Certificates


X.509 is part of the X.500 series of
standards for distributed directories
defined by ISO/ITU-T
Defines Public Key Certificate (PKC) and
Attribute Certificate (AC) data structures and
semantics



Does not define supporting protocols
In 1995 an IETF working group (PKIX) was
chartered to profile X.509 and to define
supporting protocols
X.509 scope


Public-Key Infrastructure (PKI)
Privilege Management Infrastructure (PMI)
X.509 Public Key Certificate

X.509 certificate structure:


Version, serial number, signature parameters,
certificate issuer, not before, not after, subject
details, subject public key, extensions,
signature
Extensions

Authority key identifier, subject key identifier,
key usage, extended key usage, CRL
distribution point, certificate policies, policy
mapping, subject alternative name, issuer
alternative name, subject directory attributes,,
basic constraints, path length constraints,
name constraints, policy constraints
Authorization

Operating Systems tend to have moreor-less consistent authorization models


This hasn’t really worked well for
distributed systems




Unix, Windows
Subjects / objects / permissions do not map well to
OS accounts
Distributed environments have their own
challenges (and attacks)
Things get complex
Certificates for authorization

X.509 Attribute Certificate
X.509 Attribute Certificate


Mainline description is based on RFC3281
Main idea is to have an AC issuer who encodes
privileges and other attributes into an attribute
certificate



ACs may be used for access control


Similar to X.509 PKC but with attributes instead of
a public key
Well defined attributes include: Authentication
Information, Identities (Access, Charging), Role,
Group, Clearance
Short-lived ACs are not unusual (minimum 1
second)
Entities involved: AC Issuer, AC Owner,
AC verifier
Basic PMI Model
Source of Authority
(Attribute Authority)
Assigns privilege
Trusts
Asserts
Entity
Privilege Holder
Privilege Verifier
Delegation Model
Source of Authority
Assigns privilege
Attribute Authority
Asserts privilege
(if authorised)
Trusts
Delegates privilege
Asserts
Entity
Privilege Holder
Privilege Verifier
Kerberos

Basic key management



Instead of a single trusted party Kerberos has





An authentication server (AS)
A ticket-granting server (TGS)
Scalable access management
Used in Windows 2000, Distributed Computing
Environment (DCE), ,,,
Basic version uses username/password


Two principals want to communicate
Using a trusted third party
Can be extended with public key cryptography
Problems: time-stamps guard against replay
attacks but require time synchronization
Ticket Granting SHARED KEY KC
Ticket (TGT).
User decrypts
session key using
I. Authenticate user
password
Client
II. Provide user
credentials to
access
service/server
Request ticket for
service.
Authenticator
encrypted
with ticket is
Service
III. Provide
sessiondecrypted.
key.
Ticket
contains a newcredentials
session
to
key shared by server
the user
and the service. The key
is encrypted using both
secret keys.
AS
TGS
SHARED
KEY KS
Service decrypts session
key using secret key and
reads the authenticator.
Trust is established and
Serviceservice can determine
user rights..
Security in two flavours

Managed security


What is typically taught in security courses
Opportunistic security



Kind of economic warfare
Changes attacker/defendant cost ratio
Weak authentication security model
Managed security

Requires security administration



Distributes keys
Defines policy
Imposes a cost (to the defendant)
Traditional security structure
Trust and policy management
Application
Auth.
protocols protocol(s)
Host OS
Certificate
repository
Session / connection level security
Host OS
Communication infrastructure
Integration between host security and network security
Arch.
PKI
Authz.
TSL
X.509
N/A
+
+
HTTP
-
pwd
-
-
TSL+
HTTP
X.509
pwd
TSL
TSL
IPsec
X.509
-
Kerberos
-
Java
HIP
Identity Session
+
+
Java Authentication and
Authorization
+
pwd Service
- (JAAS)
X.509
JAAS
JAAS
JSSE
Java Secure Socket Extension
(X.509)
- (JSSE) +
IPsec
Lessons to learn

Hosts and network security poorly
integrated



e.g. HTTPS + password based identification
Host security model mostly based on
accounts
Authorization is the real problem

Authorization without identification is ok
Authentication and KE

Authentication


Key exchange


Needham-Schroeder, Diffie-Hellman
Authenticated key establishment



challenge-response
key exchange protocol that provides key
authentication
The other party confirms possession of the
private key
Authenticated key establishment with
entity authentication


Private key possession is confirmed
Identity of entity is also confirmed
Weak Authentication



Jari Arkko & Pekka Nikander, Cambridge
2002
Weak Authentication (WA) means
cryptographically strong authentication
between previously unknown parties
without relying on trusted third parties
In some applications, imperfect security
may be sufficient


Need to examine attack probabilities and
economic impacts
Should be taken into account in protocol
design
Weak Authentication Toolbox

Spatial separation




Temporal separation



Ensure peer is still the same peer
Session / Inter-Session
Asymmetric cost wars


Ensure peer is reachable via a specific
communications path
Physical contact / network path / quality of
path
Single path / multiple paths
Scanning cost / attack cost / cost of revealing
location
Application semantics

Cryptographic semantics of identifiers
WA Methods

Challenge-Response (CR) – Spatial



Anonymous Encryption (AE) – Temporal, Cost



Unauthenticated Diffie-Hellman
Session is encrypted and integrity protected
Leap of Faith (LoF) – Temporal, Spatial, Cost




Does node X receive packets sent to address A?
E.g. SIP null authentication or Mobile IPv6 Return
Routability
At first usage, an unauthenticated key agreement
Subsequent connections authenticated
using these keys
E.g. SSH, HIP
Cryptographically Generated Addresses – Spatial,
Application



Part of an address is a hash of a public key
IPv6 Address = <routing prefix> | hash(PK)
Private key can be used to prove I am the
“owner” of the particular IPv6 Address
Security is cost wars


Risk analysis --> cost of attack / cost of
defence
Security management imposes a cost



Mandatory for high security apps like banking
Probably too high for low security apps like
email
Opportunistic / weak security costs only
during development time

Deployment cost is close to zero
Names in context

A name should be…



Unique within its context
Resolvable
“Identification” seems to imply

Authenticity

But to whom or with respect to what?
Architectural problems with
current Internet naming

IP addresses are overloaded



Names of hosts (at socket API & transport)
Names of topological locations
DNS names are overloaded



Names of hosts (at application level)
Names of services
Also other ones
Naming, Addressing, and Routing
Public keys as names
Security benefits
How to identify and
NAMING name a node? Even
if its address
changes.
unicast: to a specific node
broadcast: to all nodes
multicast: to a subset of nodes
anycast: to any one in some subset (IPv6)
ADDRESSING
Where is the node
located?
ROUTING
How to route
information to the
node’s address?
The Starting Point
Object API
Presentation
DNS names
Firewall bypass
Congestion control
End-to-end
IP addresses
Routing
Routing paths
With Overlays
Upper layers
DNS names, custom
identifiers
Overlay
Overlay addresses
Congestion
End-to-end
Routing
IP addresses
Routing paths
With identity/locator split

New name space for IDs





Maybe based on DNS
Maybe a separate
namespace
Maybe IP addresses are
used for location
Good for hiding IP versions
Communication endpoints (sockets) bound to
identifiers
Process
Transport
identifier
ID Layer
IP Layer
Link Layer
locator
With identity/locator split +
overlays?
Upper layers
Overlay
CONTROL
DNS names, custom
identifiers
Overlay addresses
Congestion
End-to-end
Routing
Host Identities
ID Layer
IP addresses
IP addresses
DATA
Routing paths
Routing paths
Overlay Security
Considerations Revisited

Malicious nodes


Attacker floods DHT with data
Attacker returns incorrect data




self-authenticating data
Attacker denies data exists or supplies
incorrect routing info
Basic solution: using redundancy
What if attackers have quorum?


Need a way to control creation of node Ids
Solution: secure node identifiers

Use public keys
Layered Naming Architecture

Presented in paper:




Service Identifiers (SIDs) are host-independent
data names
End-point Identifiers (EIDs) are locationindependent host names
Protocols bind to names and resolve them



Applications use SIDs as handles
SIDs and EIDs should be flat


A Layered Naming Architecture for the Internet,
Balakrishnan et al. SIGCOMM 2004
Stable-bame principle: A stable name should not
impose restrictions on the entity it names
Inspiration: HIP + i3 + Semantic Free
Referencing
Prototype: Delegation Oriented Architecture
(DOA)
User level descriptors (search query..)
Search returns SIDs
Use SID as handle
App session
App session
SIDs are resolved to EIDs
Bind to EID
Transport
Transport
Resolves EIDs to IP
IP
IP HDR
EID
TCP
SID
IP
Summary

Core Security


Session security, key agreement
The challenges:




Two flavours of security



protocol verification
key distribution
authorization
Managed & opportunistic (“weak”)
“weak” is important for DoS protection
Naming is an architectural problem


One or two new name spaces?
Public keys for nodes (host identities)