Hi Chuck,
I noticed an interesting behaviour by the linux server. If I were to
mount the linux server with vers=4.0,sec=sys,xprtsec=tls, acquire a
delegation, and trigger a CB_RECALL, then it is done with gss
integrity. Why is that? I thought callback is supposed to be done with
the same security flavor as the forechannel. But then also callback
isn't done over TLS. Should the callback be done over TLS (and it's a
future implementation to do for client/server)? Or is this a spec
restriction/limitation?
Thank you.
Howdy -
> On Jun 5, 2024, at 10:34 AM, Olga Kornievskaia <[email protected]> wrote:
>
> Hi Chuck,
>
> I noticed an interesting behaviour by the linux server. If I were to
> mount the linux server with vers=4.0,sec=sys,xprtsec=tls, acquire a
> delegation, and trigger a CB_RECALL, then it is done with gss
> integrity. Why is that? I thought callback is supposed to be done with
> the same security flavor as the forechannel.
The CB_RECALL is using the same flavor and principal as was used
for the SETCLIENTID. That is all that the NFSv4.0 spec requires.
Remember that xprtsec= does not specify a security flavor.
> But then also callback isn't done over TLS. Should the callback be
> done over TLS (and it's a future implementation to do for
> client/server)?
The NFSv4.0 backchannel could be done over TLS, sure.
> Or is this a spec restriction/limitation?
The NFSv4.0 spec doesn't know about TLS, so it doesn't take
a position about requiring it.
Unless there's an interoperability concern, IMO standards action
isn't necessary. We can definitely say, though, that a prudent
NFSv4.0 server implementation would choose to try TLS if the
forward channel used it, and a prudent NFSv4.0 client would
require the use of TLS on the backchannel in that case.
The Linux implementation does not do that yet -- TLS would
protect both directions of operation for NFSv4.1 and above,
but for NFSv4.0, it doesn't.
--
Chuck Lever
On Wed, Jun 5, 2024 at 11:37 AM Chuck Lever III <[email protected]> wrote:
>
> Howdy -
>
> > On Jun 5, 2024, at 10:34 AM, Olga Kornievskaia <[email protected]> wrote:
> >
> > Hi Chuck,
> >
> > I noticed an interesting behaviour by the linux server. If I were to
> > mount the linux server with vers=4.0,sec=sys,xprtsec=tls, acquire a
> > delegation, and trigger a CB_RECALL, then it is done with gss
> > integrity. Why is that? I thought callback is supposed to be done with
> > the same security flavor as the forechannel.
>
> The CB_RECALL is using the same flavor and principal as was used
> for the SETCLIENTID. That is all that the NFSv4.0 spec requires.
Thanks. For some reason I thought "do state operations with krb5i was
4.1 thing and not 4.0". But I can see now that this started with the
client doing SETCLIENTID using krb5i (even though mount was sec=sys).
> Remember that xprtsec= does not specify a security flavor.
>
>
> > But then also callback isn't done over TLS. Should the callback be
> > done over TLS (and it's a future implementation to do for
> > client/server)?
>
> The NFSv4.0 backchannel could be done over TLS, sure.
>
>
> > Or is this a spec restriction/limitation?
>
> The NFSv4.0 spec doesn't know about TLS, so it doesn't take
> a position about requiring it.
>
> Unless there's an interoperability concern, IMO standards action
> isn't necessary. We can definitely say, though, that a prudent
> NFSv4.0 server implementation would choose to try TLS if the
> forward channel used it, and a prudent NFSv4.0 client would
> require the use of TLS on the backchannel in that case.
>
> The Linux implementation does not do that yet -- TLS would
> protect both directions of operation for NFSv4.1 and above,
> but for NFSv4.0, it doesn't.
Thank you for the clarification. Not sure it is worth the effort
(given we've been discussing deprecating 4.0 anyway) but it answers my
question if it's a question of implementation or spec.
>
>
> --
> Chuck Lever
>
>