Issue with MIT Kerberos Documentation - Developing with GSSAPI

[Frank Filz]

> 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
> GSSAPI
> 
> The feedback link on the documentation page goes to krb5-bugs at mit.edu
which
> feeds into our bug tracker, and this isn't a bug report, so I'll just
reply privately.
> 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?
> 
> Yes.
> 
> > 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
TRAILER.
> One of my colleagues wrote a test program that uses gss_wrap_iov_length on
a
> 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
the
> PADDING buffer at least must be variable size and dependent on the DATA
size.
> 
> 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
where it
> 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
single
> 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?

Thanks

Frank