From: Greg Hudson Date: Fri, 13 Mar 2009 03:10:12 +0000 (+0000) Subject: Use correct salt for canonicalized principals X-Git-Tag: krb5-1.8-alpha1~597 X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=04e24348bf820b0eb73c10e41549f83aab04979b;p=krb5.git 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 5419f3723..f82e2a81e 100644 --- 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