Hi,
Since MIT released their kerberos 1.8 software today and it disables
single DES by default, what steps should we take to educate new users
about this? Any suggested specfiic documentation changes?
Thanks,
Jason
-------- Original Message --------
Subject: krb5-1.8 is released
Date: Tue, 02 Mar 2010 18:44:38 -0500
From: Tom Yu <[email protected]>
Reply-To: [email protected]
To: [email protected]
The MIT Kerberos Team announces the availability of MIT Kerberos 5
Release 1.8. Please see below for a list of some major changes
included, or consult the README file in the source tree for a more
detailed list of significant changes.
RETRIEVING KERBEROS 5 RELEASE 1.8
=================================
You may retrieve the Kerberos 5 Release 1.8 source from the
following URL:
http://web.mit.edu/kerberos/dist/
The homepage for the krb5-1.8 release is:
http://web.mit.edu/kerberos/krb5-1.8/
Further information about Kerberos 5 may be found at the following
URL:
http://web.mit.edu/kerberos/
and at the MIT Kerberos Consortium web site:
http://www.kerberos.org/
DES transition
==============
The krb5-1.8 release disables single-DES cryptosystems by default. As
a result, you may need to add the libdefaults setting
"allow_weak_crypto = true" to communicate with existing Kerberos
infrastructures if they do not support stronger ciphers.
The Data Encryption Standard (DES) is widely recognized as weak. The
krb5-1.7 release contains measures to encourage sites to migrate away
- From using single-DES cryptosystems. Among these is a configuration
variable that enables "weak" enctypes, which now defaults to "false"
beginning with krb5-1.8. The krb5-1.8 release includes additional
measures to ease the transition away from single-DES. These
additional measures include:
* enctype config enhancements (so you can do "DEFAULT +des", etc.)
* new API to allow applications (e.g. AFS) to explicitly reenable weak
crypto
* easier kadmin history key changes
Major changes in 1.8
====================
The krb5-1.8 release contains a large number of changes, featuring
improvements in the following broad areas:
* Code quality
* Developer experience
* Performance
* End-user experience
* Administrator experience
* Protocol evolution
Code quality:
* Move toward test-driven development -- new features have test code,
or at least written testing procedures.
* Remove applications to a separate distribution to simplify
independent maintenance.
* Increase conformance to coding style
+ "The great reindent"
+ Selective refactoring
Developer experience:
* Crypto modularity -- vendors can more easily substitute their own
crypto implementations, which might be hardware-accelerated or
validated to FIPS 140, for the builtin crypto implementation that
has historically shipped as part of MIT Kerberos. Currently, only
an OpenSSL provider is included, but others are planned for the
future.
* Move toward improved KDB interface
* Improved API for verifying and interrogating authorization data
Performance:
* Investigate and remedy repeatedly-reported performance bottlenecks.
* Encryption performance -- new crypto API with opaque key structures,
to allow for optimizations such as caching of derived keys
End-user experience:
* Reduce DNS dependence by implementing an interface that allows
client library to track whether a KDC supports service principal
referrals.
Administrator experience:
* Disable DES by default -- this reduces security exposure from using
an increasingly insecure cipher.
* More versatile crypto configuration, to simplify migration away from
DES -- new configuration syntax to allow inclusion and exclusion of
specific algorithms relative to a default set.
* Account lockout for repeated login failures -- mitigates online
password guessing attacks, and helps with some enterprise regulatory
compliance.
* Bridge layer to allow Heimdal HDB modules to act as KDB backend
modules. This provides a migration path from a Heimdal to an MIT
KDC.
Protocol evolution:
* FAST enhancements -- preauthentication framework enhancements to
allow a client to securely negotiate the use of FAST with a KDC of
unknown capabilities.
* Microsoft Services for User (S4U) compatibility: S4U2Self, also
known as "protocol transition", allows for service to ask a KDC for
a ticket to themselves on behalf of a client authenticated via a
different means; S4U2Proxy allows a service to ask a KDC for a
ticket to another service on behalf of a client.
* Anonymous PKINIT -- allows the use of public-key cryptography to
anonymously authenticate to a realm
* Support doing constrained delegation similar to Microsoft's
S4U2Proxy without the use of the Windows PAC. This functionality
uses a protocol compatible with Heimdal.
_______________________________________________
kerberos-announce mailing list
[email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos-announce
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
