Projects/GSSAPI DCE - Revision history

TomYu at 04:13, 16 February 2010

2010-02-16T04:13:59Z

Lukeh at 18:37, 14 September 2009

2009-09-14T18:37:26Z

TomYu: approval

2008-12-24T15:59:58Z

approval

SamHartman: Mark Ken's comment as rejected

2008-12-22T18:54:27Z

Mark Ken's comment as rejected

SamHartman: update descriptions based on krbdev discussion

2008-12-22T18:52:54Z

update descriptions based on krbdev discussion

TomYu: fix formatting

2008-12-02T19:36:36Z

fix formatting

SamHartman: what types does a flag go with?

2008-12-01T19:53:54Z

what types does a flag go with?

SamHartman: /* Discussion */

2008-12-01T15:10:39Z

‎Discussion

SamHartman: enter review

2008-12-01T15:06:40Z

enter review

SamHartman: Add gss_wrap_aead from Luke's notes

2008-12-01T15:05:28Z

Add gss_wrap_aead from Luke's notes

← Older revision		Revision as of 04:13, 16 February 2010
Line 1:		Line 1:
−	{{project-~~completed~~}}	+	{{project-rel\|1.7}}

	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]].		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]].

← Older revision		Revision as of 18:37, 14 September 2009
Line 1:		Line 1:
−	{{project-~~approved~~}}	+	{{project-completed}}

	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]].		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]].

@@ Line 1: / Line 1: @@
-{{project-review|December 14, 2008}}
+{{project-approved}}
 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]].
@@ Line 217: / Line 217: @@
 ===Approvals===
 ===Discussion===

@@ Line 222: / Line 222: @@
 Ken Raeburn would prefer a different name than ''gss_wrap_aead'' because he believes AEAD focuses on the implementation rather than the abstract functionality.
 --[[User:SamHartman|SamHartman]] 10:10, 1 December 2008 (EST)
 Love wants us to identify what types a given flag can be used with.

@@ Line 46: / Line 46: @@
 A new structure is introduced:
 <pre>
 typedef struct gss_iov_buffer_desc_struct {
     OM_uint32 type;
     gss_buffer_desc buffer;
 } gss_iov_buffer_desc, *gss_iov_buffer_t;
@@ Line 58: / Line 56: @@
 #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 */
 </pre>
-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.
+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.    The sign_only buffer type represents associated data that will be integrity protected but even when data buffers are confidentiality protected, the sign_only buffers will not be integrity protected.  Also, 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.
@@ Line 75: / Line 75: @@
 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.
+DCE-RPC is expected to pass in a header, a sign_only buffer, a data buffer, a sign_only buffer, 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.

@@ Line 25: / Line 25: @@
 ===Supporting DCE RPC===
- We want to make it easy to implement DCE-RPC against MIT Kerberos:
+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.
@@ Line 44: / Line 44: @@
 A new structure is introduced:
-<code>
+<pre>
 typedef struct gss_iov_buffer_desc_struct {
@@ Line 66: / Line 66: @@
 #define GSS_IOV_BUFFER_FLAG_SIGN_ONLY       4   /* indicates associated data */
-</code>
+</pre>
 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.
@@ Line 82: / Line 82: @@
 ==API details==
-<code>
+<pre>
 /*
  * Sign and optionally encrypt a sequence of buffers. The buffers
@@ Line 191: / Line 191: @@
         gss_qop_t *qop_state);
-</code>
+</pre>

← Older revision		Revision as of 19:53, 1 December 2008
Line 217:		Line 217:
	Ken Raeburn would prefer a different name than ''gss_wrap_aead'' because he believes AEAD focuses on the implementation rather than the abstract functionality.		Ken Raeburn would prefer a different name than ''gss_wrap_aead'' because he believes AEAD focuses on the implementation rather than the abstract functionality.
	--[[User:SamHartman\|SamHartman]] 10:10, 1 December 2008 (EST)		--[[User:SamHartman\|SamHartman]] 10:10, 1 December 2008 (EST)
		+
		+	Love wants us to identify what types a given flag can be used with.
		+	--[[User:SamHartman\|SamHartman]] 14:53, 1 December 2008 (EST)

← Older revision		Revision as of 15:10, 1 December 2008
Line 214:		Line 214:

	===Discussion===		===Discussion===
		+
		+	Ken Raeburn would prefer a different name than ''gss_wrap_aead'' because he believes AEAD focuses on the implementation rather than the abstract functionality.
		+	--[[User:SamHartman\|SamHartman]] 10:10, 1 December 2008 (EST)

@@ Line 79: / Line 79: @@
 ===gss_*_aead===
 ==API details==
@@ Line 169: / Line 170: @@
     size_t,             /* iov_count */
     gss_iov_buffer_desc *); /* iov */
 ==Testing plan==