krb enctype presentation available

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

krb enctype presentation available

Will Fiveash
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

Hope it helps (and let me know if there are any problems with the
presentation),
--
Will Fiveash
Sun Microsystems Inc.
Austin, TX, USA (TZ=CST6CDT)
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: krb enctype presentation available

Ken Hornstein
>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.

- 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.

--Ken
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: krb enctype presentation available

Will Fiveash
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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: krb enctype presentation available

Will Fiveash
On Thu, Jun 30, 2005 at 06:25:08PM -0500, Will Fiveash wrote:

> 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.

I've updated my presentation.  Note, the previous version had a bogus
"Sun Confidential" label at the bottom of the slides.  I've removed that
in the current version.  Sorry about that.

--
Will Fiveash
Sun Microsystems Inc.
Austin, TX, USA (TZ=CST6CDT)
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos