Issue with MIT Kerberos Documentation - Developing with GSSAPI
ffilzlnx at mindspring.com
Wed May 8 10:46:14 EDT 2019
> From: Greg Hudson [mailto:ghudson at mit.edu]
> Sent: Tuesday, May 7, 2019 10:01 PM
> To: Frank Filz <ffilzlnx at mindspring.com>
> Subject: Re: RE: Issue with MIT Kerberos Documentation - Developing with
> The feedback link on the documentation page goes to krb5-bugs at mit.edu
> feeds into our bug tracker, and this isn't a bug report, so I'll just
> We have a couple of public mailing lists for these sorts of questions;
> krbdev at mit.edu is reasonable for this since it's coding-oriented, and
> kerberos at mit.edu is for more operational questions.
Sorry, I'll take this to the list...
> > (though I do have a question, is it definitely the case that the MIC
> token needs to be in a single buffer?
> > I'm less clear on how to use gss_unwrap_iov. The test program does a
> gss_wrap_iov immediately followed by using the SAME iov to do
> gss_unwrap_iov. But if I have received an encrypted message from an RPC
> client, I have no idea of the side of the HEADER, DATA, PADDING, and
> One of my colleagues wrote a test program that uses gss_wrap_iov_length on
> set of empty buffers to find the size of the DATA, PADDING, and TRAILER
> buffers, but I believe that only works if they are all of fixed size. But
> PADDING buffer at least must be variable size and dependent on the DATA
> The GSS_C_BUFFER_TYPE_STREAM buffer type is intended for this use case.
> It allows you to decrypt the ciphertext in place without knowing exactly
> is within the wrap token. See the last part of the "IOV message wrapping"
> section starting with "Alternatively, gss_unwrap_iov may be called with a
> STREAM buffer..." and the example code there.
I see the STREAM buffer type, unfortunately, I have the wrap token
potentially split across multiple buffers due to the way our network code
handles the stream. I am looking for the best way to decrypt without having
to do a data copy.
If that isn't currently how STREAM works, would it be possible in the future
to support an iov of STREAM buffers?
More information about the krbdev