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

Weijun Wang weijun.wang at oracle.com
Tue Jul 16 01:21:16 UTC 2019


Hi Martin,

There is only one place I don't quite understand.

In SubjectComber::findAux, you have

 151                     while (iterator.hasNext()) {
 152                         Object obj = iterator.next();
 153                         if (obj instanceof KerberosTicket) {
 155                             KerberosTicket ticket = (KerberosTicket)obj;
 164                             if (!ticket.isCurrent()) {
 ...
 186                             } else {
 ...
 195                                     KerberosPrincipal clientAlias = KerberosSecrets
 196                                             .getJavaxSecurityAuthKerberosAccess()
 197                                             .kerberosTicketGetClientAlias(ticket);
 198                                     if (clientPrincipal == null ||
 199                                         clientPrincipal.equals(
 200                                             ticket.getClient().getName()) ||
 201                                             (clientAlias != null &&
 202                                             clientPrincipal.equals(
 203                                                     clientAlias.getName()))) {
 ...
 207                                             // Record names so that tickets will
 208                                             // all belong to same principals
 209                                             if (clientPrincipal == null) {
 210                                                 if (clientAlias == null) {
 211                                                     clientPrincipal =
 212                                                             ticket.getClient().getName();
 213                                                 } else {
 214                                                     clientPrincipal =
 215                                                             clientAlias.getName();
 216                                                 }
 217                                             }
 ...
 227                                             answer.add(credClass.cast(ticket));
 228                                         }
 229                                     }
 230                                 }
 231                             }
 232                         }
 233                     } 

Suppose we have 2 tickets:

 client1(clientAlias1) -> ...
 client1 -> ...  // I don't know why this one has no alias

and clientPrincipal is null at the beginning.

Now, when the 1st ticket is checked, the if check on lines 198-203 will succeed, and clientPrincipal is assigned clientAlias1 on line 214. Next, when the 2nd ticket is checked, because it has no alias and client1 != clientPrincipal (now clientAlias1), it will not be added. Is this intended?

Why not simply assign ticket.getClient().getName() to clientPrincipal?

Thanks,
Max

> On Jul 16, 2019, at 8:47 AM, Martin Balao <mbalao at redhat.com> wrote:
> 
> Hi,
> 
> I'd like to propose the following fix for JDK-8227437 [1] (*):
> 
> * http://cr.openjdk.java.net/~mbalao/webrevs/8227437/8227437.webrev.00/
> 
> JDK-8227437 bug appeared after the OpenJDK Kerberos client supported
> RFC-6806 [2].
> 
> When requesting a TGT (ticket-granting-ticket), there may be client name
> canonicalization and/or realm referrals. When requesting a TGS
> (ticket-granting-service), there may be realm referrals. As a result,
> the client or service names we use to request a ticket may be different
> than those we get in the returned ticket. I.e.: we may use the subject
> principal "subject at REALM-1.COM" as a client name to request a TGT and
> get a ticket whose client name is "subject-canonical at REALM-2.COM".
> 
> Even though the ticket credentials belong to the subject, we are unable
> to locate them based on the client or service names when there is a
> change. In the previous example, we will use "subject at REALM-1.COM"
> subject principal as a client name to find the ticket but the actual
> ticket has a "subject-canonical at REALM-2.COM" client name.
> 
> To fix this problem, we now save the original client and service names
> as "alias" fields in Credentials and KerberosTicket objects (if there is
> a change). This allows to find subject credentials properly.
> 
> Note: client and service alias information is not populated (saved or
> retrieved) across credentials caches: file-based-caches [3][4], Windows
> native cache or macOS native cache. As a result, the client name must
> match the subject principal for the credential to be found (see
> Credentials::acquireTGTFromCache). If the credential is not found, a
> request to the KDC may be issued.
> 
> Testing:
> 
> * ReferralsTest extended to cover this bug
> 
> * Regression testing on jdk/sun/security/krb5 passed
> 
> * Tested in my local Windows 2016 referrals environment
> 
> Look forward to your comments.
> 
> Thanks,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8227437
> [2] - https://bugs.openjdk.java.net/browse/JDK-8215032
> [3] - https://web.mit.edu/kerberos/krb5-1.12/doc/basic/ccache_def.html
> [4] -
> https://web.mit.edu/kerberos/krb5-devel/doc/formats/ccache_file_format.html
> 
> (*) - we have worked together with Max (@weijun) during the last week to
> come up with this version.




More information about the security-dev mailing list