logo_kerberos.gif

Difference between revisions of "Release 1.7"

From K5Wiki
Jump to: navigation, search
 
(9 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[Projects/AEAD encryption API]]
 
  +
'''[http://web.mit.edu/kerberos/krb5-1.7/ How to Get MIT Kerberos Release 1.7]'''
   
   
  +
'''Release 1.7 Feature Specifications'''
  +
 
[[Projects/AEAD encryption API]]
 
The Microsoft SSPI provides an interface for in-place encryption of messages (see MS-KILE section 3.4.5.4ff). This interface also permits additional data to be included in the checksum generated to protect integrity. Such a facility is called authenticated encryption with additional data (AEAD). The SSPI works at the GSS-API layer, rather than the raw Kerberos layer.
 
The Microsoft SSPI provides an interface for in-place encryption of messages (see MS-KILE section 3.4.5.4ff). This interface also permits additional data to be included in the checksum generated to protect integrity. Such a facility is called authenticated encryption with additional data (AEAD). The SSPI works at the GSS-API layer, rather than the raw Kerberos layer.
   
Line 12: Line 15:
   
 
[[Projects/FAST]]
 
[[Projects/FAST]]
  +
FAST is a pre-authentication framework for Kerberos. It includes a mechanism for tunneling pre-authentication exchanges using armoured KDC messages. FAST provides increased resistance to passive password guessing attacks.
  +
 
[[Projects/GSSAPI DCE]]
 
[[Projects/GSSAPI DCE]]
  +
The GSS-API DCE project proposes to add functionality found in SSPI to MIT Kerberos; this functionality includes support for AEAD and support sufficient to implement DCE RPC on top of MIT Kerberos. This project depends on and is a companion to Projects/AEAD encryption API.
  +
 
[[Projects/Master Key Migration]]
 
[[Projects/Master Key Migration]]
  +
This project will provide the ability to add a new master key (with an enctype differing from the current master key) to the master key principal and stash file and then migrate the encryption of existing principals long term keys to use the new master key. In addition deletion of master keys will be provided.
  +
 
[[Projects/Masterkey Keytab Stash]]
 
[[Projects/Masterkey Keytab Stash]]
  +
The point of this small project is to change the format of the master key stash file to that of a keytab type file. This will allow the master key's KVNO to be stored along with its enctype and key data which in turn will enable an efficient implementation of master key updating.
  +
 
[[Projects/PAC and principal APIs]]
 
[[Projects/PAC and principal APIs]]
  +
Microsoft Windows uses a data structure called the PAC in order to convey authorization information. See the expired draft-brezak-win2k-krb-authz-00 for documentation. The PAC is logically a set of type-length-value elements. That is, it is a collection of typed data items, and lengths are associated with each type. Typically the data items are NDR encoded. This API provides facilities to create and sign a PAC and to extract a given typed buffer from a PAC. NDR encoders and decoders are not provided.
  +
  +
 
[[Projects/RFC 3244]]
 
[[Projects/RFC 3244]]
  +
The RFC 3244 project adds support for the Microsoft set password protocol server to MIT Kerberos. In addition, it adds support for both that protocol and the traditional kpasswd protocol over TCP. This protocol is added for better compatibility with Microsoft Windows.
  +
 
[[Projects/RFC 4537]]
 
[[Projects/RFC 4537]]
  +
RFC 4537 defines an encryption type negotiation extension to Kerberos. This option allows clients and servers to use a stronger or faster bulk encryption mechanism even if the KDC does not support it. The client indicates a set of supported encryption types in the ap-req. If the server chooses one of these encryption types then it proposes a subkey in the ap-rep with an encryption type different than that selected by the client.
  +
 
[[Projects/Remove krb4]]
 
[[Projects/Remove krb4]]
  +
The goal of this project is to remove most of the krb4 code from the Kerberos source code base.
  +
 
[[Projects/VerifyAuthData]]
 
[[Projects/VerifyAuthData]]
  +
The goals of this project are to:
  +
  +
* change the behaviour of krb5_rd_req() to always verify known authorization data elements
  +
