| Subject: | KDC name type return issues |
In each place the KDC returns a PrincipalName to the client, there is a
name type which the client usually ignores. These places are:
* The cname of the KDC-REP
* The sname of the EncKDCRepPart
* The sname of the Ticket
* The cname of the EncTicketPart
As of 1.6, each of these name types mirrored those of the request. The
only exception is when the KDC returns an alternate TGT for a cross-
realm TGS request, in which case the returned name will (I believe) have
type KRB_NT_UNKNOWN because it was constructed by krb5_walk_rtree using
krb5_tgtname.
In 1.7, things change a bit:
* If an AS-REQ has the canonicalize flag set, the client name types will
be that of the client principal entry's name (KRB_NT_PRINCIPAL for both
of our back ends, because they use krb5_parse_name).
* If an AS-REQ has the canonicalize flag set and the requested server
principal is a TGT principal, the server name types will be that of the
server principal entry's name.
* If a TGS-REQ is returning a ticket for a cross-realm TGT, the server
name types will be that of the server principal entry's name, because
the "is_referral" flag is set (even if the client asked for that
specific cross-realm TGT).
Nico has observed a piece of Java client code failing when it requests a
cross-realm TGT (with no request flags), because the returned name has
name type KRB_NT_PRINCIPAL instead of the requested name type
KRB_NT_SRV_INST.
The most relevant bug is that is_referral is being set when we aren't
returning a referral. To set that flag appropriately, we should compare
server->princ against the requested server principal instead of just
checking whether it's a cross-realm TGT. Changing that would have the
consequence of clearing the forwardable flag on directly requested
cross-realm TGT tickets (unless the cross TGT entry has the
KRB5_KDB_OK_TO_AUTH_AS_DELEGATE flag set); I'm not sure if that's good
or bad. It also has implications for whether return_referral_enc_padata
gets called on such requests, but that seems unlikely to be a problem.
When we actually are returning a referral or alternate TGT, we should
arguably set the name type to KRB_NT_SRV_INST. Doing that by itself
(without changing the setting of is_referral) would be enough to fix
Nico's symptom.
Writing comprehensive automated tests for KDC name type behaviors is
difficult with current library APIs. Some of the returned name types
are reflected in the credentials resulting from krb5_get_credentials and
krb5_get_init_creds_password, but not when the KDC returns a referral or
alternate TGT.
name type which the client usually ignores. These places are:
* The cname of the KDC-REP
* The sname of the EncKDCRepPart
* The sname of the Ticket
* The cname of the EncTicketPart
As of 1.6, each of these name types mirrored those of the request. The
only exception is when the KDC returns an alternate TGT for a cross-
realm TGS request, in which case the returned name will (I believe) have
type KRB_NT_UNKNOWN because it was constructed by krb5_walk_rtree using
krb5_tgtname.
In 1.7, things change a bit:
* If an AS-REQ has the canonicalize flag set, the client name types will
be that of the client principal entry's name (KRB_NT_PRINCIPAL for both
of our back ends, because they use krb5_parse_name).
* If an AS-REQ has the canonicalize flag set and the requested server
principal is a TGT principal, the server name types will be that of the
server principal entry's name.
* If a TGS-REQ is returning a ticket for a cross-realm TGT, the server
name types will be that of the server principal entry's name, because
the "is_referral" flag is set (even if the client asked for that
specific cross-realm TGT).
Nico has observed a piece of Java client code failing when it requests a
cross-realm TGT (with no request flags), because the returned name has
name type KRB_NT_PRINCIPAL instead of the requested name type
KRB_NT_SRV_INST.
The most relevant bug is that is_referral is being set when we aren't
returning a referral. To set that flag appropriately, we should compare
server->princ against the requested server principal instead of just
checking whether it's a cross-realm TGT. Changing that would have the
consequence of clearing the forwardable flag on directly requested
cross-realm TGT tickets (unless the cross TGT entry has the
KRB5_KDB_OK_TO_AUTH_AS_DELEGATE flag set); I'm not sure if that's good
or bad. It also has implications for whether return_referral_enc_padata
gets called on such requests, but that seems unlikely to be a problem.
When we actually are returning a referral or alternate TGT, we should
arguably set the name type to KRB_NT_SRV_INST. Doing that by itself
(without changing the setting of is_referral) would be enough to fix
Nico's symptom.
Writing comprehensive automated tests for KDC name type behaviors is
difficult with current library APIs. Some of the returned name types
are reflected in the credentials resulting from krb5_get_credentials and
krb5_get_init_creds_password, but not when the KDC returns a referral or
alternate TGT.