XPost: linux.debian.bugs.dist, linux.kernel   
   From: TWR@tylerwross.com   
      
   On 11/19/25 6:36 AM, Scott Mayhew wrote:   
   > While I still assert that if you want to use the stronger encryption   
   > types with NFS, then you should prioritize those encryption types higher   
   > in your kerberos configuration... after discussing this yesterday with   
   > Olga I think the above scenario should probably work too.   
      
   There was no intent or attempt to specify encryption types in the   
   original configuration. Fiddling with enctypes only came up in the   
   course of troubleshooting.   
      
   This issue was found/replicated by:   
   1. Configuring a stock Debian 13 client using ipa-client-install against   
   a freshly deployed Fedora 43 IPA instance.   
   2. Adding a krb5 NFS entry in fstab   
   3. Installing and enabling gssproxy (use-gss-proxy=1 in nfs.conf)   
   4. Configuring gssproxy for constrained delegation as described in the   
   docs:   
   [service/nfs-client]   
     mechs = krb5   
     cred_store = keytab:/etc/krb5.keytab   
     cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U   
     cred_usage = initiate   
     allow_any_uid = yes   
     impersonate = true   
     euid = 0   
   5. Allowing constrained delegation on the IPA/KDC side   
      
      
   I think this should be a working configuration: it shouldn't be   
   necessary to change the enctypes from default for this to work.   
   But the above results in the aes256-cts-hmac-sha1-96 machine credential   
   and aes256-cts-hmac-sha384-192 client ticket situation.   
      
      
   > I just sent a patch that makes that happen, but I forgot to add   
   > "--in-reply-to" my "git send-email" command, so here's the link:   
   >    
   > https://lore.kernel.org/linux-nfs/20251119133231.3660975-1-sma   
   hew@redhat.com/T/#u   
      
   Thanks, Scott.   
      
   So it's technically possible for the machine and client credentials to   
   have mismatched enctypes? There are just assumptions (like the slack   
   variable calculations) that need to be changed to support that?   
      
      
      
   I'm also wondering if the gssproxy behavior is correct. I obviously   
   don't understand all the nuance here, but it appears gssproxy is   
   requesting the service ticket with a different preference/order of   
   enctypes -- which leads to this mismatch situation.   
      
   Looking at the KDC logs (below), the protocol transition request has   
   enctypes matching the default permitted_enctypes described in   
   krb5.conf(5) (i.e., with aes256-cts-hmac-sha1-96 first). But then the   
   constrained delegation request lists aes256-cts-hmac-sha384-192 first,   
   which I assume indicates preference and is why that enctype is issued.   
      
   Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8463](info): TGS_REQ (8   
   etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),   
   aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),    
   NSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-   
   hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 10.108.2.105:   
   ISSUE: authtime 1763506600, etypes {rep=aes256-cts-hmac-sha1-96(18),   
   tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha1-96(18)},   
   host/nfsclient.ipa.twrlab.net@IPA.   
   TWRLAB.NET for host/nfsclient.ipa.twrlab.net@IPA.TWRLAB.NET   
   Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8463](info): ...   
   PROTOCOL-TRANSITION s4u-client=jsmith@IPA.TWRLAB.NET   
   Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8463](info): closing down fd 4   
   Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8465](info): TGS_REQ (4   
   etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),   
   aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17)}) 10.108.2.105:   
   ISSUE: authtime 1763506600, etypes {   
   rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha384-192(20),   
   ses=aes256-cts-hmac-sha384-192(20)}, host/nfsclient.ipa.twrlab.n   
   t@IPA.TWRLAB.NET for nfs/nfssrv.ipa.twrlab.net@IPA.TWRLAB.NET   
   Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8465](info): ...   
   CONSTRAINED-DELEGATION s4u-client=jsmith@IPA.TWRLAB.NET   
   Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8465](info): closing down fd   
   11   
      
      
   >    
   > -Scott   
   >    
   >>   
   >>> That's exactly the case: the machine credential is   
   >>> aes256-cts-hmac-sha1-96.   
   >>>   
   >>> So, taking a step back for context/background: this issue was escalated to   
   >>> me by someone attempting to use constrained delegation via gssproxy. In the   
   >>> course of troubleshooting that, we found (by examining the krb5kdc logs on   
   >>> the IPA server) that the NFS service ticket acquired by gssproxy had an   
   >>> aes256-cts-hmac-sha384-192 session key.   
   >>>   
   >>> Not understanding that the machine and user tickets must having matching   
   >>> enctypes, I ended up down this rabbit hole thinking the problem   
   >>> was with the SHA2 enctypes. Sorry to bring you all with me on that   
   >>> misadventure.   
   >>>   
   >>>   
   >>>   
   >>> The actual issue at hand then seems to be that gssproxy is requesting (and   
   >>> receiving) a service ticket with an unusable (for the NFS mount) enctype,   
   >>> when performing constrained delegation/S4U2Proxy.   
   >>>   
   >>> krb5kdc logs of gssproxy performing S4U2Self and S4U2Proxy:Nov 18 18:06:51   
   >>> directory.ipa.twrlab.net krb5kdc[8463](info): TGS_REQ (8 etypes   
   >>> {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),   
   >>> aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),   
   >>> UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23),   
   >>> camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 10.108.2.105: ISSUE:   
   >>> authtime 1763506600, etypes {rep=aes256-cts-hmac-sha1-96(18),   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)