GSSAPI AEAD API, rrc and memory layout

[Stefan (metze) Metzmacher]

Sam Hartman schrieb:
> I'm doing the code review for the GSS-API AEAD implementation.
> 
> RFC 4121 has a concept called the right rotation count (RRC) that
> describes how much a token has been rotated in memory.  The intent is
> to allow supporting mechanisms like Microsoft SSPI that do not support
> adding text at the end.
> 
> RFC 4121 requires that all implementations accept any value of the
> RRC, including values greater than the size of the token.
> 
> The AEAD API does this for stream buffer types.
> 
> However if the API is passed in header, trailer and data buffers, it
> is very selective in what rrc values it supports.
> 
> Whether this is a problem kind of boils down to what it means to use
> the buffer types on decrypt.  Are these buffer types hint about how
> the data is layed out, or is it actually a requirement that the header
> be in the header chunk.
> 
> 
> I think that in the interest of interop and being liberal in what we
> receive, we probably want to accept any rrc value.  However I want to
> bring it up here, as it seems like a lot of special-case code that
> will only get used when we test it and if someone else comes up with a
> strange implementation.
> 
> Note that it is only possible to handle RRC in a well defined manner
> if the length of the header buffer plus length of the trailer buffer,
> plus length of the pad buffer is the header length plus the trailer
> length, plus the pad length.  In other words, you can move the
> overhead around, possibly even having it land on data once rotated,
> but you need to have the right amount of overhead or something is very
> wrong.
> 
> 
> If we do decide to handle RRC, then presumably what we'd do is write a
> rotate_iov function that would produce a new gss_iov_buffer_destc *
> (array) and that would move things around in memory.  The lengths of
> all the data buffers , the relative ordering of the data and sign_only
> buffers, and the memory locations of the data buffers will be
> constant.  The header and trailer buffers will probably need to get
> reallocated and copied as their length may change.

I think we need to able to receive any RRC and maybe use a rotate_iov
function, but in the end the DATA needs to end up in the DATA_BUFFERs.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20081215/eb57fb51/attachment.bin