T110 455 Network Application Frameworks and XML Security

T-110. 455 Network Application Frameworks and XML Security and Naming 9. 3. 2005 Sasu Tarkoma Based on slides by Pekka Nikander

Contents n Basic Security u n Security in two flavours u n n Managed & opportunistic Layered-model revisited Names in Context u n 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 n Fundamentals u Authentication F u Authorization F u Encryption Integrity F u Policies, certificates, Access Control Lists (ACL) Privacy F u Passwords, signatures, certificates Digests, hash functions Confidentiality F Signatures

Policy vs. Mechanism n Security policy u u u n Security mechanisms u n 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 u u Each mechanism implements a subset of the policy. Union of all mechanisms implements full policy.

Correctness vs. Security n Program correctness u n Program security u u n Program satisfies specification Properties preserved when attacked presence of malicious entities (adversaries) Security analysis u Need models F u u system, adversary Need to identify security properties The properties should be maintained even if attacked

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

Problems in security I n Authentication u u n Access control u u n collusion (keys get shared) identity theft collusion (keys get shared) naming attacks (DNS, DB corruptions) Protocol / mechanism failure u u Eavesdropping, sniffing, reflection Man-in-the-middle Design errors (logic errors) Network related problems (firewalls, NATs)

Problems in security II n Authorization u n Audit trail altered / overloaded u Access control / authentication failures New directions and challenges u Distributed systems (wide-area) u Multi-vendor application layer interoperability issues u Web Services (topic of next lectures) u n Management is challenging

TLS / SSL I n n n Connection-oriented protocol for application-layer sessions 1. SSL-protected page is opened 2, Client verifies server certificate. u Client must trust the certificate authority that signed the certificate. u CA public key installed in the browser 3. Server performs optional client authentication 4. Possession of private key is verified. u Client generates a challenge, encrypts it with the server’s public key, asks for the response

TLS / SSL II n n 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 n n IP Security (IPsec) End-to-end, below congestion control u Authentication Header (AH) F F u ESP (Encapsulating Security Payload) F F F n n n 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 n n IPSec separates key management into IKE / IKE v 2 Security Association (SA) u n relationship between two or more entities that describes how the entities will use security services to communicate securely Internet Key Exchange (IKE) u negotiates the IPSec security associations (SAs) u IKE creates an authenticated, secure tunnel u negotiates the security association for IPSec u authentication, establishment of shared keys

Public Key Systems n N entities requires O(N) asymmetric keys u u n Private key of X - Prv(A) Public key of X - Pub(a) Management issues u Creation of public/private key pairs F u Distribution of public keys F u Host, server, trusted 3 rd party On disk, email, directories, . . Revoking public keys F Distribution of periodic revocation lists

PKI n Public Key Infrastructure (PKI) u Makes public keys available to applications F u u n 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 u n 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 u u Does not need to reveal actual identity Does not need to be global

Key Management n Out of band key setup u n Public-key infrastructure (PKI) u n Can be used for some keys (Kerberos) Uses a small number of keys for signing certificates Protocols for session keys u u u Generate short-lived session keys Should avoid extended use of important secret Should not use the same key for encryption and signing

Protocol Engineering n Engineering security protocols for open distributed environments is difficult u u n n Man-in-the-middle attacks Modification attacks Replay attacks Reflection attacks Formal methods and empirical testing Divide and conquer is essential to development u 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, Nonce. A }Kb A { Nonce. A, B, Nonce. B }Ka B { Nonce. B}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. n Basic protocol is vulnerable to attacks u An intruder can convince B it is A F 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 a g 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 n n 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 u u u u 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 n n 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 u n n 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 u u Public-Key Infrastructure (PKI) Privilege Management Infrastructure (PMI)

X. 509 Public Key Certificate n X. 509 certificate structure: u n Version, serial number, signature parameters, certificate issuer, not before, not after, subject details, subject public key, extensions, signature Extensions u 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 n Operating Systems tend to have more-or -less consistent authorization models u n This hasn’t really worked well for distributed systems u u u n 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 u X. 509 Attribute Certificate

