Difference between revisions of "Projects/GSSAPI DCE"

Revision as of 14:10, 5 November 2008

The GSS-API AEAD project proposes to add functionality found in SSPI to MIT Kerberos; this functionality includes support for AEAD.

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.

Simplifying assumption

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.

What we're trying to do

We have a couple of goals:

• We'd like to add AEAD support to GSS-API.
• 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.

At least so far no argument has been made that the following are goals:

• In-place encryption for GSS-API
• Having an API with the same semantics as SSPI

Solution constraints

We do not want to complicate mechanism design. A consequence of the 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.

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.

If we do not constrain chunk size, we still need to make it possible 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.