RFD 0239 - Windows CA split

Required Approvers

Engineering: @rosstimothy && @zmb3
Security: (@rob-picard-teleport || @klizhentas)
Product: @klizhentas

What

Split the "windows" (aka Desktop Access) CA from the User CA.

Why

The "windows" CA is used to generate user certificates for Desktop Access. Those certificates are used to perform smart card authentication on RDP (Remote Desktop Protocol).

Currently the User CA issues those certificates, as they are end-user certs. Splitting the CAs improves Teleport's security posture by introducing a more specialized CA (the "windows" CA needs to be trusted by downstream Windows systems) and lets both CAs be rotated independently.

This is a task we've been long meaning to address (see #10111).

UX

The CA split borrows its methodology and UX from the previous db and db_client split.

The new CA is called "windows", as that term is already used in the product's UX (for example, /webapi/auth/export?type=windows and tctl auth export --type=windows).

Honorable mention to RFD 0168.

New Teleport cluster

New Teleport clusters are created with distinct User and Windows CAs. No further action is needed from the user.

Existing Teleport cluster

Existing Teleport clusters have the User CA copied into Windows CA on startup. A CA rotation is required to create distinct key material.

Neither User or Windows CA is rotated automatically, nor is there any forced rotation relationship between them. This follows our database CA migration advice.

Old Windows Desktop service instances (prior to the introduction of the Windows CA) will remain issuing RDP certificates using the User CA. Only new Windows Desktop service instances are capable of using the Windows CA. This is transparent while the Windows CA is a copy of the User CA, but the issued certificates will differ once a rotation happens.

Attempts to rotate the Windows CA will issue a warning calling attention to this fact that only new agents are capable of utilizing it, thus all agents should be upgraded first.

Details

The Windows CA, if it doesn't exist, is created during Teleport initialization:

If the UserCA exists: as a copy of the UserCA (existing cluster)
- Implemented after init migrations
If the UserCA does not exist: as a distinct CA (new cluster)
- Implemented by initializeAuthorities

Cluster initialization already runs under a lock, so no further precautions against Auth server races are required.

Agent compatibility check

In order to ensure correct functioning a new GenerateWindowsDesktopCert RPC request parameter is added to detect old clients/agents.

Old agents (prior to Windows CA) get certificates issued using the User CA. New agents use the Windows CA.

diff

 message WindowsDesktopCertRequest {
   // (Existing fields omitted.)
+
+  // Set by callers that fully support the new Windows CA.
+  //
+  // Auth issues certificates differently according to this parameter:
+  // - false issues certificates using the UserCA
+  //   (Teleport agent versions < 18.x, where 18.x marks the initial release of
+  //   the Windows CA split).
+  // - true issues certificates using the WindowsCA
+  //   (Teleport agent version >= 18.x)
+  //
+  // Transitional. To be removed on Teleport 20, when all agents are expected
+  // to support the Windows CA.
+  bool SupportsWindowsCA = n;
 }

Client compatibility check

Incompatible tctl versions are detected per User-Agent plus version and stopped from querying the User CA, due to the inherent ambiguity of such requests. (Ie, does it want the Windows CA instead?)

This stops commands such as tctl auth export --type=windows from exporting the wrong CA.

The check is only applied to GetCertAuthority requests and is itself less than perfect, but is considered sufficient (and better than a more severe breakage, such as a MinClientVersion increase).

Trust architecture

Connect, tbot and tsh

No direct interaction with the Windows CA.

tctl

tctl has various commands that interact with CAs.
No direct trust of the Windows CA or special interactions, other than the ones above.

Proxy

No direct interaction with the Windows CA.
The Proxy connects to the Windows Desktop Service using a UserCA certificate with the appropriate RouteToWindowsDesktop.

Windows Desktop Service

The Windows Desktop Service connects to the Windows host using a Windows CA issued certificate

Product surface

The Windows CA split has direct impact in the following user-visible surface:

Desktop Access feature
tctl status
tctl auth export
tctl auth sign
tctl auth rotate
tctl auth crl
/webapi/auth/export endpoint

Release targets

The Windows CA split targets:

(N-1).x.0 - A minor release in the current version (eg, 18.7.0)
N - The next major version (eg, 19.0.0)

Any deprecation related actions only take effect on N+1 (eg, 20.0.0), to allow for at least a full release cycle.

Backward compatibility

Agent and client compatibility are discussed in their respective design sections.

Rollbacks to versions prior to the split have the system revert to using the User CA for Windows Desktop Access. That is harmless without a rotation, but may break downstream trust if a rotation happened. The mitigation is that downstream systems should retain trust to the User CA certificate for a safety period, after which a downgrade becomes unlikely.

In the case of a rollback the split Windows CA remains in the backend, effectively dormant until a following upgrade makes use of it again.

Test Plan

Windows CA split

Features must be tested before split, after split (or on new cluster), and after CA rotation.