Deadly Sins Distributed Authentication

Title: 7 Deadly Sins of Distributed Authentication

Session: Wednesday, Session 5, A

Conference: IIW-11 November 2-4, Mountain View, Complete Notes Page

Convener, Note Taker: Brad Hill

7 Deadly Sins of Identity and Authentication Systems The “OWASP Top 10” of what we do at IIW. IANAC High school calculus was my last math class

I am an engineer/nerd who understands the properties of some crypto primitives, and a little bit about how they combine and compose.

I’ve seen a lot of mistakes and read about even more. Focus on protocol / artifact flaws Not governance, policy, key management, ecosystem issues

These are universal and unavoidable challenges, not flaws Background Reading: Classics Prudent Engineering Practice for Cryptographic Protocols Abadi and Needham, 1995 Robustness Principles for Public Key Protocols Anderson and Needham, 1995 Programming Satan’s Computer Anderson and Needham, 1995 Authentication in Distributed Systems: Theory and Practice Lampson, Abadi, Burrows and Wobbler, 1992

Background Reading: Post WWW Ten Risks of PKI: What You’re not Being Told about Public Key Infrastructure Ellison and Schneier, 2000 Ceremony Design and Analysis Ellison, 2008 Defective Sign & Encrypt in S/MIME, �PKCS#7, MOSS, PEM, PGP, and XML Don Davis, 2001

Background Reading: �Higher notation tolerance necessary Using encryption for authentication in large networks of computers Needham and Schroeder, 1978 Trust Relationships in Secure Systems – A Distributed Authentication Perspective Yahalom, Klein and Beth, 1993 A taxonomy of Replay Attacks Syverson, 1994 Some New Attacks upon Security Protocols Lowe, 1996 Federated Identity-Management Protocols (Transcript of Discussion) Pfitzmann, 2005 Background Reading: Books Cryptography Engineering: Design Principles and Practical Applications Ferguson, Schneier and Kohno, 2010 Security Engineering: A Guide to Building Dependable Distributed Systems Anderson, 2008 Network Security: Private Communications in a Public World (2nd edition) Kaufman, Perlman and Speciner, 2002 More formal papers of special interest New Proofs for NMAC sand HMAC: Security without Collision-Resistance Bellare, 2006 On the Security of Joint Signature and Encryption An, Dodis and Rabin, 2002 Authenticated Encryption: Relations among notions and analysis of the generic composition paradigm Bellare and Namprempre, 2007 The 7 Deadly Sins Unconstrained Delegation Unbound Composition of Transport and Message Security Un-Scoped or Over-Scoped Authority PKI, PKIX and SSL/TLS Dependencies Impedance Mismatch in Identity Contexts DoS and Confused Deputies in Revocation and Key Retrieval False Dilemmas in Adoption vs. Assurance 1. Unconstrained Delegation Failure of least privilege Username / Password Don’t just replace it with a “token” with mostly equivalent properties. Specify a target set against which the credential is valid Delegate privileges or capabilities, not identities Identify and audit delegate as well as delegating principal Accommodate attributed re-delegation Prefer holder-of-key proof to bearer tokens

2: Unbound Composition of Transport and Message Security “Mixed-mode” or “Message Credential with Transport Security” Server Auth TLS + a client token

“While encryption guarantees confidentiality and authenticity, it also serves in binding together the parts of a message: receiving {X, Y}K is not always the same as receiving {X}K and {Y}K.” - Abadi & Needham, ’95 Forwarding attacks possible TLS validation is incorrect or absent Mismatched scope NTLM over HTTPS X.509 tokens without an AppliesTo Multiple server identities Kerberos SPN specified in WSDL Renegotiation attacks with client certs in TLS

Example Forwarding Attack:�WS-Security Kerberos Tokens over TLS Scoped to a particular server, negotiates key material, requires holder-of-key proof by client Still vulnerable…

