Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.427 (Entity 5.427) Subject: KDC always offers encrypted timestamp or challenge X-RT-Original-Encoding: iso-8859-1 Content-Length: 1185 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.