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

2. Contents n Basic Security u Review of network security n Security in two flavours u Managed & opportunistic n Layered-model revisited n Names in Context u Case Studies n Summary

3. SSL/TLS Kerberos IPSEC Integration Function Firewalls Security Cryptography Efficiency Certificate authorities Digital signatures Symmetric encr. X.509 certificates Public keys MACs and hashing Core technologies

4. Short Review of Security n Fundamentals u Authentication F Passwords, signatures, certificates u Authorization F Policies, certificates, Access Control Lists (ACL) u Privacy F Encryption u Integrity F Digests, hash functions u Confidentiality F Signatures

5. Policy vs. Mechanism n Security policy u A statement of what is and/or is not allowed. u Policies can be abstract, informal, or very formal u Requirements of a system n Security mechanisms u A procedure, tool or method of enforcing the policy n Trust that mechanisms work u Each mechanism implements a subset of the policy. u Union of all mechanisms implements full policy.

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

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

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

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

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

11. TLS / SSL II n 5. Optional reverse challenge n 6. Client and server agree to a shared secret for symmetric encryption. n 7. Session ID is agreed upon. n Note that steps 4-5 are processor intensive. One solutions: session ID is cached.

12. Security: IPsec n IP Security (IPsec) n End-to-end, below congestion control u Authentication Header (AH) F Integrity and authenticity F Problems with NATs u ESP (Encapsulating Security Payload) F Transport-mode: higher level payload host-to-host F Tunnel-mode: payload is IP packet network-to-network F Mostly in tunnel mode, VPNs n AH and ESP may be combined n Contains a complex policy control model n Does not work for IP control traffic

13. IKE n IPSec separates key management into IKE / IKE v2 n Security Association (SA) u relationship between two or more entities that describes how the entities will use security services to communicate securely n 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

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

15. PKI n Public Key Infrastructure (PKI) u Makes public keys available to applications F Security operations: encryption, digital signatures u PKIs integrate digital certificates, public-key cryptography, and certificate authorities into a total, enterprise-wide network security architecture u Key-pair is bound to an identifier in a way that makes it useful for applications n Public keys are about identification u And with the host/identity split they are also about naming n The identifier in this case uniquely specifies the entity within some context or environment u Does not need to reveal actual identity u Does not need to be global

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

17. Protocol Engineering n Engineering security protocols for open distributed environments is difficult u Man-in-the-middle attacks u Modification attacks u Replay attacks u Reflection attacks n Formal methods and empirical testing n Divide and conquer is essential to development u But common belief is that security properties do not compose

18. Needham-Schroeder Public Key Protocol AB { A, NonceA } Kb { NonceB} Kb { NonceA, B, NonceB } Ka Result: A and B share two numbers Numbers can be used to compute a session key (concatenation, XOR,..) A Every agent has a public key Ka and private key Ka -1 The public keys of A and B are known A key used once: nonce

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

20. Diffie-Hellman Key Agreement AB g a mod p g b mod p p is a prime and g is a generator of Z p *, p and g are public After KE A and B share g ab mod p not known to other parties Pick random a, K = (g b mod p) a = g ab mod p Pick random b, K = (g a mod p) b = g ab mod p Vulnerable to man-in-the-middle attack Authenticated DH requires digital signatures and certificates

21. Public-Key Certificates 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 n Certificate u is not secret u identifies the owner u contains the certified public-key u contains the validity period u may contain usage policy u may contain extension fields u is signed by a known authority (the Certification Authority (CA))

22. X.509 Certificates n X.509 is part of the X.500 series of standards for distributed directories defined by ISO/ITU-T n Defines Public Key Certificate (PKC) and Attribute Certificate (AC) data structures and semantics u Does not define supporting protocols n In 1995 an IETF working group (PKIX) was chartered to profile X.509 and to define supporting protocols n X.509 scope u Public-Key Infrastructure (PKI) u Privilege Management Infrastructure (PMI)

23. X.509 Public Key Certificate n X.509 certificate structure: u Version, serial number, signature parameters, certificate issuer, not before, not after, subject details, subject public key, extensions, signature n 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

