GSSAPI AEAD API, rrc and memory layout

[Sam Hartman]

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.


Thoughts?

--Sam