rpc.gssd: Don't supply the KDC with unsupported encryption types

Hello,

It seems when rpc.gssd initially registers with the KDC, it sends a long list of encryption types that are not supported:

Encryption Types: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1
rc4-hmac des-cbc-crc des-cbc-md5 des-cbc-md4 rsa-sha1-cms rsa-md5-cms des-ede3-cbc-env rc2-cbc-env rsa-env

Now the theory is mounts will hang if the KDC (like a Solaris KDC) returns an unsupported encryption type since the client will not know what to do with it. I'm currently trying to test this theory with people that actually have a working Solaris KDC, unfortunately I'm not one of those people...

But to me, it just makes sense that rpc.gssd should only talk about encryption types it supports. It seems like it would cuts out any and all confusion.The following patch does just that.

comments?

steved.

Author: Steve Dickson <[email protected]>
Date:   Tue Nov 11 11:08:13 EST 2008

When rpc.gssd registers with the KDC, only talk about the supported encryption types during the initial registration so the KDC will only return supported encryption types.

Signed-off-by Steve Dickson <[email protected]>

utils/gssd/krb5_util.c +5 -5

index 77814bc..7f131c9 100644
@@ -125,6 +125,10 @@
 
 /* Global list of principals/cache file names for machine credentials */
 struct gssd_k5_kt_princ *gssd_k5_kt_princ_list = NULL;
+static krb5_enctype enctypes[] = { ENCTYPE_DES_CBC_CRC,
+                                   ENCTYPE_DES_CBC_MD5,
+                                   ENCTYPE_DES_CBC_MD4 };
+static int num_enctypes = sizeof(enctypes) / sizeof(enctypes[0]);
 
 /*==========================*/
 /*===  Internal routines ===*/

@@ -309,10 +313,6 @@ limit_krb5_enctypes(struct rpc_gss_sec *sec, uid_t uid)
       u_int maj_stat, min_stat;
       gss_cred_id_t credh;
       gss_OID_set_desc  desired_mechs;
-       krb5_enctype enctypes[] = { ENCTYPE_DES_CBC_CRC,
-                                   ENCTYPE_DES_CBC_MD5,
-                                   ENCTYPE_DES_CBC_MD4 };
-       int num_enctypes = sizeof(enctypes) / sizeof(enctypes[0]);
 
       /* We only care about getting a krb5 cred */
       desired_mechs.count = 1;

@@ -412,6 +412,7 @@ gssd_get_single_krb5_cred(krb5_context context,
 
       krb5_get_init_creds_opt_init(&options);
       krb5_get_init_creds_opt_set_address_list(&options, NULL);
+       krb5_get_init_creds_opt_set_etype_list(&options, enctypes, num_enctypes);
 #ifdef TEST_SHORT_LIFETIME
       /* set a short lifetime (for debugging only!) */
       printerr(0, "WARNING: Using (debug) short machine cred lifetime!\n");
--

To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Hi Steve,

This patch shouldn't be necessary.

When you say "registers with the KDC", I assume that you mean gets a TGT.

Quoted 6 lines · Kevin Coffman

Hi Steve,

This patch shouldn't be necessary.

When you say "registers with the KDC", I assume that you mean gets a TGT.

I'm not sure what a TGT is... but what I talking about is the AS-REQ and AS-REP (output from wireshark):

Kerberos AS-REQ (from rpc.gssd)
Pvno: 5
MSG Type: AS-REQ (10)
KDC_REQ_BODY

       Padding: 0
       KDCOptions: 40000010 (Forwardable, Renewable OK)
       Client Name (Principal): nfs/HOST.DOMAINNAME
       Realm: REALM
       Server Name (Unknown): krbtgt/REALM
       from: 2008-11-11 12:56:53 (UTC)
       till: 2008-11-12 12:56:53 (UTC)
       Nonce: 1226408213
       Encryption Types: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 rc4-hmac des-cbc-crc des-cbc-md5 des-cbc-md4 rsa-sha1-cms rsa-md5-cms des-ede3-cbc-env rc2-cbc-env rsa-env

Kerberos AS-REP (From a linux KDC)
Pvno: 5
MSG Type: AS-REP (11)
padata: PA-ENCTYPE-INFO2
Client Realm: REALM
Client Name (Principal): nfs/HOST.home.DOMAINNAME Ticket
enc-part des-cbc-crc

So my point is what if the KDC returns something other that 'des-cbc-crc' in the AS-REP since in the AS-REQ we says we support all those encryption types.

Again this is still all theory since still don't have a functionally non-linux KDC but I'm working on it...

steved.

The AS-REQ (Authentication Service) is a request for a TGT (aka, Ticket-Granting-Ticket). This is a ticket issued by the KDC to a principal after verifying her identity (by verifying her password). This ticket is good for a period of time, allowing that principal to get tickets for other services, such as NFS, without having to use her password for every request. (Her password doesn't even go to the KDC for the AS-REQ. It is used to generate a key locally, which is used to encrypt something locally, which is sent in the AS-REQ.)

This is the exchange your patch is limiting to only DES. That is unnecessary.

The tickets for other services (like NFS) (aka Service Tickets) are obtained using a TGS-REQ (Ticket Granting Service). The TGT returned in the AS-REP is used to form the TGS request -- to verify it is still the same principal. This is where the code in gssd currently limits the encryption types that can be negotiated. We only want limit the encryption types for the session key in the NFS Service Ticket, not for all the service tickets obtained using that TGT. That is also why we DO NOT want to have

default_tkt_enctypes = des-cbc-crc # Don't do this!
default_tgs_enctypes = des-cbc-crc # Don't do this!

in the /etc/krb5.conf file. Those limit all negotiations to only using DES.

Also, it shouldn't matter if the KDC is a Linux KDC or a Solaris KDC. Modern versions of both KDCs support many encryption types besides DES. (As you can see above.)

Now the Solaris NFS client and server can handle more encryption types than Linux at the moment. That is why it is important to limit the encryption types to only DES when creating the keytab entry for the nfs/<hostname>@REALM principal for Linux machines. That gives the KDC the information it needs to only issue a Service Ticket with only a DES session key to a Solaris NFS client when it is going to talk to a Linux NFS server.

Hopefully this clears up a little without raising too many more questions!