Skip Menu |

Subject: KDC always offers encrypted timestamp or challenge
Download (untitled) / with headers
text/plain 1.1KiB
Currently we require every principal entry in the KDB to have at least
one long-term key, and we always offer encrypted timestamp or challenge
as one of the choices for preauthentication. This is suboptimal if the
principal should only be allowed to preauthenticate with PKINIT or some
other mechanism which does not involve the long-term key.

The administrator can, of course, give the principal one or more random
keys, which means encrypted timestamp or challenge won't work. But
lying to the client this way makes it difficult to present good
diagnostics about configuration issues with PKINIT. The client tries
PKINIT first and sees an error, but thinks it should also try encrypted
timestamp or challenge instead of failing out.

This problem could be solved in two ways. We could make it possible for
a principal to have zero long-term keys, and only offer encrypted
timestamp or challenge if the principal has keys. This would be an
architectural challenge, requiring analysis of each part of our code
which interacts with key data.

Alternatively, we could give administrative control over which
preauthentication mechanisms are allowed for each principal.
Fixed by ticket #7679.