Alice retrieves WSDL from Mallory Mallory’s WSDL says her SPN is Bob Alice gets Kerberos ticket for Bob Alice verifies Mallory’s TLS server cert, sends ticket with signature over a timestamp Mallory connects as a client to Bob, forwards ticket with signature and new message body Forwarding Attack Solutions Service Binding AppliesTo header – copy the TLS subject name here Use for both symmetric and symmetric credentials as per our Kerberos example AudienceRestriction Other indication in token of intended target Channel Binding Include a property of the outer channel as a signed attribute of the inner token (RFC 5056) 3: Un-Scoped or Over-Scoped Authority Not often a problem in Internet-scale systems PKIX is the BIG exception. Global CAs have terrible name-collision properties. Certs for non-unique names, IP addresses, etc. Any authority valid for every name Often a problem in enterprise and federation Can the Boeing.com STS assert identities in “@airforce.mil”? What about “@airbus.com”? What about server names? Solutions: SID Filtering in Active Directory Apply a scope or bailiwick for every counterparty Make this a mandatory part of establishing a trust

Language: Configuring a “trusted partner” implies too much I prefer “federation counterparty”

4. PKI, PKIX and SSL/TLS Dependencies We all hate it here at IIW. But it is the one universal Internet-scale identity system, and one that is also widespread at big organizations Interop is a tempting target But it is more complex… OID extensions, constraints, KU, EKU And less trustworthy than you think Non unique names Negligent and Bad actors No assurance for client certs 4. PKI, PKIX and SSL/TLS Dependencies Problems with Production / Non-Production systems We don’t want to spend the money for certs for our development, test and acceptance environment We don’t want to or don’t know how to set up our own authority (Wrong) Solutions? Turn off validation (and forget to turn it back on) Use same keys for all environments (no separation of duties) 5. Impedance Mismatch in Identity Contexts How granular is an identity?

When you interoperate or cross-contexts with different scopes, how do you normalize this?

6. Denial-of-Service and Confused Deputy Attacks with Revocation and Key Retrieval Good: My key is the entire content of a resource at this anonymously accessible HTTPS URL

Bad: My key is the result of the following XSLT transformation at \\192.168.1.99\c$\foo\bar 7. False Dilemmas in Adoption vs. Assurance Bearer Tokens vs. Holder-of-Key

Because having to “find, install and configure libraries” is too hard for developers, compared to “the convenience and ease offered by simply using passwords.” (from the intro to OAuth 2 page)

Is crypto “too hard”? Not too hard then… Too hard now? Canonicalization and Transformation is Hard, Basic Signature Ops Aren’t Canonicalization was what made XML DSIG and OAuth 1.0 difficult, not hashing and crypto Strange but true – building a lenient parser seems to be easier than building a strict serializer. See, e.g. “the Web”.

The “See what is seen” idea in XML DSIG that led to XSLT and related functionality is also a misplaced responsibility Canonicalize as little as necessary Extreme C14N is often a layering violation. Cryptographic primitives can provide confidentiality, guarantee authenticity, bind together the parts of a message and serve in producing random numbers

Ensuring that every well-formed message has an unambiguous meaning is the responsibility of the protocol or message layer, not of the cryptographic primitive. The elements of the crypto protocol itself may require careful treatment to avoid type flaws. But the payload should be opaque.

7. False Dilemmas in Adoption vs Assurance, continued The ideal: “There is one mode, and it is secure.” – Ian Grigg

The reality: “Something’s gotta give.” (and guess which one will)

Solution: Build Two Protocols and Incentivize Low friction protocol for easy onboarding

Encourage self sorting of higher value clients to the higher assurance protocol Provide higher value services or assertions Set different price points Examples: SXIP, Google Checkout

TWO protocols, not one protocol with complex options or NegOtiated security

Extra Time: Implementation Foibles Poor 3rd-party token storage (cookies, GET urls, unencrypted at rest) Decrypting tokens but not verifying signatures. Common for encrypted SAML messages HMAC verification timing brute-force Encryption without integrity Mentioned last time – now padding oracle attacks have gone mainstream

http://groups.google.com/group/iiw-common-problems-dist-authN brad@isecpartners.com