logo_kerberos.gif

Difference between revisions of "Projects/GSSAPI DCE"

From K5Wiki
Jump to: navigation, search
(Reflect discussions about the goals of the project)
(Add more details on DCE style)
Line 8: Line 8:
 
===SSPI architecture===
 
===SSPI architecture===
   
The SSPI for connection-oriented contexts provides the following service model for per-messageprotection:
+
The SSPI for connection-oriented contexts provides the following service model for per-message protection:
 
* Security mechanisms may add small fixed-size padding (less than 8 bytes) to a message.
 
* Security mechanisms may add small fixed-size padding (less than 8 bytes) to a message.
 
* Security mechanisms add fixed size mechanism-specific tokens to messages.
 
* Security mechanisms add fixed size mechanism-specific tokens to messages.
Line 28: Line 28:
 
* DCE RPC separates the security token information from the confidentiality protected information and places it elsewhere in the network PDU
 
* DCE RPC separates the security token information from the confidentiality protected information and places it elsewhere in the network PDU
 
* DCE uses AEAD to integrity protect parts of the message that are not confidentiality protected.
 
* DCE uses AEAD to integrity protect parts of the message that are not confidentiality protected.
  +
* DCE requires two separate AEAD buffers.
 
* DCE manages its own padding.
 
* DCE manages its own padding.
   
Line 35: Line 36:
   
 
DCE requires adding AEAD support to the GSS mechanism. However an application implementing DCE RPC will typically want in-place encryption APIs that expose significant detail about the structure of the GSS token. For some classes of application, this is desirable. However it is highly undesirable to force an application to pay attention to the details of GSS tokens in order to take advantage of features like AEAD. Doing so increases the probability that the application will depend on some semantic of the token and thus will not be portable across mechanisms.
 
DCE requires adding AEAD support to the GSS mechanism. However an application implementing DCE RPC will typically want in-place encryption APIs that expose significant detail about the structure of the GSS token. For some classes of application, this is desirable. However it is highly undesirable to force an application to pay attention to the details of GSS tokens in order to take advantage of features like AEAD. Doing so increases the probability that the application will depend on some semantic of the token and thus will not be portable across mechanisms.
  +
 
==Basic approach==
 
==Basic approach==
   
Line 49: Line 51:
 
gss_buffer_desc buffer;
 
gss_buffer_desc buffer;
 
} gss_iov_buffer_desc, *gss_iov_buffer_t;
 
} gss_iov_buffer_desc, *gss_iov_buffer_t;
  +
  +
#define GSS_C_NO_IOV_BUFFER ((gss_iov_buffer_t)0)
  +
  +
#define GSS_IOV_BUFFER_TYPE_EMPTY 0
  +
#define GSS_IOV_BUFFER_TYPE_DATA 1 /* Packet data */
  +
#define GSS_IOV_BUFFER_TYPE_HEADER 2 /* Mechanism header */
  +
#define GSS_IOV_BUFFER_TYPE_TRAILER 7 /* Mechanism trailer */
  +
#define GSS_IOV_BUFFER_TYPE_PADDING 9 /* Padding */
  +
#define GSS_IOV_BUFFER_TYPE_STREAM 10 /* Complete wrap token */
  +
  +
  +
#define GSS_IOV_BUFFER_FLAG_ALLOCATE 1 /* indicates GSS should allocate */
  +
#define GSS_IOV_BUFFER_FLAG_ALLOCATED 2 /* indicates gss_release_iov_buffer should free */
  +
#define GSS_IOV_BUFFER_FLAG_SIGN_ONLY 4 /* indicates associated data */
  +
 
</code>
 
</code>
   
A set of APIs is created that takes an array of ''gss_iov_buffer_desc'' structures for per-message operations. Several types of buffers are defined. A DCE style application would typically pass in
 
  +
A set of APIs is created that takes an array of ''gss_iov_buffer_desc'' structures for per-message operations. Several types of buffers are defined. The header buffer represents mechanism-specific headers added to a security token. In SSPI, this buffer is called the token. The trailer buffer is mechanism-specific security information added to the end of application data; this buffer typically does not exist in SSPI applications. The padding buffer contains padding bytes necessary for block-cipher alignment. Data buffers contain application data to be integrity or confidentiality protected. If the header, data buffers, padding and trailer buffers are concatenated in that order, the resulting token should be a valid input to gss_unwrap.
  +
  +
The SIGN_ONLY flag indicates that a particular data buffer is integrity protected but not encrypted. This buffer can be sent over the wire, or reconstructed by the remote application.
  +
  +
SSPI compatible applications will typically be unable to pass in a trailer buffer. Mechanisms should try to function even when no trailer is available. The Kerberos mechanism can always produce valid output without a trailer, although if a trailer is provided, it may be used.
  +
  +
DCE-RPC is expected to pass in a header, three data buffers (two of them SIGN_ONLY), and potentially padding.
  +
  +
Applications will typically set up their data buffers along with placeholder entries for the other buffers they need and then call gss_wrap_iov_length.
   
 
===gss_*_aead===
 
===gss_*_aead===

Revision as of 17:02, 24 November 2008

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.


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.


Background

SSPI architecture

The SSPI for connection-oriented contexts provides the following service model for per-message protection:

  • Security mechanisms may add small fixed-size padding (less than 8 bytes) to a message.
  • Security mechanisms add fixed size mechanism-specific tokens to messages.
  • Messages may contain data chunks that are encrypted and read_only chunks that are integrity protected but not encrypted.
  • So a message looks like (data+ readonly* pad token), although all the components can be reordered. In particular, when interoperating with GSS-API the token comes at the front.
  • The application gets to control the placement of token, data, read_only and pad chunks both in the input and output; chunks cannot change size.

GSS-API architecture

  • Application passes in a token for per-message protection
  • Gss-API returns a token, typically of a different size.
  • No support for AEAD
  • The application does not control placement or order of chunks.

Supporting DCE RPC

We want to make it easy to implement DCE-RPC against MIT Kerberos:
  • DCE RPC separates the security token information from the confidentiality protected information and places it elsewhere in the network PDU
  • DCE uses AEAD to integrity protect parts of the message that are not confidentiality protected.
  • DCE requires two separate AEAD buffers.
  • DCE manages its own padding.

There are also changes to the context establishment procedure signaled by a DCE_STYLE flag; RFC 4757 briefly describes these changes.

AEAD support

DCE requires adding AEAD support to the GSS mechanism. However an application implementing DCE RPC will typically want in-place encryption APIs that expose significant detail about the structure of the GSS token. For some classes of application, this is desirable. However it is highly undesirable to force an application to pay attention to the details of GSS tokens in order to take advantage of features like AEAD. Doing so increases the probability that the application will depend on some semantic of the token and thus will not be portable across mechanisms.

Basic approach

Two new sets of APIs will be introduced. The first, the gss_iov API is similar to the AEAD encryption API and to SSPI. The second adds support for AEAD while minimizing differences with the original GSS-API.

gss_iov

A new structure is introduced:

typedef struct gss_iov_buffer_desc_struct {

   OM_uint32 type;
   OM_uint32 flags;
   gss_buffer_desc buffer;

} gss_iov_buffer_desc, *gss_iov_buffer_t;

  1. define GSS_C_NO_IOV_BUFFER ((gss_iov_buffer_t)0)
  1. define GSS_IOV_BUFFER_TYPE_EMPTY 0
  2. define GSS_IOV_BUFFER_TYPE_DATA 1 /* Packet data */
  3. define GSS_IOV_BUFFER_TYPE_HEADER 2 /* Mechanism header */
  4. define GSS_IOV_BUFFER_TYPE_TRAILER 7 /* Mechanism trailer */
  5. define GSS_IOV_BUFFER_TYPE_PADDING 9 /* Padding */
  6. define GSS_IOV_BUFFER_TYPE_STREAM 10 /* Complete wrap token */


  1. define GSS_IOV_BUFFER_FLAG_ALLOCATE 1 /* indicates GSS should allocate */
  2. define GSS_IOV_BUFFER_FLAG_ALLOCATED 2 /* indicates gss_release_iov_buffer should free */
  3. define GSS_IOV_BUFFER_FLAG_SIGN_ONLY 4 /* indicates associated data */

A set of APIs is created that takes an array of gss_iov_buffer_desc structures for per-message operations. Several types of buffers are defined. The header buffer represents mechanism-specific headers added to a security token. In SSPI, this buffer is called the token. The trailer buffer is mechanism-specific security information added to the end of application data; this buffer typically does not exist in SSPI applications. The padding buffer contains padding bytes necessary for block-cipher alignment. Data buffers contain application data to be integrity or confidentiality protected. If the header, data buffers, padding and trailer buffers are concatenated in that order, the resulting token should be a valid input to gss_unwrap.

The SIGN_ONLY flag indicates that a particular data buffer is integrity protected but not encrypted. This buffer can be sent over the wire, or reconstructed by the remote application.

SSPI compatible applications will typically be unable to pass in a trailer buffer. Mechanisms should try to function even when no trailer is available. The Kerberos mechanism can always produce valid output without a trailer, although if a trailer is provided, it may be used.

DCE-RPC is expected to pass in a header, three data buffers (two of them SIGN_ONLY), and potentially padding.

Applications will typically set up their data buffers along with placeholder entries for the other buffers they need and then call gss_wrap_iov_length.

gss_*_aead

API details

Testing plan