[24195] in Kerberos
Re: krb enctype presentation available
daemon@ATHENA.MIT.EDU (Will Fiveash)
Thu Jun 30 19:28:03 2005
Date: Thu, 30 Jun 2005 18:25:08 -0500
From: Will Fiveash <William.Fiveash@sun.com>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Message-ID: <20050630232507.GD6743@sun.com>
Mail-Followup-To: Ken Hornstein <kenh@cmf.nrl.navy.mil>,
MIT Kerberos List <kerberos@MIT.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200506302121.j5ULLcvF010102@ginger.cmf.nrl.navy.mil>
cc: MIT Kerberos List <kerberos@mit.edu>
Errors-To: kerberos-bounces@mit.edu
On Thu, Jun 30, 2005 at 05:21:40PM -0400, Ken Hornstein wrote:
> >I created a presentation PDF a while back that I've placed on the Web
> >which goes into detail on Kerberos enctypes in terms of how they are
> >used, negotiated and controlled via *.conf parameters. It can be
> >downloaded via my blog:
> >
> >http://blogs.sun.com/roller/page/wfiveash?entry=everything_you_wanted_to_know
>
> This is a good presentation. I have two comments:
>
> - In my experience, encryption type settings are the herpes of the Kerberos
> world - once they get out "into the wild", they spread magically to
> other systems and it's damn hard to get rid of them. If you have
> your applicatation server enctypes set correctly, you should almost
> never need them. I'd stress that setting these enctype settings on
> the client should only be used rarely (say, you're using MIT Kerberos
> that supports AES, but one of your developers uses a Java Kerberos
> implementation that only supports single-DES). I know you mention this
> in your last slide, but I'd put something stronger in there.
Yeah, I'll stress doing the "right thing" more as this is one of the
reasons I created the presentation (helping admins understand the entype
knobs to get it right or at least leave well enough alone).
> - I know you know this, but on slide 8 you imply with the diagrams that
> the ticket in the AS_REP is double-encrypted, and of course it's not;
> only the session key and a few other bits are encrypted by the user's
> long-term key. A minor nit, but I only wanted to point it out for
> accuracy's sake.
Thanks for the feedback. I'll tweak the presentation to make it more
accurate.
--
Will Fiveash
Sun Microsystems Inc.
Austin, TX, USA (TZ=CST6CDT)
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
