Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review
Nico Williams <nico@cryptonector.com> Fri, 01 August 2014 05:54 UTC
Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABE51A040A; Thu, 31 Jul 2014 22:54:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVkjXmeWgMxW; Thu, 31 Jul 2014 22:54:04 -0700 (PDT)
Received: from homiemail-a72.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C36B21A0409; Thu, 31 Jul 2014 22:54:04 -0700 (PDT)
Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 92F156B0078; Thu, 31 Jul 2014 22:54:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=xkxoxGdb1wTlZ7 AlHrLzy1lovs0=; b=uOnUSxI41dUa3NryuFxvPnYIpAX8BEzxJBvlLPx4aGsHIG +5BayrjTcRI/zxwFIyyNcZ9oBv3UQBAVuC5OYopves7PspyohEGQfulhsN519kZj dCtf3osM8Bqikda/GjbbdsEzi/2gyagv+e9bWNHM9eLWgi7mQ6UWu3veuPYek=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPA id 23CA06B0070; Thu, 31 Jul 2014 22:54:04 -0700 (PDT)
Date: Fri, 01 Aug 2014 00:54:03 -0500
From: Nico Williams <nico@cryptonector.com>
To: Benjamin Kaduk <kaduk@MIT.EDU>
Message-ID: <20140801055401.GA7409@localhost>
References: <DC941FEB-725A-49E1-8C38-FF765454827C@netapp.com> <alpine.GSO.1.10.1407301239260.21571@multics.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.GSO.1.10.1407301239260.21571@multics.mit.edu>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/44XdwfhhnvdbIuMLmwXfGFPW-tA
Cc: "kitten@ietf.org" <kitten@ietf.org>, "Adamson, Andy" <William.Adamson@netapp.com>, NFSv4 <nfsv4@ietf.org>
Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Aug 2014 05:54:06 -0000
On Thu, Jul 31, 2014 at 06:38:09PM -0400, Benjamin Kaduk wrote: > Hmm, this seems to have gotten rather long. The most important part > is near the top, just after the refresher on the RPCSEC_GSS > protocol. I may reply in bite sizes :) > [...] > Three levels of protection are provided for the RPC bodies, none, > integrity, and privacy. The choice of level for this attempt at > this RPC, as well as a sequence number unique to this transmission, > are encoded into the "credential", a part of the RPC request header; > there is a GSS MIC over the header, so the header (and protection > level and sequence number) are always protected. The request > payload's encoding depends on the level; for none, it is unchanged. > [...] Though "none" always MICs the header. > Multi-principal authentication > > This draft proposes a multi-principal authentication scheme, > restricted to just the case of a privileged client process on a No, not only the case of a privileged client process. RPCSEC_GSSv3 wants to solve TWO problems: - cache poisoning attacks on the client by the user - secure conveyance of privilege information for processes running with more or even LESS privilege than the user normally would be accorded Therefore we envision that RPCSEC_GSSv3 will *always* be used to establish security contexts on any ONC RPC client where the client can avail itself of a credential distinct from the user's. > machine combining the (privileged) host's credentials with the > (unprivileged) user's credentials so as to take action on behalf of > the user. This is a similar combination to that we are using for > RXGK_AFSCombineTokens (see draft-wilkinson-afs3-rxgk-afs), Yes, it is similar to rxgk. > restricted to just a combination of host and user credentials, > specifying which one is which. I think this is the only > well-understood scenario for compount authentication at the moment, > and makes sense. What is the antecedent of "this" here? Did you mean that conveying local privilege information is not understood? > The key material from the host's GSS context are used unchanged for > securing RPCs issued with the combined identity, but the opaque > RPCSEC_GSS context handle is changed to indicate that it represents > a "child" context which has the combined identity (and possibly A new context results. > other attributes as well, not relevant for multi-principal > authentication). The creation of the child context involves sending Yes. > an authenticated RPC using the parent/host-credential context, > containing body data including a random nonce and the MIC of that > nonce using the "inner" context (i.e., the user's credentials). The > reply contains the same nonce, but the MIC in the reply is performed > using the parent/host-credentials context. The RPC to create the > child context is not permitted over a plaintext channel, and > requires either integrity protection, confidentiality+integrity > protection, or channel binding to a secure channel. Eh? No, confidentiality is neither needed nor called for for context establishment. > However, I don't think this is strong enough; I think this scheme > requires the "privacy" level of protection. Otherwise, an attacker > could replay the nonce+MIC and obtain an RPCSEC_GSS context that > will authenticate as the user from the "inner" context, without > actually proving that it possesses the user's credentials. In The client's credentials are required to make progress. That stops replay attacks. We need only bind things sufficiently to the new RPCSEC_GSS security context handle and the client credentials. Sure, if you're not using integrity protection for the payloads then an attacker can hijack RPCs, but that was always true of RPCSEC_GSSv1. > RXGK_AFSCombineTokens, we are not using (opaque) GSS credentials and > can explicitly combine the key material for a strong proof of > possession. GSS credentials are opaque, and the GSS-API does not > really provide any primitives that seem applicable here. So, I would > recommend requiring privacy protection for this call. I'll have to take a look (Andy produced the latest update and it's been a while since I've looked at RPCSEC_GSSv3), but IIRC it suffices to provide integrity protection. More tomorrow. Nico --
- [kitten] draft-ietf-nfsv4-rpcsec-gssv3: request f… Adamson, Andy
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… J. Bruce Fields
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Benjamin Kaduk
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Benjamin Kaduk
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Nico Williams
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… J. Bruce Fields
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Adamson, Andy
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Adamson, Andy
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Adamson, Andy
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Nico Williams
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Nico Williams
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Benjamin Kaduk
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Benjamin Kaduk
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Benjamin Kaduk
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Benjamin Kaduk
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Nico Williams
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Nico Williams
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Nico Williams
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… J. Bruce Fields
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Adamson, Andy
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Nico Williams
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Nico Williams
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Adamson, Andy
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Benjamin Kaduk
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Nico Williams
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Nico Williams
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Benjamin Kaduk
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Nico Williams
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Adamson, Andy
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Nico Williams
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Nico Williams
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Benjamin Kaduk
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Benjamin Kaduk
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Adamson, Andy
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Benjamin Kaduk
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Nico Williams
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Adamson, Andy
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Nico Williams
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Adamson, Andy
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Nico Williams
- [kitten] rpcsec-gssv3 multi-principal authenticat… Benjamin Kaduk
- Re: [kitten] rpcsec-gssv3 multi-principal authent… Benjamin Kaduk
- Re: [kitten] [nfsv4] rpcsec-gssv3 multi-principal… Nico Williams
- Re: [kitten] rpcsec-gssv3 multi-principal authent… Adamson, Andy
- Re: [kitten] [nfsv4] rpcsec-gssv3 multi-principal… J. Bruce Fields
- Re: [kitten] [nfsv4] rpcsec-gssv3 multi-principal… Nico Williams
- Re: [kitten] [nfsv4] rpcsec-gssv3 multi-principal… J. Bruce Fields
- Re: [kitten] [nfsv4] rpcsec-gssv3 multi-principal… Benjamin Kaduk
- Re: [kitten] [nfsv4] rpcsec-gssv3 multi-principal… Nico Williams
- Re: [kitten] [nfsv4] rpcsec-gssv3 multi-principal… J. Bruce Fields
- Re: [kitten] rpcsec-gssv3 multi-principal authent… Benjamin Kaduk
- Re: [kitten] [nfsv4] rpcsec-gssv3 multi-principal… Benjamin Kaduk
- Re: [kitten] [nfsv4] rpcsec-gssv3 multi-principal… Nico Williams
- Re: [kitten] [nfsv4] rpcsec-gssv3 multi-principal… Adamson, Andy
- Re: [kitten] [nfsv4] rpcsec-gssv3 multi-principal… Nico Williams
- Re: [kitten] [nfsv4] rpcsec-gssv3 multi-principal… Adamson, Andy
- Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv… Benjamin Kaduk