Canonical clients in AS-REQ for non-TGS server principals

[Greg Hudson]

On 02/07/2017 09:58 AM, Jakob Uhd Jepsen wrote:
> I have run into a limitation of the AS-REQ protocol, when used with 
> canonical clients, that I am not sure why exists.

This code dates back to a period of churn in the code base in 2008-2009
as the team integrated a bunch of changes for better interoperability
with Microsoft's Kerberos implementation.

I looked at the commits as they appeared on the development branch for
this work.  First is r21462 (we used Subversion back then):

    https://src.mit.edu/fisheye/changelog/krb5/?cs=21462

which simply conditionalizes the client-against-request and
server-against-request checks on the canonicalize flag.  This is
followed by r21484:

    https://src.mit.edu/fisheye/changelog/krb5/?cs=21484

which adds in the implicit assumption that an enterprise client
principal implies canonicalization.  (r21487 corrects "=" to "==" in the
expression there.)  Finally there is r21662:

    https://src.mit.edu/fisheye/changelog/krb5/?cs=21662

which appears intended to restrict changes to the server principal to
when a krbtgt principal is requested, but also restricts changes to the
client principal, as you discovered.

Even just the motivation for this change is a little confusing, as there
is no such thing as a cross-realm AS request.  It seems potentially
useful to accept changes in the case of the realm we sent the request
to, although that seems equally true for a non-krbtgt server principal.
I did find this paragraph in the security considerations of RFC 6806:

   Changing the server name can be a very significant attack.  For
   example, if a user is authenticating in order to send some
   confidential information, then the attacker could gain this
   information by directing the user to a server under the attacker's
   control.  The server name in the response is protected by RFC 4120,
   but not the one in the request.  Fortunately, users are typically
   authenticating to the "krbtgt" service in an AS exchange.  Clients
   that permit changes to the server name when no protection beyond RFC
   4120 is in use SHOULD carefully restrict what service names are
   acceptable.  One critical case to consider is the password-changing
   service.  When a user authenticates to change their password, they
   use an AS authentication directly to the password-changing service.
   Clients MUST restrict service name changes sufficiently that the
   client ends up talking to the correct password-changing service.

I think it should be safe to alter the code to allow a change to the
client principal if the requested server principal is not a TGT.  We do
need to be very careful not to introduce an attack vector when making
the change, as these parts of the AS exchange are not protected by any
cryptography (in the absence of FAST or MS-KKDCP or similar).