On Sat, 2005-09-10 at 01:56 -0400, Ken Raeburn wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sep 10, 2005, at 00:29, Andrew Bartlett wrote: > > This patch adds a new function: > > OM_uint32 > > gss_wrap_size ( > > OM_uint32 * /*minor_status*/, > > const gss_ctx_id_t /*context_handle*/, > > int /*conf_req_flag*/, > > gss_qop_t /*qop_req*/, > > OM_uint32 /*req_input_size*/, > > OM_uint32 * /*output_size*/ > > ); > > > > This tells the caller what the wrapped size would be, given an input > > size. From there, I can tell what the 'signature' portion would be. > > What is there in the GSSAPI specification that makes you think that > the output size will always be uniquely determined by the input size, > independent of the data? Granted, it's probably usually true, > perhaps true with all the mechanisms Samba is likely to run into, but > I do think it's an assumption unsupported by the GSSAPI specification. > > For example, does the GSSAPI allow for a "wrap" token encoding to > first compress the data? (Whether you'd *want* to is a different > question, and beside the point, which is that the GSSAPI allows for > mechanisms for which this function cannot be implemented as > described.) Upper or lower limits, perhaps; a precise size, I don't > think so. > > I think it's also a mistake to assume that there's always a trivially > separable "signature portion". Sadly it is a mistake that DCE/RPC forces on us: While I presume you could simply expand the data portion for the full wrapped data, Microsoft chose to place the signature in the traditional place, separate from the main data. We have to be compatible with that. Now, I'm being a little lazy, because I should have just implemented the gss_wrap_ex() interface, which handles both this separation and AEAD (the signature is over the data and the headers). This is the interface that lukeh proposes in his mechglue branch, but he cheats and uses gss_wrap_size_limit() to similar effect, rather than actually splitting things up for gssapi/krb5. (He presumably splits things up, as is natural, for NTLMSSP). However, I didn't like some of the corner cases in the use of _limit(), as it made assumptions about the data size (which changes the signature size, due to the asn1 wrapping including a length). So, I could have done that, but this creates problems for NTLMSSP, which has an AEAD negotiated option, and because the headers are signed, it therefore requires the caller to know the data and signature size before calling the function anyway! As such, I'm in a no-win situation, and took the least ugly way out :-) Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Samba Developer, SuSE Labs, Novell Inc. http://suse.de Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net
This is a digitally signed message part