Add a comment to the r22168 change since it's not obvious why we're
authorGreg Hudson <ghudson@mit.edu>
Wed, 20 May 2009 17:44:37 +0000 (17:44 +0000)
committerGreg Hudson <ghudson@mit.edu>
Wed, 20 May 2009 17:44:37 +0000 (17:44 +0000)
decrypting authdata that way.

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

src/kdc/kdc_authdata.c

index fd2e3ab5b34e6886a06e9cbf8b051aa1ecd1fdd8..1dc4d33243c401e6959e7ad45a4548eee2ee6cdf 100644 (file)
@@ -398,6 +398,17 @@ handle_request_authdata (krb5_context context,
     if (scratch.data == NULL)
        return ENOMEM;
 
+    /*
+     * RFC 4120 requires authdata in the TGS body to be encrypted in
+     * the subkey with usage 5 if a subkey is present, and in the TGS
+     * session key with key usage 4 if it is not.  Prior to krb5 1.7,
+     * we got this wrong, always decrypting the authorization data
+     * with the TGS session key and usage 4.  For the sake of
+     * conservatism, try the decryption the old way (wrong if
+     * client_key is a subkey) first, and then try again the right way
+     * (in the case where client_key is a subkey) if the first way
+     * fails.
+     */
     code = krb5_c_decrypt(context,
                          enc_tkt_request->session,
                          KRB5_KEYUSAGE_TGS_REQ_AD_SESSKEY,