Return-Path: X-Original-To: nfsv4@ietfa.amsl.com Delivered-To: nfsv4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8036D3A0BE9; Mon, 29 Jun 2020 11:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 v7T8J0zROmzo; Mon, 29 Jun 2020 11:35:40 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BFFD3A0BDE; Mon, 29 Jun 2020 11:35:40 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id x9so15419437ila.3; Mon, 29 Jun 2020 11:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HozEFX0/ZGAqbKEqs+Bp73zRH1jNi2KKWxBy/+dBKbY=; b=BGqiZugdc6eRN4/4xksWTLCKPa+Wqy+vp6L42Pz6AkWROeKuR2tfTcgNz//uPTiGbt kdFeWt96yieCU41b6mNIy2fd6UBcI+pib2TqOvlWTCLcYlk0mqcH85+jtlp6CtUwhW0T tjnz/fNvEan6NmNXb0fLXCCZ7IpoZw3d6R6Z4ECjcdUR9tB5M5FRPcLq1zdRib1Vv2PU 1Cmgh5U9EhjEbGeyiQV1uwP7PFVvjIX0yhIeTyxRukjhfkkU9GQYcgbp0o+0B/E283Wh fOQ9Mhp7cvWJ9mmP/ixfxXfO5qbeXx/oES1Deggupx3qwJlWEbji16UD4gQPe/IZv/i1 A3vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HozEFX0/ZGAqbKEqs+Bp73zRH1jNi2KKWxBy/+dBKbY=; b=gna9c3Au3HydDtybL6sNNElZl6zb9SeoSw8OP1zcD0m63Gyxc5SsfI0EQ06zw/7Adj wrWNdlwVkHr4/iKkcxKsEcjpdLxz4+17aRPyPwm6EircaLWYkYOZS6BhJDpy5Fsaj6iP h0yjQBJ/GlplQC3B10bn+3gvn478Bsall50YsDscWV+WHKhPC9alJD5tGjIf/8SxafxQ PDJP2XT56bIxGn9dPfopA5qThWHtNZP9QhToA/y/8yEevKauEXEOPdGZTQ6x2PFno24C kv8Aap4lD+3LbNOgQYhtUtcVyPy1xpUVgpluLJDT7ojPLS2wEhfPWX8qgqh4uWLaNLIq wq8w== X-Gm-Message-State: AOAM531OgmJaPUifv55g3M9NiuQRaoZ+kREe5720GZD5NEUZZr8P0uTt MU5E7mRkPI+UN9MrVMxwI095tjmN/aHLnjJVfxY= X-Google-Smtp-Source: ABdhPJzhbPXMnhdEb6Q7690P6XKNnXmPT1TfhDXQrNaPEJ4koFZjy/6VidAmUY4aVCG0tAp4wzswBGvYHZBczBHKuD0= X-Received: by 2002:a92:91d2:: with SMTP id e79mr17492082ill.237.1593455739641; Mon, 29 Jun 2020 11:35:39 -0700 (PDT) MIME-Version: 1.0 References: <159311856977.23665.6882641799899154823@ietfa.amsl.com> <797483BA-93B2-45AC-B2BC-044E905F40C9@oracle.com> In-Reply-To: <797483BA-93B2-45AC-B2BC-044E905F40C9@oracle.com> From: Martin Duke Date: Mon, 29 Jun 2020 11:35:28 -0700 Message-ID: To: Chuck Lever Cc: The IESG , draft-ietf-nfsv4-rpc-tls@ietf.org, nfsv4-chairs@ietf.org, nfsv4@ietf.org, David Noveck Content-Type: multipart/alternative; boundary="00000000000053a96b05a93d53e6" Archived-At: Subject: Re: [nfsv4] Martin Duke's Discuss on draft-ietf-nfsv4-rpc-tls-08: (with DISCUSS and COMMENT) X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 18:35:43 -0000 --00000000000053a96b05a93d53e6 Content-Type: text/plain; charset="UTF-8" All of these changes are satisfactory, thanks. On the issue of Sec 4.2: I am not knowledgeable about this, but how about: OLD: In either of these modes, RPC user authentication is not affected by the use of transport layer security. When a client presents a TLS peer identity to an RPC server, the protocol extension described in the current document provides no way for the server to know whether that identity represents one RPC user on that client, or is shared amongst many RPC users. Therefore, a server implementation must not utilize the remote TLS peer identity for RPC user authentication. NEW: In either of these modes, RPC user authentication is not affected by the use of transport layer security. When a client presents a TLS peer identity to an RPC server, the protocol extension described in the current document provides no way for the server to know whether that identity represents one RPC user on that client, or is shared amongst many RPC users. Therefore, a server that wishes to authenti On Sat, Jun 27, 2020 at 10:29 AM Chuck Lever wrote: > Hi Martin- > > Thank you for your comments. > > > > On Jun 25, 2020, at 4:56 PM, Martin Duke via Datatracker < > noreply@ietf.org> wrote: > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > This presumably a trivial fix but I think it's important enough to be a > DISCUSS: > > > > I think the document needs some discussion of the security properties of > TLS1.3 > > early data over TCP, if only to refer to Section 8 of RFC 8446 (replay) > and > > mention that it is not forward-secure, unlike the rest of the payload. > > We could extend the first paragraph of Section 7, as follows: > > OLD: > > 7. Security Considerations > > One purpose of the mechanism described in the current document is to > protect RPC-based applications against threats to the confidentiality > of RPC transactions and RPC user identities. A taxonomy of these > threats appears in Section 5 of [RFC6973]. Also, Section 6 of > [RFC7525] contains a detailed discussion of technologies used in > conjunction with TLS. Implementers should familiarize themselves > with these materials. > > NEW: > > 7. Security Considerations > > One purpose of the mechanism described in the current document is to > protect RPC-based applications against threats to the confidentiality > of RPC transactions and RPC user identities. A taxonomy of these > threats appears in Section 5 of [RFC6973]. Also, Section 6 of > [RFC7525] contains a detailed discussion of technologies used in > conjunction with TLS. Implementers should familiarize themselves > with these materials. > > Once a TLS session is established, the RPC payload carried on TLSv1.3 > is forward-secure. However, implementers need to be aware that replay > attacks can occur during session establishment. Remedies for such > attacks are discussed in detail in Section 8 of [RFC 8446]. > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thank you for this draft. I fully support bringing TLS into more use > cases of > > this type. > > > > Some comments: > > Sec 1. > > "Moreover, the use of AUTH_SYS remains common despite the adverse > effects that > > acceptance of UIDs and GIDs from unauthenticated clients brings with it. > > Continued use is in part because: > > > > Per-client deployment and administrative costs are not scalable. > Administrators > > must provide keying material for each RPC client, including transient > clients. > > Host identity management and user identity management must be enforced > in the > > same security realm. In certain environments, different authorities > might be > > responsible for provisioning client systems versus provisioning new > users." > > > > The text above says that something is still in use because..., and then > > mentions two things that are bad. I think the two items are supposed to > refer > > to GSS? > > Indeed, they do. > > NEW: > > Moreover, the use of AUTH_SYS remains common despite the adverse > effects that acceptance of UIDs and GIDs from unauthenticated clients > brings with it. Continued use is in part because: > > * Per-client GSS deployment and administrative costs are not > scalable. Administrators must provide keying material for each > RPC client, including transient clients. > > * GSS host identity management and user identity management must be > enforced in the same security realm. In certain environments, > different authorities might be responsible for provisioning client > systems versus provisioning new users. > > > > Sec 4.2 This sure looks like normative text, so s/must not/MUST NOT "... > > utilize the remote TLS peer identity for RPC user authentication" > > This paragraph formerly had MUST NOT, but was rewritten to address this > issue: > > https://github.com/chucklever/i-d-rpc-tls/issues/5 > > There was a concern that the existing statement was not specific enough to > make > it a compliance requirement. In particular, some implementations do want > to use > the peer identity for access control decisions, though not on a per-user > basis. > > I'm open to some change here, but I'd like to hear suggestions about > wording > to make the new compliance statement more actionable. > > > > Sec 5.1.2 Similarly, s/should/SHOULD "...employ ConnectionIDs of at > least 4 > > bytes in length." > > No objection to using SHOULD. > > > -- > Chuck Lever > > > > --00000000000053a96b05a93d53e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All of these changes are satisfactory, thanks.

