Subject: Re: [kitten] [nfsv4] I-D Action: draft-ietf-nfsv4-rpcsec-gssv3-09.txt

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 5 Dec 2014 15:03:16 -0500 (EST)

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:
struct {
   [stuff, includes sequence number which is unique per transmission]
   credential
   verifier
}

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:
struct {
    sequence number
    XDR-encoded call/args/etc.
    verifier
}
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:
struct {
    credential id
    verifier
}
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
verifier).

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
authenticator).

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
offhand.

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
section 2.7.

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.

Grammar nits:

In the penultimate paragraph of section 2.7.1.1, s/the server send/the
server sends/

-Ben

---

From: "Adamson, Andy" <[email-masked]>
Date: Fri, 5 Dec 2014 22:12:28 +0000

> On Dec 5, 2014, at 3:03 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

Hello Ben

The high level proposed solution for multi-principal assertion as well as the draft-09 was posted on the nfsv4 list. Thanks for posting to kitten.

I believe the attached draft-10 addresses your review comments.

I also added a note about NFSv4.1 SSV in the Security Consideration section.

Comments in-line.

> nothing about how it is created.

I didn’t see the need to mention that, as RPCSEC_GSSv3 is a super set of RPCSEC_GSSv2 which is a super set of RPCSEC_GSSv1 which fully describes how to create an RPCSEC_GSS handle no matter what version it is.

>  That text could probably be reworked to

 I added a reference to the RPCSEC_GSSv1 section on context creation.

> specified by this document is rather strange.

I added a sentence to the first paragraph noting that this is the motivation for the new reply verifier and reworded the paragraph.

> handle unless RPCSEC_GSS_BIND_CHANNEL has been performed.  

Listing rpc_gss_svc_channel_prot as a security service for _CREATE is wrong.  Sorry I did not address this - as I look over past email, you mentioned it last review.

I removed rpc_gss_svc_channel_prot from the list, and added a separate paragraph allowing it’s use in RPCSEC_GSS_LIST.

Just a note: in RPCSEC_GSSv3 channel bindings can only exist on child v3 handles returned on a sucessful RPCSEC_GSS_CREATE with a channel binding payload. A non-child v3 handle can not have channel bindings. RPCSEC_GSS_BIND_CHANNEL is not allowed in RPCSEC_GSSv3, it is replaced by RPCSEC_GSS_CREATE channel binding assertion.

> Perhaps a full
> of the v2 channel binding procedure is self-consistent.  

I’ll go over it once again.

> I guess

That makes sense. I added some text to section 2.7.1.

> In the penultimate paragraph of section 2.7.1.1, s/the server send/the

Thanks for the review. I’ve attached an updated draft-10

—>Andy