New mechanism for CSR tickets

[gunnarbeutner]

The current certificate request mechanism has a number of issues:

• Clients can't locally verify whether their ticket is valid (this would be useful in "node wizard")
• Tickets have infinite validity which is a security concern
• Users have to manually verify that they're connecting to the correct parent instance

This issue describes a new mechanism for CSR tickets which would alleviate some of these problems.

V2 tickets are constructed using the following algorithm:

1. The current timestamp is rounded to the nearest N days (using the modulo operation) where N is configurable in the range [1, 256]. This value is the notBefore timestamp.
2. The N value in step 1 is the validityGranularity.
3. A SHA256 hash is constructed over the notBefore timestamp and the commonName of the Icinga instance for which the ticket is being generated. This is the ticketHash.
4. An RSA or ECDSA signature is constructed over the validityGranularity and ticketHash values. This is the ticketSignature.
5. A base64-encoded concatenation of the validityGranularity, ticketHash and ticketSignature is generated. This is the ticketData.

The resulting ticket format is "icinga-ticket <ticketData> <comment>" where <comment> is an optional value that is not used by Icinga. In most cases this should be the commonName to enable debugging by the user.

Note that the ticketHash could in theory be omitted from the ticketData because it can be reconstructed from the ticketSignature when RSA signatures are used. However, this is not true for ECDSA which would mean that the client cannot locally verify tickets. It would however save 256 bits (+ overhead for base64).

Icinga can locally verify whether a ticket is valid by trying to construct the ticketHash value using the current timestamp and whatever common name it has been configured with. This would be a useful verification step for the "node wizard" to avoid sending known-invalid tickets to the parent instance.

Icinga agents can use the ticket to verify that they're connecting to the correct parent instance. They do this by enumerating the CA certificate(s) from their trust chain for cluster connections. Icinga then attempts to verify the ticketSignature against each of the CA certificates. If a match is found we know that we're connected to an Icinga instance that belongs to the same trust hierarchy. We then still have to verify that we're connecting to the right instance by checking the common name of the instance against the node name the user has specified for the Endpoint object.

The Icinga CA instance can validate tickets by constructing a new ticketHash for the current timestamp and the requestor's commonName. If these match the ticketHash that was provided by the requestor the ticket is both in the correct time range and for the correct commonName. The CA instance also must verify the ticketSignature to ensure that the ticketData has not been tampered with.

[gunnarbeutner]

Paging @dnsmichi and @lippserd. :)

[gunnarbeutner]

The modulo division might be an issue if we're "close" to the end of the current validityGranularity period. Maybe we should just put the entire notAfter timestamp into the ticket.

[dnsmichi]

As discussed, this should be included going along with #5450 and 2.8.

[gunnarbeutner]

This also (optionally) depends on #5555 to get the ticket length down to a manageable value.

[dnsmichi]

Postponed due to feature freeze.

[dnsmichi]

Unfortunately

• Windows X509Certificate2 does not support sha256ECDSA #6200

is a blocker here, and we cannot raise the .NET package dependency.

[dnsmichi]

.NET 4.6.1 is now the new default, not a blocker anymore. #5555 was reverted, so those changes are needed.

[Al2Klimov]

The whole concept reminds me of certificates themselves. Alternatively people could just issue and deploy certificates in favour of tickets, via icinga2 pki. Or even do neither, but instead use icinga2 ca sign.