Why does NIST SP 800 `KDF in Counter Mode' specification require a PRF rather than a PRP?

Question

This is the NIST SP 800 KDF in Counter Mode specification.

Where $K_I$ is the input key, $[i]_2$ is the counter value, Label and Context are fixed-length strings and $[L]_2$ is the output size, the input to the PRF for each block $i\in n$ is as follows

$$K(i) := \operatorname{PRF} (K_I, [i]_2 \mathbin\Vert \mathit{Label} \mathbin\Vert \mathrm{0x00} \mathbin\Vert \mathit{Context} \mathbin\Vert [L]_2)$$

I'm trying to understand why

this Recommendation approves the use of either the keyed-hash Message Authentication Code (HMAC) specified in [8] or the cipher-based Message Authentication Code (CMAC) specified in [7] as the pseudorandom function.

Why not just use a straightforward PRP like AES here? Provided the fixed input data is of the correct width, I don't see why the complexity of using i.e. a CMAC PRF is being added to the construction.

Moreover, looking at the NIST CMAC specification and adapting it for one-block fixed-length inputs it seems the only difference would be XORing a second key with the input to the PRP.

Answer 1

The basic goal—not really explicated by the standard—of these KDF constructions is to turn an unstructured-input short-output PRF $f$ into a structured-input long-output PRF $\operatorname{KDF-}\!f$, whose PRF-advantage has some standard reduction to the PRF-advantage of $f$.

If the label, context, counter, etc., are all short enough, you could instantiate it with a PRP instead of a PRF for $f$, and you would incur the standard PRP-for-PRF cost on security bounds. It is likely that with CMAC, you don't pay that cost—though I haven't done the analysis to be sure.