X. 509 Attribute Certificate n n Mainline description is based on RFC 3281 Main idea is to have an AC issuer who encodes privileges and other attributes into an attribute certificate u u n ACs may be used for access control u n 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 Entity Privilege Holder Trusts Asserts Privilege Verifier

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

Kerberos n Basic key management u u n Instead of a single trusted party Kerberos has u u n 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 u n 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 Ticket (TGT). User decrypts session key using I. Authenticate user password Client KC 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 n Managed security u n What is typically taught in security courses Opportunistic security u u u Kind of economic warfare Changes attacker/defendant cost ratio Weak authentication security model

Managed security n Requires security administration u u u Distributes keys Defines policy Imposes a cost (to the defendant)

Traditional security structure Trust and policy management Application protocols Host OS Auth. protocol(s) 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 IPsec X. 509 - Kerberos - Java HIP Identity Session + + Java Authentication and Authorization + pwd Service - (JAAS) X. 509 JAAS JSSE Java Secure Socket Extension (X. 509) - (JSSE) + IPsec

Lessons to learn n Hosts and network security poorly integrated u n n e. g. HTTPS + password based identification Host security model mostly based on accounts Authorization is the real problem u Authorization without identification is ok

Authentication and KE n Authentication u n Key exchange u n Needham-Schroeder, Diffie-Hellman Authenticated key establishment u u n challenge-response key exchange protocol that provides key authentication The other party confirms possession of the private key Authenticated key establishment with entity authentication u u Private key possession is confirmed Identity of entity is also confirmed

Weak Authentication n 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 u u Need to examine attack probabilities and economic impacts Should be taken into account in protocol design

Weak Authentication Toolbox n Spatial separation u u u n Temporal separation u u n Ensure peer is still the same peer Session / Inter-Session Asymmetric cost wars u n 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 u Cryptographic semantics of identifiers

WA Methods n Challenge-Response (CR) – Spatial u u n Anonymous Encryption (AE) – Temporal, Cost u u n Unauthenticated Diffie-Hellman Session is encrypted and integrity protected Leap of Faith (Lo. F) – Temporal, Spatial, Cost u u u n Does node X receive packets sent to address A? E. g. SIP null authentication or Mobile IPv 6 Return Routability At first usage, an unauthenticated key agreement Subsequent connections authenticated using these keys E. g. SSH, HIP Cryptographically Generated Addresses – Spatial, Application u u u Part of an address is a hash of a public key IPv 6 Address = <routing prefix> | hash(PK) Private key can be used to prove I am the “owner” of the particular IPv 6 Address

Security is cost wars n n Risk analysis --> cost of attack / cost of defence Security management imposes a cost u u n Mandatory for high security apps like banking Probably too high for low security apps like email Opportunistic / weak security costs only during development time u Deployment cost is close to zero

Names in context n A name should be… u u n Unique within its context Resolvable “Identification” seems to imply u Authenticity F But to whom or with respect to what?

Architectural problems with current Internet naming n IP addresses are overloaded u u n Names of hosts (at socket API & transport) Names of topological locations DNS names are overloaded u u u 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 (IPv 6) 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 paths

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

With identity/locator split n New name space for IDs u u n 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 DATA Routing paths

Overlay Security Considerations Revisited n Malicious nodes u u Attacker floods DHT with data Attacker returns incorrect data F u n n self-authenticating data Attacker denies data exists or supplies incorrect routing info Basic solution: using redundancy What if attackers have quorum? u u Need a way to control creation of node Ids Solution: secure node identifiers F Use public keys

Layered Naming Architecture n Presented in paper: u n n n Service Identifiers (SIDs) are host-independent data names End-point Identifiers (EIDs) are locationindependent host names Protocols bind to names and resolve them u n n Applications use SIDs as handles SIDs and EIDs should be flat u n 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 + i 3 + Semantic Free Referencing Prototype: Delegation Oriented Architecture (DOA)

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

Summary n Core Security u u Session security, key agreement The challenges: F F F n Two flavours of security u u n protocol verification key distribution authorization Managed & opportunistic (“weak”) “weak” is important for Do. S protection Naming is an architectural problem u u One or two new name spaces? Public keys for nodes (host identities)