There are probabilistic algorithms to factor $n$ into $p$ and $q$ from $n$, $e$, $d$. It's then easy to rebuild the full private key $(n,e,d,p,q,d_p,d_q,q_\text{inv})$. One such algorithm is there. A similar one is in OpenSSL key import, and other libraries. The time it takes in practice is acceptable (comparable to key generation). Doing that with side-channel resistance would be hard (and unstudied AFAIK), but not an issue in many contexts.
the modulus $n$ and the private exponent $d$ are all that is needed to use an RSA private key
Yes that's sufficient to evaluate the RSA private key transformation $x\mapsto y=x^d\bmod n$. But if you care about making that operation three times faster or so, you want to use the Chinese Remainder Theorem method, which disregards $d$ and use $n$, $p$, $q$, $d_p=e^{-1}\bmod(p-1)$, $d_q=e^{-1}\bmod(q-1)$, $q_\text{inv}=q^{-1}\bmod p$ to compute the same $y\,$; and you want $e$ for reasons detailed later.
Or is $n$ and $d$ insufficient?
Yes, for performance in particular, see above. $n$ and $d$ are not sufficient to reconstruct the full form of the private key (for arbitrary odd unknown large $e$ as allowed by PKCS#1 and FIPS 186-5). The RFC 2313 quote is correct in including "provided the public key is known" because $e$ is in the public key, not included in the $(n,d)$ format of the private key, and necessary together with $d$ to factor $n$ if $p$ and $q$ are unavailable. And it is is correct in making reference to the Miller article that lays the basis for the methods actually used.
That's part of RSA folklore. I have no idea why it was removed, and if it's still in some modern documents.
Update: On the other hand, RSA usually uses a small $e$, and small values can be guessed and checked. If $r^{e\,d}\bmod n=r$ for small prime $r$ (e.g. $r=2$) then most likely a guess of $e$ is right. It's worth trying the usual values of $e$: 65537, 3, 5, 17, 257 which are the Fermat primes $F_i=2^{(2^i)}+1$, 37 which is also common. And we can find small $e$ systematically: compute $g_1=2^d\bmod n$, then $g_2={g_1}^2\bmod n$, then $g_e=g_2\,g_{e-2}\bmod n$ for successive odd $e$, until we find one $g_e=2$. Most likely, that gets us $e$. We can then check $r^{e\,d}\bmod n=r$ for a few odd primes $r$ to be sure. And further: by using methods similar to baby-step/giant-step or collision search, we can find medium $e$ with in the order of $2\sqrt{e_\max}$ modular multiplications.
Any reason (other than performance) that the other components ($p$, $q$, et al) are necessary for confidence in the key?
It is important to have $e$ in the private key for at least two reasons beyond performance:
- $e$ allows masking to resist side channel attacks: to compute $y=x^d\bmod n$, we can draw a random $r$, compute $s=r^e\bmod n$, then $t=x\,s\bmod n$, then $u=t^d\bmod n$, then $y=(r^{-1}\bmod n)\,u\bmod n$. Because $t$ and $u$ are different and random-like from one execution to the other, some attacks are thwarted.
- $e$ allows checking the result to resist fault attacks: we check that $y^e\bmod n=x$. Many errors induced in the calculation, or in the storage of $n$ or $d$, are caught by this check.
The other components $p$, $q$, $d_p$, $d_q$, $q_\text{inv}$ are only useful for performance reasons.
Update: occasionally, with HSMs or crypto-accelerators, the hardware for modular exponentiation may have a width limitation that makes it unusable for computation modulo $n$, but usable modulo $p$ and $q$. If this is the case, not having $p$ and $q$ has a huge performance hit, or could even make use of $(n,d)$ impossible for lack of an implementation.
