Re: I-D Action: draft-ietf-nfsv4-rpcsec-gssv3-09.txt
Benjamin Kaduk <kaduk <at> MIT.EDU>
2014-12-05 20:03:16 GMT
Adding nfsv4 to receive the extra feedback, and kitten since I don't think
the proposed solution for multi-principal assertion in the new draft was
posted there yet.
On Tue, 2 Dec 2014, Andy Adamson wrote:
> Any comments on the multi-principal assertion changes? I think I
> handled it correctly - replacing the nonce/MIC of nonce with MIC of
> RPC header including credential using the inner context for both args
> and reply.
I'll briefly summarize the proposal for the kitten folks (and to verify
that I'm reading it correctly). I will play very fast-and-loose with the
XDR and field names, for concision.
To recall, the RPCSEC_GSS traffic involves the generic RPC header followed
by the RPC body.
The header is:
[stuff, includes sequence number which is unique per transmission]
Where the verifier is basically a GSS MIC over the header up to and
including the credential. This verifier is always a GSS MIC regardless of
the protection of the RPC body (none, integrity, or privacy).
For integrity-protected RPCs (which are mostly what we care about here,
since with confidentiality protection an attacker can't grab the inner
verifier), the RPC body is:
where the verifier is a GSS MIC over the sequence number and the XDR blob.
For RPCSEC_GSS_CREATE, party of the "XDR-encoded call/args/etc" is
supposed to be the GSS inner context handle and verifier, which identify
the user part of the multi-principal authentication. The version in the
-08 was just a context handle, nonce, and mic over the nonce, which could
be read by an attacker and replayed in an attacker-controlled parent
connection. The new proposal is to have this role played by:
where the verifier is now a GSS MIC over the current RPC header, up to and
including the credential (i.e., the same content as the RPC header's
Since this structure is included in the RPC call body, it will be included
in the MIC over the body as part of the RPC integrity protection (this is
not really relevant for preventing an attacker from replaying the inner
I think that the current proposal (-09) has acceptable security
properties, since the inner verifier is tied to the outer context handle.
Potentially an attacker could replay or MITM a call, but would not be able
to use the resulting child context handle, since it is tied to the actual
outer context's GSS security context.
That said, I don't think there is any reason to exclude the RPC header
verifier field from the GSS MIC with the inner handle, since the RPC
header can be fully constructed by that point, and it might end up
providing slightly tighter binding of the inner handle to the outer RPC.
It also might be worth thinking about including the inner context handle
id in the MIC, but it is probably not necessary.
[kitten folks can probably stop reading here]
> We need to goto WGLC, so I'm putting out one more draft. I have some
> miscellaneous fixes - including your flattening of rigs_assertion.
Another miscellaneous fix:
Section 2 reads rather strangely, with the first bullet point just
assuming that there is an existing RPCSEC_GSSv3 context handle and saying
nothing about how it is created. That text could probably be reworked to
be more clear and accurate, thought I don't have any concrete suggestions
Section 2.3 also reads a bit oddly, with the first paragraph describing a
situation that would have occurred if the MITM problem was not addressed,
and the second paragraph describing the fix. Having the first paragraph
read as if the MITM vulnerability is still present in the protocol
specified by this document is rather strange.
Section 2.5 says that RPCSEC_GSS_BIND_CHANNEL MUST NOT be used on a v3
handle, but section 2.7 still lists rpc_gss_svc_channel_prot as an
acceptable security service for protecting the _CREATE and _LIST control
messages -- rpc_gss_svc_channel_prot cannot be used on a non-child v3
handle unless RPCSEC_GSS_BIND_CHANNEL has been performed. Perhaps a full
review of the document should be made to ensure that all of the coverage
of the v2 channel binding procedure is self-consistent. I guess
rpc_gss_svc_channel_prot could make sense for _LIST, but I don't think it
works for _CREATE, so perhaps that should be noted in the bullet item in
There is probably something to be said about the ordering of entries in
rcr_assertions (with respect to rca_assertions' order). If I'm reading
correctly (I skimmed that part a bit) the server returns in rcr_assertions
exactly the subset of rca_assertions which was accepted by the server's
processing. The client may want to verify which of its assertions were
accepted, and requiring the server to return things in the same order
would facilitate implementation efficiency in the client.
In the penultimate paragraph of section 184.108.40.206, s/the server send/the
nfsv4 mailing list
nfsv4 <at> ietf.org