On the issue of=C2=A0 Sec 4.2:
I am not knowledgeable abo= ut this, but how about:
OLD:
   In either of these modes, RPC user authentica=
tion is not affected by
   the use of transport layer security.  When a client presents a TLS
   peer identity to an RPC server, the protocol extension described in
   the current document provides no way for the server to know whether
   that identity represents one RPC user on that client, or is shared
   amongst many RPC users.  Therefore, a server implementation must not
   utilize the remote TLS peer identity for RPC user authentication.

NEW:
   In either of these modes, RPC user a=
uthentication is not affected by
   the use of transport layer security.  When a client presents a TLS
   peer identity to an RPC server, the protocol extension described in
   the current document provides no way for the server to know whether
   that identity represents one RPC user on that client, or is shared
   amongst many RPC users.  Therefore, a server that wishes to authenti


On Sat, Jun 27, 2= 020 at 10:29 AM Chuck Lever <c= huck.lever@oracle.com> wrote:
Hi Martin-

Thank you for your comments.


> On Jun 25, 2020, at 4:56 PM, Martin Duke via Datatracker <noreply@ietf.org> wro= te:
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> This presumably a trivial fix but I think it's important enough to= be a DISCUSS:
>
> I think the document needs some discussion of the security properties = of TLS1.3
> early data over TCP, if only to refer to Section 8 of RFC 8446 (replay= ) and
> mention that it is not forward-secure, unlike the rest of the payload.=

