| From: | "Nico Williams" <nico@cryptonector.com> |
| To: | krb5-bugs@mit.edu |
| Date: | Fri, 26 Mar 2021 11:41:03 -0500 |
| Subject: | PKINIT client cert notAfter has no effect on ticket endtime, but should |
In a world where there are online CAs issuing client certificates it is
important to not allow the endtime of a ticket acquired with PKINIT to
extend past the notAfter of the client's certificate. Otherwise there
is the risk that a user can cycle a forever credential by using Kerberos
to acquire a client certificate and then the client certificate to
acquire a TGT, repeatedly getting a 10 hour (or whatever is configured)
extension, and thus avoiding the need to periodically engage in initial
[pre-]authentication.
This should apply to all pre-authentication methods where the method
involves expiring credentials, and indeed, it already applies to PA-TGS
for example.
Not applying the client certificate's notAfter to the issued ticket's
endtime is only a serious bug in environments that also operate online
CAs that issue client certificates good for PKINIT to clients
authenticated with Kerberos. In the context of as-originally-intended
deployment, this is not a serious bug.
important to not allow the endtime of a ticket acquired with PKINIT to
extend past the notAfter of the client's certificate. Otherwise there
is the risk that a user can cycle a forever credential by using Kerberos
to acquire a client certificate and then the client certificate to
acquire a TGT, repeatedly getting a 10 hour (or whatever is configured)
extension, and thus avoiding the need to periodically engage in initial
[pre-]authentication.
This should apply to all pre-authentication methods where the method
involves expiring credentials, and indeed, it already applies to PA-TGS
for example.
Not applying the client certificate's notAfter to the issued ticket's
endtime is only a serious bug in environments that also operate online
CAs that issue client certificates good for PKINIT to clients
authenticated with Kerberos. In the context of as-originally-intended
deployment, this is not a serious bug.