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

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

[Steve Dickson]

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 <steved@redhat.com>
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 <steved@redhat.com>

diff --git a/utils/gssd/krb5_util.c b/utils/gssd/krb5_util.c
index 77814bc..7f131c9 100644
--- a/utils/gssd/krb5_util.c
+++ b/utils/gssd/krb5_util.c
@@ -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");

Re: [PATCH] rpc.gssd: Don't supply the KDC with unsupported encryption types

[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.  That transaction doesn't need to (and shouldn't) have encryption
types limited.  When we get a service ticket to talk to an NFS server,
we need to limit the encryption types to those supported by the
kernel.  The current code should be doing that.  If you find that
isn't the case, let me know.


K.C.

On Tue, Nov 11, 2008 at 11:40 AM, Steve Dickson <SteveD@redhat.com> wrote:
> 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 <steved@redhat.com>
> 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 <steved@redhat.com>
>
> diff --git a/utils/gssd/krb5_util.c b/utils/gssd/krb5_util.c
> index 77814bc..7f131c9 100644
> --- a/utils/gssd/krb5_util.c
> +++ b/utils/gssd/krb5_util.c
> @@ -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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

Re: [PATCH] rpc.gssd: Don't supply the KDC with unsupported encryption types

[Steve Dickson]

Kevin Coffman wrote:
> 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.

Re: [PATCH] rpc.gssd: Don't supply the KDC with unsupported encryption types

[Kevin Coffman]

On Tue, Nov 11, 2008 at 3:05 PM, Steve Dickson <SteveD@redhat.com> wrote:
>
>
> Kevin Coffman wrote:
>> 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!

K.C.

Re: [PATCH] rpc.gssd: Don't supply the KDC with unsupported encryption types

[Steve Dickson]

Kevin Coffman wrote:
> 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!
It did... thanks!

It turns out there was bug in krb5-libs... Image that! 8-)

steved.