[17591] in Kerberos_V5_Development
Re: Use keytab to select etypes in krb5_get_init_creds_keytab()
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sun Apr 15 19:17:45 2012
Message-ID: <4F8B5713.7070303@mit.edu>
Date: Sun, 15 Apr 2012 19:17:39 -0400
From: Greg Hudson <ghudson@mit.edu>
MIME-Version: 1.0
To: Stef Walter <stefw@gnome.org>
In-Reply-To: <4F848F53.2060309@gnome.org>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On 04/10/2012 03:51 PM, Stef Walter wrote:
> The attached patch fixes the issue. If the
> krb5_get_init_creds_opt_set_etype_list() has not been called on the
> option context passed to krb5_get_init_creds_keytab() then the keytab is
> enumerated for the enctypes that are available for the given principal.
> The patch sorts the enctypes so 'weak' ones come last.
I do want this feature, but I have a few concerns about the patch:
1. This doesn't work with krb5_init_creds_set_keytab().
2. qsort() isn't a stable sort, so the resulting order of enctypes is
unpredictable.
3. This patch could introduce enctypes not present in default_tkt_enctypes.
4. This patch could result in requesting weak enctypes when
allow_weak_enctypes is false.
Heimdal's approach doesn't have problems (1) or (2) but I think does
have problem (3), and would have problem (4) except that Heimdal pushes
allow_weak_enctypes down into the crypto layer. I think what I would
like to see is:
1. Make krb5_get_init_creds_keytab use krb5_init_creds_init and
krb5_init_creds_set_keytab. This will require some care because of the
use_master fallback.
2. In krb5_init_creds_set_keytab, make a temporary list of the etypes
present in the keytab (for the client principal) and then filter the
current ctx->request->ktype list for membership in etypes, without
changing the order.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
