[secdir] RPCSEC_GSS analysis (was Re: [nfsv4] SECDIR Review of draft-ietf-nfsv4-umask-03)

[Nico Williams <[e-mail]>]

>                                                    [...].  A more
> complete analysis of RPCSEC_GSS should really not be done in the context
> of this I-D.

So here is that thread.

ONC RPC is... an RPC protocol.  Requests have a 32-bit (small) XID that
responses repeat.  The XID allows responses to be sent out of order, and
resembles what HTTP/2 calls channels (or whatever).

Each RPC request or response message has a header which carries said XID
and other metadata, including a field for security that RPCSEC_GSS uses
to a) identify a "security context" (explained earlier) and b) include a
MIC of metadata.  A "MIC" is a lot like a MAC, with some additional
metadata.

Each RPC request or response message also contains a payload.  The
payload is either MIC'ed (to provide only integrity protection) or
"wrapped" (to also provide integrity protection.

"MIC" and "wrap" are GSS [RFC2743] terminology.  GSS is an API and a
small amount of protocol for authenticating peers to each other.

GSS has an "initiator" (the client in the NFS case) and an "acceptor"
(the server in the NFS case).  At first the initiator and acceptor
engage in an exchange of "security context tokens" (messages) until
"security context" establishment succeeds or fail.

An established security context basically has session keys that can be
used to make/verify MICs (again, MAC-like messages), or wrap/unwrap
"wrap tokens".  Wrapping can provide either integrity protection, or
both integrity and confidentiality protection.

MIC and wrap tokens can carry things like timestamps or sequence numbers
in them that can be used to deal with out of sequence delivery and
detect replays.

All of the metadata in RPC headers goes in the clear unless the TCP
connection is further protected by IPsec or TLS or SSHv2 or whatever.
People have run NFSv4 over all of those, but there is no standard for
doing so over TLS or SSHv2 -- there is no "upgrade to TLS" feature in
NFSv4 (unless it's been added recently and I missed it).

The binding between header and payload is done, IIRC, by including the
payload MIC or wrap token in the input to the header MIC token input,
but I may be misremembering.  You can go check RFC2205 to double-check.

Wrap tokens nowadays can do "AEAD" style "encrypt some plaintext and
authenticate it and additional data", which would benefit RPCSEC_GSS.
But even so, the most efficient thing we can do is implement RFC5660 and
run NFSv4 with channel binding to IPsec.

Nico
--