We could extend the first paragraph of Section 7, as follows:

OLD:

7.=C2=A0 Security Considerations

=C2=A0 =C2=A0One purpose of the mechanism described in the current document= is to
=C2=A0 =C2=A0protect RPC-based applications against threats to the confiden= tiality
=C2=A0 =C2=A0of RPC transactions and RPC user identities.=C2=A0 A taxonomy = of these
=C2=A0 =C2=A0threats appears in Section 5 of [RFC6973].=C2=A0 Also, Section= 6 of
=C2=A0 =C2=A0[RFC7525] contains a detailed discussion of technologies used = in
=C2=A0 =C2=A0conjunction with TLS.=C2=A0 Implementers should familiarize th= emselves
=C2=A0 =C2=A0with these materials.

NEW:

7.=C2=A0 Security Considerations

=C2=A0 =C2=A0One purpose of the mechanism described in the current document= is to
=C2=A0 =C2=A0protect RPC-based applications against threats to the confiden= tiality
=C2=A0 =C2=A0of RPC transactions and RPC user identities.=C2=A0 A taxonomy = of these
=C2=A0 =C2=A0threats appears in Section 5 of [RFC6973].=C2=A0 Also, Section= 6 of
=C2=A0 =C2=A0[RFC7525] contains a detailed discussion of technologies used = in
=C2=A0 =C2=A0conjunction with TLS.=C2=A0 Implementers should familiarize th= emselves
=C2=A0 =C2=A0with these materials.

=C2=A0 =C2=A0Once a TLS session is established, the RPC payload carried on = TLSv1.3
=C2=A0 =C2=A0is forward-secure. However, implementers need to be aware that= replay
=C2=A0 =C2=A0attacks can occur during session establishment. Remedies for s= uch
=C2=A0 =C2=A0attacks are discussed in detail in Section 8 of [RFC 8446].

> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> Thank you for this draft. I fully support bringing TLS into more use c= ases of
> this type.
>
> Some comments:
> Sec 1.
> "Moreover, the use of AUTH_SYS remains common despite the adverse= effects that
> acceptance of UIDs and GIDs from unauthenticated clients brings with i= t.
> Continued use is in part because:
>
> Per-client deployment and administrative costs are not scalable. Admin= istrators
> must provide keying material for each RPC client, including transient = clients.
> Host identity management and user identity management must be enforced= in the
> same security realm. In certain environments, different authorities mi= ght be
> responsible for provisioning client systems versus provisioning new us= ers."
>
> The text above says that something is still in use because..., and the= n
> mentions two things that are bad. I think the two items are supposed t= o refer
> to GSS?

Indeed, they do.

NEW:

=C2=A0 =C2=A0Moreover, the use of AUTH_SYS remains common despite the adver= se
=C2=A0 =C2=A0effects that acceptance of UIDs and GIDs from unauthenticated = clients
=C2=A0 =C2=A0brings with it.=C2=A0 Continued use is in part because:

=C2=A0 =C2=A0*=C2=A0 Per-client GSS deployment and administrative costs are= not
=C2=A0 =C2=A0 =C2=A0 scalable.=C2=A0 Administrators must provide keying mat= erial for each
=C2=A0 =C2=A0 =C2=A0 RPC client, including transient clients.

=C2=A0 =C2=A0*=C2=A0 GSS host identity management and user identity managem= ent must be
=C2=A0 =C2=A0 =C2=A0 enforced in the same security realm.=C2=A0 In certain = environments,
=C2=A0 =C2=A0 =C2=A0 different authorities might be responsible for provisi= oning client
=C2=A0 =C2=A0 =C2=A0 systems versus provisioning new users.


> Sec 4.2 This sure looks like normative text, so s/must not/MUST NOT &q= uot;...
> utilize the remote TLS peer identity for RPC user authentication"=

This paragraph formerly had MUST NOT, but was rewritten to address this iss= ue:

=C2=A0 https://github.com/chucklever/i-d-rpc-tls= /issues/5

There was a concern that the existing statement was not specific enough to = make
it a compliance requirement. In particular, some implementations do want to= use
the peer identity for access control decisions, though not on a per-user ba= sis.

I'm open to some change here, but I'd like to hear suggestions abou= t wording
to make the new compliance statement more actionable.


> Sec 5.1.2 Similarly, s/should/SHOULD "...employ ConnectionIDs of = at least 4
> bytes in length."

No objection to using SHOULD.


--
Chuck Lever



--00000000000053a96b05a93d53e6--