* provide an attribute-based GSS interface for inquiry and submission of authorization information ([http://www.ietf.org/id/draft-ietf-kitten-gssapi-naming-exts-05.txt draft-ietf-kitten-gssapi-naming-exts])
  +
* provide an attribute-based plugin interface for verification and serialization of authorization information
  +
* encourage the use of positive authorization data by providing sample KDC and application plugins
  +
 
[[Projects/domain realm referrals]]
 
[[Projects/domain realm referrals]]
  +
Eliminates the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral (draft-ietf-krb-wg-kerberos-referrals) support in the KDC and providing the mapping information to clients through that protocol. Modern client code (MIT, Heimdal, and Microsoft, at least) should contain all the support needed to take advantage of this.
  +
 
[[Projects/replay cache collision avoidance]]
 
[[Projects/replay cache collision avoidance]]
  +
In order to avoid false positives we require that the replay cache data structure store sufficient data to be able to distinguish between two authenticators while at the same time maintaining compatibility with existing deployments.

Latest revision as of 09:03, 21 November 2009

How to Get MIT Kerberos Release 1.7


Release 1.7 Feature Specifications

Projects/AEAD encryption API

The Microsoft SSPI provides an interface for in-place encryption of messages (see MS-KILE section 3.4.5.4ff). This interface also permits additional data to be included in the checksum generated to protect integrity. Such a facility is called authenticated encryption with additional data (AEAD). The SSPI works at the GSS-API layer, rather than the raw Kerberos layer.

This project proposes to extend the raw Kerberos cryptographic API (krb5_c_*) in order to make it possible to implement these SSPI facilities in an extension to the GSS-API. The ultimate consumer of these applications is typically DCE-style RPC, although the facilities could be used by other applications.

Projects/Aliases

This project proposes to add two features. The first is support for Unicode principal names and case insensitive principal search. The goal of this project is to get behavior more similar to Microsoft and to search for principals in a manner that supports international use somewhat better. This includes case insensitive search and support for ignoring accents in search.

Protocol extensions for general internationalization or character set conversion are specifically out of scope. The second feature is generalized support for name canonicalization and server principal aliases.

Projects/FAST

FAST is a pre-authentication framework for Kerberos. It includes a mechanism for tunneling pre-authentication exchanges using armoured KDC messages. FAST provides increased resistance to passive password guessing attacks.

Projects/GSSAPI DCE

The GSS-API DCE project proposes to add functionality found in SSPI to MIT Kerberos; this functionality includes support for AEAD and support sufficient to implement DCE RPC on top of MIT Kerberos. This project depends on and is a companion to Projects/AEAD encryption API.

Projects/Master Key Migration

This project will provide the ability to add a new master key (with an enctype differing from the current master key) to the master key principal and stash file and then migrate the encryption of existing principals long term keys to use the new master key. In addition deletion of master keys will be provided.

Projects/Masterkey Keytab Stash

The point of this small project is to change the format of the master key stash file to that of a keytab type file. This will allow the master key's KVNO to be stored along with its enctype and key data which in turn will enable an efficient implementation of master key updating.

Projects/PAC and principal APIs

Microsoft Windows uses a data structure called the PAC in order to convey authorization information. See the expired draft-brezak-win2k-krb-authz-00 for documentation. The PAC is logically a set of type-length-value elements. That is, it is a collection of typed data items, and lengths are associated with each type. Typically the data items are NDR encoded. This API provides facilities to create and sign a PAC and to extract a given typed buffer from a PAC. NDR encoders and decoders are not provided.


Projects/RFC 3244

The RFC 3244 project adds support for the Microsoft set password protocol server to MIT Kerberos. In addition, it adds support for both that protocol and the traditional kpasswd protocol over TCP. This protocol is added for better compatibility with Microsoft Windows.

Projects/RFC 4537

RFC 4537 defines an encryption type negotiation extension to Kerberos. This option allows clients and servers to use a stronger or faster bulk encryption mechanism even if the KDC does not support it. The client indicates a set of supported encryption types in the ap-req. If the server chooses one of these encryption types then it proposes a subkey in the ap-rep with an encryption type different than that selected by the client.

Projects/Remove krb4

The goal of this project is to remove most of the krb4 code from the Kerberos source code base.

Projects/VerifyAuthData

The goals of this project are to:

  • change the behaviour of krb5_rd_req() to always verify known authorization data elements
  • provide an attribute-based GSS interface for inquiry and submission of authorization information (draft-ietf-kitten-gssapi-naming-exts)
  • provide an attribute-based plugin interface for verification and serialization of authorization information
  • encourage the use of positive authorization data by providing sample KDC and application plugins
Projects/domain realm referrals

Eliminates the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral (draft-ietf-krb-wg-kerberos-referrals) support in the KDC and providing the mapping information to clients through that protocol. Modern client code (MIT, Heimdal, and Microsoft, at least) should contain all the support needed to take advantage of this.

Projects/replay cache collision avoidance

In order to avoid false positives we require that the replay cache data structure store sufficient data to be able to distinguish between two authenticators while at the same time maintaining compatibility with existing deployments.