[19930] in Kerberos_V5_Development
RE: RE: Issue with MIT Kerberos Documentation - Developing with GSSAPI
daemon@ATHENA.MIT.EDU (Frank Filz)
Wed May 8 10:46:28 2019
From: Frank Filz <ffilzlnx@mindspring.com>
To: "'Greg Hudson'" <ghudson@mit.edu>, <krbdev@mit.edu>
In-Reply-To: <52ee8861-5453-8826-6462-cf6dc5afb828@mit.edu>
Date: Wed, 8 May 2019 07:46:14 -0700
Message-ID: <075101d505ac$c9e094b0$5da1be10$@mindspring.com>
MIME-Version: 1.0
Content-Language: en-us
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
> From: Greg Hudson [mailto:ghudson@mit.edu]
> Sent: Tuesday, May 7, 2019 10:01 PM
> To: Frank Filz <ffilzlnx@mindspring.com>
> Subject: Re: RE: Issue with MIT Kerberos Documentation - Developing with
> GSSAPI
>
> The feedback link on the documentation page goes to krb5-bugs@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@mit.edu is reasonable for this since it's coding-oriented, and
> kerberos@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
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
