RE: RE: Issue with MIT Kerberos Documentation - Developing with GSSAPI

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: RE: Issue with MIT Kerberos Documentation - Developing with GSSAPI

Frank Filz
> From: Greg Hudson [mailto:[hidden email]]
> Sent: Tuesday, May 7, 2019 10:01 PM
> To: Frank Filz <[hidden email]>
> Subject: Re: RE: Issue with MIT Kerberos Documentation - Developing with
> GSSAPI
>
> The feedback link on the documentation page goes to [hidden email]
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;
> [hidden email] is reasonable for this since it's coding-oriented, and
> [hidden email] 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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Issue with MIT Kerberos Documentation - Developing with GSSAPI

Greg Hudson
On 5/8/19 10:46 AM, Frank Filz wrote:> 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.

Yeah, the interface is designed for applications with specific packet
formats, not ones where a split could happen anywhere.

> If that isn't currently how STREAM works, would it be possible in the future
> to support an iov of STREAM buffers?

Possibly, though I can't promise anything.  The code to handle the
current contract is pretty complicated, and dealing with a split outside
of the data segment (inside the padding, for instance) would add a new
dimension to that.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

RE: Issue with MIT Kerberos Documentation - Developing with GSSAPI

Frank Filz
> On 5/8/19 10:46 AM, Frank Filz wrote:> 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.
>
> Yeah, the interface is designed for applications with specific packet formats, not
> ones where a split could happen anywhere.
>
> > If that isn't currently how STREAM works, would it be possible in the
> > future to support an iov of STREAM buffers?
>
> Possibly, though I can't promise anything.  The code to handle the current
> contract is pretty complicated, and dealing with a split outside of the data
> segment (inside the padding, for instance) would add a new dimension to that.

I'd be happy with one that could only deal with a split within the data, but you would need a gss_unwrap_iov_length to handle it. I'm ok with copying HEADER, PADDING, and TRAILER to a single buffer, they aren't long and often won't be split.

Hmm, is split padding really a problem? I can see split HEADER or TRAILER being difficult to work with.

Thanks

Frank


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev