Difference between revisions of "Projects/GSSAPI DCE"
From K5Wiki
< Projects
SamHartman (talk | contribs) m (Projects/GSSAPI AEAD moved to Projects/GSSAPI DCE: The primary goal of the project relates to DCE rather than AEAD) |
SamHartman (talk | contribs) (Reflect discussions about the goals of the project) |
||
| Line 1: | Line 1: | ||
{{project-early}} |
{{project-early}} |
||
| − | The '''GSS-API |
+ | 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]]. |
| − | ==SSPI architecture== |
||
| + | |||
| + | ==Background== |
||
| + | |||
| + | ===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-messageprotection: |
||
| Line 12: | Line 15: | ||
* 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. |
* 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== |
+ | ===GSS-API architecture=== |
| Line 20: | Line 23: | ||
* The application does not control placement or order of chunks. |
* The application does not control placement or order of chunks. |
||
| − | ==Simplifying assumption== |
||
| + | ===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 manages its own padding. |
||
| − | It's not clear that SSPI supports more than one data chunk in the decryption operation. Applications cannot manipulate encrypted data, so the value of having a lot of encrypted chunks may be low. |
||
| + | There are also changes to the context establishment procedure signaled by a DCE_STYLE flag; RFC 4757 briefly describes these changes. |
||
| − | ==What we're trying to do== |
||
| + | ===AEAD support=== |
||
| − | We have a couple of goals: |
||
| + | 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. |
||
| − | * We'd like to add AEAD support to GSS-API. |
||
| + | ==Basic approach== |
||
| − | * 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. |
||
| − | * We want an API that allows people to write non-SSPI applications that can parse anything the SSPI commonly parses for the kerberos package. |
||
| + | Two new sets of APIs will be introduced. The first, the '''gss_iov''' API is similar to the [[Projects/AEAD encryption API|AEAD encryption API]] and to [[SSPI]]. The second adds support for AEAD while minimizing differences with the original GSS-API. |
||
| + | ===gss_iov=== |
||
| − | At least so far no argument has been made that the following are goals: |
||
| + | A new structure is introduced: |
||
| − | * In-place encryption for GSS-API |
||
| + | <code> |
||
| − | * Having an API with the same semantics as SSPI |
||
| − | ==Solution constraints== |
||
| + | 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; |
||
| + | </code> |
||
| − | We do not want to complicate mechanism design. A consequence of the [[Projects/GSS-API mechanism plug-in support|mechanism glue project]] is that we want it to be relatively easy to write a new GSS-API mechanism. So, we want to be careful about introducing parallel APIs; clearly some of that is needed but we want to minimize what is needed. We also want to avoid making it significantly harder to create stackable mechanisms. |
||
| + | 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 |
||
| − | We don't want to lose the generality of GSS-API. IN particular adding a constraint that token chunks are always fixed-size or that the pad chunk is always fixed-size and small is problematic. |
||
| + | ===gss_*_aead=== |
||
| − | If we do not constrain chunk size, we still need to make it possible |
||
| + | ==API details== |
||
| − | to use mechanisms that do meet DCE's constraints with DCE. |
||
| − | This may be as simple as telling the user how to pull apart the buffer. If multiple data chunks are common, it may be significantly more complicated. |
||
| − | We also want to make it easy to figure out whether a mechanism can be used with DCE. |
||
| + | ==Testing plan== |
||
Revision as of 16:38, 11 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.
Contents
Background
SSPI architecture
The SSPI for connection-oriented contexts provides the following service model for per-messageprotection:
- 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 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;
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
