RFR 8227437: S4U2proxy cannot continue because server's TGT cannot be found

Weijun Wang weijun.wang at oracle.com
Wed Jul 17 03:23:49 UTC 2019

Krb5Context.java and Krb5LoginModule.java:

There is no need to set the aliases, already done inside Krb5Util.credsToTicket(serviceCreds). The case in Krb5LoginModule.java is more complicated, due to your change in webrev.01. See below.

> * Fixed a bug in referral TGTs Credentials (no server alias should be
> there)
>  * See this change in KrbTgsRep.java

But this is not harmful, right? The referral TGTs are not stored in a Subject and its alias is not used.

> * Fixed a bug in Krb5LoginModule
>  * If we get a TGT from a ccache, that TGT will not have client alias
> and its cname may be different than the subject principal. If we commit
> this ticket in the subject private credentials, we will not find it.
>   * My proposal is to force the subject principal as an alias if: cname
> differs from the subject principal AND there is no client alias.
>  * See this change in Krb5LoginModule.java

KerberosPrincipal kClient = new KerberosPrincipal(
if (!princSet.contains(kClient)) {
    kClientAlias = kClient;

Looks like this ticket's name and alias will be the same? Is this useful?

> --
> In regards to SubjectComber::findAux, I understand your concerns but
> cannot figure out how that situation would be possible. I'll try to
> explain my reasoning as detailed as possible and why I believe the
> client alias (if there is one) is a better choice there.
> Let's say we have a Subject called "client1", whose principal is
> "client1 at REALM-1.COM". This Subject has 2 KerberosTicket private
> credentials:
> 1) TGT cname: client1-canonical at REALM-1.COM, clientAlias:
> client1 at REALM-1.COM
> 2) TGT cname: client1 at REALM-1.COM, clientAlias: null
> We want to retrieve all tickets for this Subject so we call
> SubjectComber::find with clientPrincipal == null.
> As you said, ticket #1 is retrieved after check in line 198
> (clientPrincipal == null). Now, clientPrincipal will be equal to
> "client1 at REALM-1.COM" because of the assignment in line 214
> (clientPrincipal = clientAlias.getName();).
> In the second iteration, we will get the ticket #2 because
> clientPrincipal (client1 at REALM-1.COM) matches the ticket cname
> (client1 at REALM-1.COM).
> If we do "clientPrincipal = ticket.getClient().getName()" in line 214,
> clientPrincipal would be client1-canonical at REALM-1.COM and we will not
> get ticket #2 (whose cname is client1 at REALM-1.COM).
> Why did I assume that ticket #2 has a "client1 at REALM-1.COM" cname and
> not something different? cname may be anything BUT if it were different
> than the subject principal (client1 at REALM-1.COM), then it must have an
> alias and we will get it through the alias.

OK, this is how I understand it.

With the current implementation, yes it always has an alias.

Or, if CANONICALIZE is not set (who knows why), then there will be no alias and the alias is the name.

If so, then you are correct.


> My reasoning is that we should track all the tickets to the subject
> principal (either because their cname matches the subject principal or
> because we set an alias).
> If someone forces a ticket without an alias and without a cname that
> matches the subject principal, we will not retrieve it... but that's
> because the invariant is broken. We may also broke the invariant in the
> same way by adding a ticket with a cname different than
> ticket.getClient().getName().
> Thanks,
> Martin.-

More information about the security-dev mailing list