RFR: 8272162: S4U2Self ticket without forwardable flag

Weijun Wang weijun at openjdk.java.net
Mon Nov 22 19:06:43 UTC 2021

On Fri, 22 Oct 2021 16:31:02 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The S4U2proxy extension requires that the service ticket to the first service has the forwardable flag set, but some versions of Windows Server do not set the forwardable flag in a S4U2self response and accept it in a S4U2proxy request.
> There are 2 commits now. The 1st is a refactoring that sends more info into the methods (Ex: `KdcComm::send(byte[])` -> `KdcComm::send(KrbKdcReq)`, and `Ticket` -> `Credentials` in multiple places) so that inside `KdcComm::send` there is enough info to decide how to deal with various errors. The 2nd is the actual fix to this issue, i.e. ignore the flag and retry another KDC.

Oops, I introduced a bug. At the end of the constructor of `KrbTgsReq`, `options` could be changed. Since I'm now calculating the encoding on-demand, the encoding will also change. I'll fix this in another commit.

First, my latest commit contains a mechanism to tell if a ticket is from S4U2self. Is it significant enough to change your mind?

Even if there is a system property for this purpose (suppose it's named `jdk.security.krb5.accept.non.forwardble.s4u2self.response.and.retry`), I wonder if it's worth turning it off. As you said, a  legitimate S4U2self should always be FORWARDABLE, and in this case the system property is useless. But, if a service really receives such a ticket, I assume it would prefer to try it in a S4U2proxy request instead of just failing early. After all, when it impersonates someone, its purpose should be accessing a backend service.

We usually introduce a system property for a compatibility reason so that existing normal cases will not behave differently, but here, we are simply trying to resurrect a former failure.

The main problem I see with the current approach is still about whether a "tolerant" KDC can be accessed in time. If this can be optimized by adjusting the orders of KDC either in krb5.conf or in the DNS response, then I would be greatly relieved.

That `ccreds` in `acquireS4U2selfCreds`? I'll fix it.

Other comments accepted. I'll add a system property.

All suggestions accepted, except that I still write out the full name for S4U2proxy in `java.security`.

For the `KrbKdcReq` method name. It's now `encoding` because it's returning a byte array. `getMessage` was used to return a message type.


PR: https://git.openjdk.java.net/jdk/pull/6082

More information about the security-dev mailing list