7 Deadly Sins of Distributed Authentication

From IIW

Session: Wed Session 4 Space A

Conference: IIW 10 May 17-19, 2009 this is the complete Complete Set of Notes

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

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

2. Forwardable Credentials

  1. NTLM
  2. Not delegatable, definitely forwardable.
  3. Protocols that don’t provide server authentication or scope and verify artifacts are vulnerable.

3. No Channel Binding

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

4. Bearer Tokens

  1. Yes, it matters
  2. Kerberos is a great example
  3. Mutual auth, strong crypto, key exchange
  4. Use it as a bearer token, it becomes vulnerable

5. Unscoped Authority

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

6. PKI, PKIX and SSL/TLS

  1. Problems of unscoped authority.
  2. Any public authority can assert any name.
  3. Can any PKIX roots assert enterprise or other non-public identities?
  4. Acceptance policies.
  5. Key usage, EKU, etc.
  6. Is this a server cert? A client cert?
  7. Algorithms, key strengths
  8. Trusting useless assertions
  9. NO ASSURANCE for client certs or server certs for non-public TLDs as of 2005-9.
  10. Wear a Belt & Suspenders for very high value services.
  11. e.g. Windows Update

7. No Upgrade Path

  1. Yes, adoption is important.
  2. Build a strong and a weak system
  3. Price them differently

Good Practices

  1. Scoped, self-describing artifacts
  2. Mutual authentication
  3. Forwarding-resistant credentials
  4. Channel binding
  5. Key agreement
  6. Proof-of-possession
  7. Incentives to use high assurance protocols

Implementation Gaffes

  1. Not verifying signatures.
  2. Trusting encryption when integrity is needed – e.g., in SAML messages.

<saml> <encrypted> … </encrypted><yourPublicKey/> <signed> … </signed><myPublicKey/> </saml>

  1. Weak Crypto / Incorrect Crypto
  2. Stream ciphers. Don’t.
  3. Using RSA to Encrypt and Sign arbitrary data.
  4. ECB mode.
  5. Encryption without Integrity
  6. GUIDS, UUIDS and Randomness
  7. Just make it random unless you have a good reason why it shouldn’t be.
  8. Only need to seed and occasionally update PRNG with good randomness.
  9. Minute possibility of a collision in a 128 bit random space is exactly the guarantee you’re hanging your hat on.
  10. Old IETF draft of GUIDS not really that random – don’t use it.
  11. HMAC Verification Timing
  12. Don’t use a standard string or array comparison function to verify HMACs.
  13. They all short-circuit as soon as they find a mismatched character.
  14. Timing difference between good validation and bad validation.
  15. 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

  1. Administration
  2. Rollover
  3. Key Lifetime
  4. “Heavy” Keys

Failure to Manage the Ecosystem and Dependencies

  1. Verifying the implementation and policy of relying parties / consumers

Failure to Explicitly Distinguish Implementation vs. Policy

  1. Acceptance policy
  2. Issuance policy

“Writing Your Own”

  1. 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.
  2. IdPs and protocol implementers should provide and consumers should use standard libraries.
  3. 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

Retrieved from "https://iiw.idcommons.net/index.php?title=7_Deadly_Sins_of_Distributed_Authentication&oldid=3466"