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