PIV login enforcement

[Joerger]

Part 3 for implementing #14774

Changes:

• Add PrivateKeyPolicy extension for TLS and SSH certificates, and enforce them for every API request.
• Add hardware_key/hardware_key_touch enforcement during certificate signing operations.
  • Login endpoints have additional AttestationRequest field. When provided, the auth server will verify the attestation data, sign the certificates with the proper key policy extension, and store the attestation for future checks
    • Certificates generated outside the normal login flow, such as reissued certificates for database sessions or per-Session MFA certificates, get the attestation data from the backend.
    • If the attestation is rejected or not provided when a private key policy is required, Teleport Clients will receive an error containing the missing key policy and must re-login.
  • Before signing certificates, Auth server will check the user's require_session_mfa settings to see if attestation is required. If so, it will try to get a valid attestation from the signing request, or from a previously stored attestation in `/key_attestations/
• Add private key policy guessing and error logic to tsh and Teleport Connect to automatically enable hardware key login when needed.
  • Add private_key_policy field to Ping response so that a cluster's default private key policy can be discovered.
• Refactor/Generalize login logic to be reused by tsh and Teleport Connect. Specifically:
  • Abstract ssh login logic to be an sshLoginFunc function of type func(context.Context, *keys.PrivateKey) (*auth.SSHLoginResponse, error)
  • Create new generalized SSHLogin function, which takes an sshLoginFunc, prepares a private key for login, sends it through the login func, parses the response and returns a new client key.
  • Retry login if initial login fails due to a private key policy error.

e PR - https://github.com/gravitational/teleport.e/pull/528

Fixes #10489

[Joerger]

@codingllama Could you give the current re-login flow a quick look? This is probably more in line with what you originally had in mind too.

During implementation I realized it would be much easier and simpler to wire attestation logic directly into login (rather than #14774 (comment)). This way, we don't need to add any new endpoints, or worry about handling certificates with reduced privileges.

Right now, the flow is simply:

login (with nil attestation field) -> 
  auth returns attestation error -> 
  get private key policy from error -> 
  bootstrap PIV private key -> 
  login (with valid attestation field) ->
  auth returns certs with proper extensions

Another benefit of this approach is that we have a clear lifetime for attestations stored in the backend - the login certificate TTL.

Once we agree on a solution in this PR, I'll update the RFD to reflect it.

[codingllama]

@codingllama Could you give the current re-login flow a quick look? This is probably more in line with what you originally had in mind too.

During implementation I realized it would be much easier and simpler to wire attestation logic directly into login (rather than #14774 (comment)). This way, we don't need to add any new endpoints, or worry about handling certificates with reduced privileges.

Right now, the flow is simply:

login (with nil attestation field) -> 
  auth returns attestation error -> 
  get private key policy from error -> 
  bootstrap PIV private key -> 
  login (with valid attestation field) ->
  auth returns certs with proper extensions

Another benefit of this approach is that we have a clear lifetime for attestations stored in the backend - the login certificate TTL.

Once we agree on a solution in this PR, I'll update the RFD to reflect it.

Yep, that sounds even better to me.

Is there anything in particular in the PR you'd like me to look at?

[jakule]

LGTM, one minor comment.

[codingllama]

Drive-by review, looking at a couple of changes that caught my eye.