There's a subtle problem with your question, which is that the term "CSPRNG" is a little bit vague. There are two common kinds of applications for (pseudo)random generators in cryptography:
- Two parties need to make deterministic, reproducible choices that appear random to a third party.
- One party needs to make a nondeterministic, irreproducible choices that appear random to any other party.
Situation #1 properly requires cryptographic-strength pseudorandomness (a pseudorandom generator, pseudorandom function, pseudorandom permutation); if you used a true random number generator in its place such an application would not work.
Situation #2's requirements on the other hand could be fulfilled with a true random number generator, but in practice we normally use designs that incorporate pseudorandom generators for engineering reasons. Such generators typically use a #1-type algorithm as an internal component, but provide additional security features that are inapplicable or fatal for situation #1:
- Forward secrecy: ensuring that compromises of the RNG state cannot be used to backtrack to earlier outputs.
- Prediction resistance: ensuring that compromises of the RNG state can only predict its future output during a limited time window. This is normally accomplished by sampling random data (e.g., keyboard timings) and scrambling the RNG's state with it.
Assuming we only talk about cryptographically secure block ciphers; can any block cipher in CTR mode be used as a CSPRNG? Or are there specific characteristics a block cipher should have to be used as such?
Any secure block cipher in CTR mode will give you a generator that's suitable for situation #1.
Can such a CSPRNG be used to produce key material, or do I have to specifically use a key generation/derivation algorithm for that purpose?
Producing master key material is situation #2; you could substitute a true random generator and the system would still work. So a block cipher in CTR mode, seeded with a random key, meets the minimal requirements but is not the best solution. You should prefer the sort of random number generators that OSes incorporate, with the additional security features.
Again, rule of thumb: would this application work just as correctly with a true random generator? In that case, you don't really want a pseudorandom generator—you want a good surrogate for a true RNG, which is allowed but not required to use pseudorandomness.