svn rev #22083: trunk/src/lib/krb5/krb/

[ghudson@MIT.EDU]

http://src.mit.edu/fisheye/changelog/krb5/?cs=22083
Commit By: ghudson
Log Message:
ticket: 6415
subject: Use correct salt for canonicalized principals
target_version: 1.7
tags: pullup

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.



Changed Files:
U   trunk/src/lib/krb5/krb/get_in_tkt.c
Modified: trunk/src/lib/krb5/krb/get_in_tkt.c
===================================================================
--- trunk/src/lib/krb5/krb/get_in_tkt.c	2009-03-12 22:06:35 UTC (rev 22082)
+++ trunk/src/lib/krb5/krb/get_in_tkt.c	2009-03-13 03:10:12 UTC (rev 22083)
@@ -254,7 +254,13 @@
     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 @@
 	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