Use correct salt for canonicalized principals

In cases where the salt is derived from the client principal, use the
canonicalized principal received from the KDC to determine the salt.
Further changes are probably required for some preauth cases.

ticket: 6415
target_version: 1.7
tags: pullup

git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@22083 dc483132-0cff-0310-8789-dd5450dbe970

diff --git a/src/lib/krb5/krb/get_in_tkt.c b/src/lib/krb5/krb/get_in_tkt.c
index 5419f3723c499ffab79e739ce9f989aa650f6c75..f82e2a81e7bab3f71dccb4108a2a718b12a6dbf1 100644 (file)
--- a/src/lib/krb5/krb/get_in_tkt.c
+++ b/src/lib/krb5/krb/get_in_tkt.c
@@ -254,7 +254,13 @@ decrypt_as_reply(krb5_context              context,
     if (key)
            decrypt_key = key;
     else {
-       if ((retval = krb5_principal2salt(context, request->client, &salt)))
+       /*
+        * Use salt corresponding to the client principal supplied by
+        * the KDC, which may differ from the requested principal if
+        * canonicalization is in effect.  We will check
+        * as_reply->client later in verify_as_reply.
+        */
+       if ((retval = krb5_principal2salt(context, as_reply->client, &salt)))
            return(retval);
     
        retval = (*key_proc)(context, as_reply->enc_part.enctype,
@@ -1385,6 +1391,22 @@ krb5_get_init_creds(krb5_context context,
        goto cleanup;
        }
 
+    /*
+     * If we haven't gotten a salt from another source yet, set up one
+     * corresponding to the client principal returned by the KDC.  We
+     * could get the same effect by passing local_as_reply->client to
+     * gak_fct below, but that would put the canonicalized client name
+     * in the prompt, which raises issues of needing to sanitize
+     * unprintable characters.  So for now we just let it affect the
+     * salt.  local_as_reply->client will be checked later on in
+     * verify_as_reply.
+     */
+    if (salt.length == SALT_TYPE_AFS_LENGTH && salt.data == NULL) {
+       ret = krb5_principal2salt(context, local_as_reply->client, &salt);
+       if (ret)
+           goto cleanup;
+    }
+
     /* XXX For 1.1.1 and prior KDC's, when SAM is used w/ USE_SAD_AS_KEY,
        the AS_REP comes back encrypted in the user's longterm key
        instead of in the SAD. If there was a SAM preauth, there