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.

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

Basic Security Mechanisms • Session protection: integrity & confidentiality • IPsec AH & ESP, TLS “session” protocol • Key agreement • IPsec IKE&IKEv2, TLS “key” protocol • Key distribution & trust management • X.509, SDSI/SPKI, KeyNote2 • Authorization • X.509: Attribute Certificates, SAML: XML authorization framework, XACML

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)

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)

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

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

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

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

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

{ A, NonceA }Kb { NonceA, B, NonceB }Ka { NonceB}Kb 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, ..)

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

ga mod p gb mod p 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

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 more-or-less consistent authorization models • Unix, Windows • This hasn’t 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

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

Assigns privilege Trusts Asserts Basic PMI Model Source of Authority (Attribute Authority) Entity Privilege Holder Privilege Verifier

Assigns privilege Trusts Asserts privilege (if authorised) Delegates privilege Asserts Delegation Model Source of Authority Attribute Authority Entity Privilege Holder Privilege Verifier

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

SHARED KEY KC I. Authenticate user II. Provide user credentials to access service/server SHARED KEY KS III. Provide credentials to server 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

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)

Host OS Host OS Application protocols Auth. protocol(s) Certificate repository Integration between host security and network security Traditional security structure Trust and policy management Session / connection level security Communication infrastructure

Arch. HIP Java Kerberos TSL+ HTTP HTTP IPsec TSL (X.509) X.509 X.509 X.509 X.509 - PKI - - pwd pwd N/A - + Authz. JAAS TSL JAAS pwd + Identity + + - + JSSE IPsec + TSL Session - - Java Authentication and Authorization Service (JAAS) Java Secure Socket Extension (JSSE)

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 • 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

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 • 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

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 = <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 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 node’s address? Where is the node located?

The Starting Point Object API DNS names Presentation Firewall bypass IP addresses Congestion control End-to-end Routing Routing paths

With Overlays Upper layers DNS names, custom identifiers Overlay Overlay addresses Congestion IP addresses End-to-end Routing Routing paths

Process Transport IP Layer Link Layer 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

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

Search returns SIDs Use SID as handle SIDs are resolved to EIDs Bind to EID Resolves EIDs to IP User level descriptors (search query..) App session App session Transport Transport IP IP IP HDR EID TCP SID

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)

Contents

Contents

Presentation Transcript

Contents

Contents

Contents

Contents

Contents

Contents

Contents

CONTENTS

Contents

Contents