24. Authorization n Operating Systems tend to have more- or-less consistent authorization models u Unix, Windows n This hasn’t really worked well for distributed systems u Subjects / objects / permissions do not map well to OS accounts u Distributed environments have their own challenges (and attacks) u Things get complex n Certificates for authorization u X.509 Attribute Certificate

25. X.509 Attribute Certificate n Mainline description is based on RFC3281 n Main idea is to have an AC issuer who encodes privileges and other attributes into an attribute certificate u Similar to X.509 PKC but with attributes instead of a public key u Well defined attributes include: Authentication Information, Identities (Access, Charging), Role, Group, Clearance n ACs may be used for access control u Short-lived ACs are not unusual (minimum 1 second) n Entities involved: AC Issuer, AC Owner, AC verifier

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

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

28. Kerberos n Basic key management u Two principals want to communicate u Using a trusted third party n Instead of a single trusted party Kerberos has u An authentication server (AS) u A ticket-granting server (TGS) u Scalable access management u Used in Windows 2000, Distributed Computing Environment (DCE),,,, n Basic version uses username/password u Can be extended with public key cryptography n Problems: time-stamps guard against replay attacks but require time synchronization

29. Client AS TGS Service I. Authenticate user II. Provide user credentials to access service/server III. Provide credentials to server Request ticket for service. Authenticator encrypted with session key. 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. SHARED KEY K C SHARED KEY K S Service decrypts session key using secret key and reads the authenticator. Trust is established and service can determine user rights.. Ticket Granting Ticket (TGT). User decrypts session key using password

30. Security in two flavours n Managed security u What is typically taught in security courses n Opportunistic security u Kind of economic warfare u Changes attacker/defendant cost ratio u Weak authentication security model

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

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

33. Arch.PKIAuthz.IdentitySessionTSLX.509N/A++HTTP-pwd-- TSL+ HTTP X.509pwdTSL IPsecX.509-++Kerberos-+pwd-JavaX.509JAAS JSSEHIP(X.509)-+IPsec Java Authentication and Authorization Service (JAAS) Java Secure Socket Extension (JSSE)

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

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

36. Weak Authentication n Jari Arkko & Pekka Nikander, Cambridge 2002 n Weak Authentication (WA) means cryptographically strong authentication between previously unknown parties without relying on trusted third parties n In some applications, imperfect security may be sufficient u Need to examine attack probabilities and economic impacts u Should be taken into account in protocol design

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

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

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

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

41. Architectural problems with current Internet naming n IP addresses are overloaded u Names of hosts (at socket API & transport) u Names of topological locations n DNS names are overloaded u Names of hosts (at application level) u Names of services u Also other ones

42. Naming, Addressing, and Routing NAMING ADDRESSINGROUTING How to identify and name a node? Even if its address changes. Where is the node located? How to route information to the node’s address? unicast: to a specific node broadcast: to all nodes multicast: to a subset of nodes anycast: to any one in some subset (IPv6) Public keys as names Security benefits

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

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

45. Process Transport ID Layer IP Layer Link Layer identifier locator n New name space for IDs u Maybe based on DNS u Maybe a separate namespace u Maybe IP addresses are used for location u Good for hiding IP versions n Communication end- points (sockets) bound to identifiers With identity/locator split

46. With identity/locator split + overlays? Upper layers Overlay Congestion End-to-end Routing Overlay addresses IP addresses Routing paths DNS names, custom identifiers Host Identities IP addresses Routing paths ID Layer CONTROL DATA

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

48. Layered Naming Architecture n Presented in paper: u A Layered Naming Architecture for the Internet, Balakrishnan et al. SIGCOMM 2004 n Service Identifiers (SIDs) are host-independent data names n End-point Identifiers (EIDs) are location- independent host names n Protocols bind to names and resolve them u Applications use SIDs as handles n SIDs and EIDs should be flat u Stable-bame principle: A stable name should not impose restrictions on the entity it names n Inspiration: HIP + i3 + Semantic Free Referencing n Prototype: Delegation Oriented Architecture (DOA)

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

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