From dc883527fd27fec5d3d1bdee336370be64440e47 Mon Sep 17 00:00:00 2001 From: Greg Hudson Date: Wed, 20 May 2009 17:44:37 +0000 Subject: [PATCH] Add a comment to the r22168 change since it's not obvious why we're decrypting authdata that way. git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@22358 dc483132-0cff-0310-8789-dd5450dbe970 --- src/kdc/kdc_authdata.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/src/kdc/kdc_authdata.c b/src/kdc/kdc_authdata.c index fd2e3ab5b..1dc4d3324 100644 --- a/src/kdc/kdc_authdata.c +++ b/src/kdc/kdc_authdata.c @@ -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, -- 2.26.2