T-110.455 Network Application Frameworks and XML Security and Naming 9.3.2005 Sasu Tarkoma Based on slides by Pekka Nikander

1
T-110.455 Network Application Frameworks and
XML Security and Naming9.3.2005Sasu Tarkoma
Based on slides by Pekka Nikander
2
Contents

• Basic Security
• Review of network security
• Security in two flavours
• Managed opportunistic
• Layered-model revisited
• Names in Context
• Case Studies
• Summary

3
Core technologies
4
Short Review of Security

• Fundamentals
• Authentication
• Passwords, signatures, certificates
• Authorization
• Policies, certificates, Access Control Lists
  (ACL)
• Privacy
• Encryption
• Integrity
• Digests, hash functions
• Confidentiality
• Signatures

5
Policy vs. Mechanism

• Security policy
• A statement of what is and/or is not allowed.
• Policies can be abstract, informal, or very
  formal
• Requirements of a system
• Security mechanisms
• 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.

6
Correctness vs. Security

• Program correctness
• Program satisfies specification
• Program security
• 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

7
Basic Security Mechanisms

• Session protection integrity confidentiality
• IPsec AH ESP, TLS session protocol
• Key agreement
• IPsec IKEIKEv2, TLS key protocol
• Key distribution trust management
• X.509, SDSI/SPKI, KeyNote2
• Authorization
• X.509 Attribute Certificates, SAML XML
  authorization framework, XACML

8
Problems in security I

• Authentication
• collusion (keys get shared)
• identity theft
• Access control
• 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)

9
Problems in security II

• Authorization
• Management is challenging
• 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)

10
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 servers public key, asks for the response

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

12
Security IPsec

• IP Security (IPsec)
• End-to-end, below congestion control
• Authentication Header (AH)
• Integrity and authenticity
• Problems with NATs
• ESP (Encapsulating Security Payload)
• 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

13
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

14
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
• Host, server, trusted 3rd party
• Distribution of public keys
• On disk, email, directories, ..
• Revoking public keys
• Distribution of periodic revocation lists

15
PKI

• Public Key Infrastructure (PKI)
• Makes public keys available to applications
• Security operations encryption, digital
  signatures
• 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
• 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

16
Key Management

• Out of band key setup
• Can be used for some keys (Kerberos)
• Public-key infrastructure (PKI)
• 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

17
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

18
Needham-Schroeder Public Key Protocol
A key used once nonce
Every agent has a public key Ka and private key
Ka-1 The public keys of A and B are known
A
A
B
Result A and B share two numbers Numbers can be
used to compute a session key (concatenation,
XOR, ..)
19
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 Bs name to the second
  message --gt A will see a discrepancy

20
Diffie-Hellman Key Agreement
Vulnerable to man-in-the-middle
attack Authenticated DH requires digital
signatures and certificates
p is a prime and g is a generator of Zp, p and g
are public
A
B
Pick random a, K (gb mod p)a gab mod p
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
21
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))

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

23
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

24
Authorization

• Operating Systems tend to have more-or-less
  consistent authorization models
• Unix, Windows
• This hasnt really worked well for distributed
  systems
• 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

25
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
• 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
• ACs may be used for access control
• Short-lived ACs are not unusual (minimum 1
  second)
• Entities involved AC Issuer, AC Owner, AC
  verifier

26
Basic PMI Model
Source of Authority (Attribute Authority)
Privilege Verifier
Entity Privilege Holder
27
Delegation Model
Source of Authority
Attribute Authority
Privilege Verifier
Entity Privilege Holder
28
Kerberos

• Basic key management
• Two principals want to communicate
• Using a trusted third party
• 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
• Can be extended with public key cryptography
• Problems time-stamps guard against replay
  attacks but require time synchronization

29
AS
Ticket Granting Ticket (TGT). User decrypts
session key using password
TGS
Client
Request ticket for service. Authenticator
encrypted with session key.
Service decrypts session key using secret key and
reads the authenticator. Trust is established and
service can determine user rights..
Service ticket is decrypted. Ticket contains a
new session key shared by the user and the
service. The key is encrypted using both secret
keys.
Service
30
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

31
Managed security

• Requires security administration
• Distributes keys
• Defines policy
• Imposes a cost (to the defendant)

32
Traditional security structure
Trust and policy management
Session / connection level security
Communication infrastructure
33
Java Authentication and Authorization Service
(JAAS)
Java Secure Socket Extension (JSSE)
34
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

35
Authentication and KE

• Authentication
• challenge-response
• Key exchange
• Needham-Schroeder, Diffie-Hellman
• Authenticated key establishment
• 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

36
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

37
Weak Authentication Toolbox

• Spatial separation
• Ensure peer is reachable via a specific
  communications path
• Physical contact / network path / quality of path
• Single path / multiple paths
• Temporal separation
• Ensure peer is still the same peer
• Session / Inter-Session
• Asymmetric cost wars
• Scanning cost / attack cost / cost of revealing
  location
• Application semantics
• Cryptographic semantics of identifiers

38
WA Methods

• Challenge-Response (CR) Spatial
• Does node X receive packets sent to address A?
• E.g. SIP null authentication or Mobile IPv6
  Return Routability
• Anonymous Encryption (AE) Temporal, Cost
• Unauthenticated Diffie-Hellman
• Session is encrypted and integrity protected
• Leap of Faith (LoF) Temporal, Spatial, Cost
• 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 ltrouting prefixgt hash(PK)
• Private key can be used to prove I am the
  owner of the particular IPv6 Address

39
Security is cost wars

• Risk analysis --gt 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

40
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?

41
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

42
Naming, Addressing, and Routing
Public keys as names Security benefits
How to identify and name a node? Even if its
address changes.
NAMING
unicast to a specific node broadcast to all
nodes multicast to a subset of nodes anycast to
any one in some subset (IPv6)
ADDRESSING
ROUTING
How to route information to the nodes address?
Where is the node located?
43
The Starting Point
Object API
DNS names
Presentation
Firewall bypass
IP addresses
Congestion control
End-to-end
Routing
Routing paths
44
With Overlays
Upper layers
DNS names, custom identifiers
Overlay
Overlay addresses
Congestion
IP addresses
End-to-end
Routing
Routing paths
45
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 end-points (sockets) bound to
  identifiers

identifier
ID Layer
locator
46
With identity/locator split overlays?
CONTROL
Upper layers
DNS names, custom identifiers
Overlay
Overlay addresses
Host Identities
Congestion
IP addresses
ID Layer
IP addresses
End-to-end
DATA
Routing
Routing paths
Routing paths
47
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

48
Layered Naming Architecture

• Presented in paper
• A Layered Naming Architecture for the Internet,
  Balakrishnan et al. SIGCOMM 2004
• Service Identifiers (SIDs) are host-independent
  data names
• End-point Identifiers (EIDs) are
  location-independent host names
• Protocols bind to names and resolve them
• Applications use SIDs as handles
• SIDs and EIDs should be flat
• 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)

49
User level descriptors (search query..)
App session
App session
Transport
Transport
IP
IP
IP HDR
EID
TCP
SID
50
Summary

• Core Security
• Session security, key agreement
• The challenges
• protocol verification
• key distribution
• authorization
• Two flavours of security
• 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)