IIW - User contributions [en]

Deadly Sins Distributed Authentication

2010-11-15T20:25:06Z

Hillbrad:

'''Title:''' 7 Deadly Sins of Distributed Authentication

'''Session:''' Wednesday, Session 5, A

'''Conference:''' [http://iiw.idcommons.net/Iiw11 IIW-11] November 2-4, Mountain View, [http://iiw.idcommons.net/Notes_IIW11 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

7 Deadly Sins of Distributed Authentication

2010-05-27T23:17:31Z

Hillbrad: Created page with '== Issue/Topic: 7 Deadly Sins of Distributed Authentication == '''Session: Day – Number - Space Location: Day 3 – Session 4 – Location A''' '''Convener: Brad Hill''' ...'

== Issue/Topic: 7 Deadly Sins of Distributed Authentication ==

'''Session: Day – Number - Space Location: Day 3 – Session 4 – Location A'''

'''Convener: Brad Hill'''

'''Notes-taker(s): Brad Hill'''

== A. Tags for the session - technology discussed/ideas considered: ==

Security, Security Flaws, Cryptography, Protocols, Implementation

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

iiw-common-problems-dist-authN@googlegroups.com

== B. Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps: ==

This session was based on the idea that the many common problems, protocols and implementations of distributed authentication and identity systems also lead to a common set of flaws, pitfalls and shortcomings. The goal was to propose a set of “most common mistakes”, in the spirit of the OWASP Top 10 Most Common Web Application Flaws, (http://www.owasp.org) to inform designers, implementers and deployers of these technologies on the informal security history and academic literature of similar technologies.

The discussion started with the following outline, supplied by Brad Hill:

'''7 Deadly Sins of Distributed Authentication:'''

'''1. Unconstrained Delegation'''
• Passwords
– Give them to somebody, they can use them to authenticate as you to anyone else.
• Bearer Tokens
– Message level security needs to have a target scope: Who was this artifact intended for?
• Kerberos Delegation v1
– Constrained sources, unconstrained targets for those sources. Abuse of “trusted subsystem” model.

'''2. Forwardable Credentials'''
• NTLM
– Not delegatable, definitely forwardable.
– Protocols that don’t provide server authentication or scope and verify artifacts are vulnerable.

'''3. No Channel Binding'''
• More sophisticated subset of credential forwarding.
• Auth the transport channel one-way
– Server to client (TLS)
– Auth inside the client the other way
– Client to server (NTLM, Kerberos bearer tokens, SAML)
– No binding between the two creates confused deputy possibility, forwarding.
• Possible even with client certs – recent renegotiation bug.

'''4. Bearer Tokens'''
• Yes, it matters
• Kerberos is a great example
– Mutual auth, strong crypto, key exchange
– Use it as a bearer token, it becomes vulnerable

'''5. Unscoped Authority'''
• Example: Boeing & Air Force federate
– Air Force wants to accept Boeing’s identity assertions
– Boeing should be able to assert joe@boeing.com
– NOT: admin@airforce.mil or joe@lockheed.com
– This is especially a big problem for systems that provide mutual authentication in a federated manner.
– Server names must be scoped!
• Kerberos SID Filtering

'''6. PKI, PKIX and SSL/TLS'''
• Problems of unscoped authority.
– Any public authority can assert any name.
– Can any PKIX roots assert enterprise or other non-public identities?
• Acceptance policies.
– Key usage, EKU, etc.
• Is this a server cert? A client cert?
– Algorithms, key strengths
• Trusting useless assertions
– NO ASSURANCE for client certs or server certs for non-public TLDs as of 2005-9.
• Wear a Belt & Suspenders for very high value services.
– e.g. Windows Update

'''7. No Upgrade Path'''
• Yes, adoption is important.
• Build a strong and a weak system
• Price them differently

'''Good Practices'''
• Scoped, self-describing artifacts
• Mutual authentication
• Forwarding-resistant credentials
• Channel binding
• Key agreement
• Proof-of-possession
• Incentives to use high assurance protocols

'''Implementation Gaffes'''
• Not verifying signatures.
– Trusting encryption when integrity is needed – e.g., in SAML messages.
<saml>
<encrypted> … </encrypted><yourPublicKey/>
<signed> … </signed><myPublicKey/>
</saml>

• Weak Crypto / Incorrect Crypto
– Stream ciphers. Don’t.
– Using RSA to Encrypt and Sign arbitrary data.
– ECB mode.
– Encryption without Integrity
• GUIDS, UUIDS and Randomness
– Just make it random unless you have a good reason why it shouldn’t be.
• Only need to seed and occasionally update PRNG with good randomness.
– Minute possibility of a collision in a 128 bit random space is exactly the guarantee you’re hanging your hat on.
– Old IETF draft of GUIDS not really that random – don’t use it.
• HMAC Verification Timing
– Don’t use a standard string or array comparison function to verify HMACs.
– They all short-circuit as soon as they find a mismatched character.
– Timing difference between good validation and bad validation.
• Brute force correct HMAC one character at a time.

C and machine language comparisons that look like constant time may be OK, but test. Java and .Net are subject to optimizations that make code that looks like it should produce constant time results not. Adding a randomized delay was suggested. Suggestions from the group for better algorithms included double-hashing the HMAC before comparing, or starting the comparison at a random location in the HMAC string.

Other proposed additions to the list of common sins included:

'''Key Distribution'''
• Administration
• Rollover
• Key Lifetime
• “Heavy” Keys

'''Failure to Manage the Ecosystem and Dependencies'''
• Verifying the implementation and policy of relying parties / consumers

'''Failure to Explicitly Distinguish Implementation vs. Policy'''
• Acceptance policy
• Issuance policy

'''“Writing Your Own”'''
• Developers have learned in the last 10 years they shouldn’t write their own crypto algorithms. Need to learn now that they shouldn’t write their own distributed authentication and identity protocols.
• IdPs and protocol implementers should provide and consumers should use standard libraries.
• Usability should focus on providing good APIs and libraries. Making a protocol that anyone can implement in Perl overnight should be a non-goal, or at least subordinate to making a protocol that gives participants strong security guarantees.

Significant interest was expressed, at least among the attendees at the session, in formalizing the discussion into a paper, including a good bibliography.

Google Group created to facilitate discussion around creation of such a paper, at:

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

iiw-common-problems-dist-authN@googlegroups.com

'''Suggested sources immediately relevant to the discussion included:'''

Ross Anderson - Robustness Principles for Public Key Protocols
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.44.3669

Martin Abadi and Roger Needham – Prudent Engineering Practice for Cryptographic Protocols
http://portal.acm.org/citation.cfm?id=229714

Carl Ellision and Bruce Schneier – Ten Risks of PKI
http://openweb.or.kr/10_risks_of_pki.pdf