Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf-nfsv4-rpc-tls-08: (with DISCUSS and COMMENT)

[Chuck Lever <[e-mail]>]

Hi Roman -

I'll address Section 1 and 4 in this reply, and follow up with the other
Sections in subsequent replies.


> On Jul 6, 2020, at 11:24 PM, Roman Danyliw via Datatracker <[e-mail]> wrote:
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for addressing the early SECDIR review items (and thank you Derrell
> Piper and Alan Alan DeKok for doing them)
> 
> ** Section 1.  Per “Encryption by Default: Transport encryption can be enabled
> without … generating additional keying materials”, I’m not sure that this is
> accurate if the server and clients need to be keyed with certificates or PSK
> for TLS

The full list item reads:

   Encryption By Default:  Transport encryption can be enabled without
      additional administrative tasks such as identifying client systems
      to a trust authority, generating additional keying material, or
      provisioning a secure network tunnel.

All modes of RPC-on-TLS operation require a server key of some type.
The "additional keying material" in this case refers to client keys.
Section 4.2 specifies a mode of operation where RPC-over-TLS-enabled
clients can initiate a TLS session with an RPC-over-TLS-enabled server
even though the clients do not have a certificate.

This is meant to address deployment scalability issues with GSS, which
requires a keytab on every participating peer.

Perhaps instead of "identifying client systems to a trust authority,
generating additional keying material," the text could say "identifying
client systems to a trust authority and providing them with keying
material,".


> ** Section 4.1. Per “Policy settings on the RPC-over-TLS-enabled peer determine
> whether RPC operation continues without the use of TLS or RPC operation is not
> permitted.”, I had trouble parsing this sentence.

A previous IESG COMMENT prompted a rewrite of this sentence since -08.

The first paragraph of Section 4.1 now reads:

   The mechanism described in the current document interoperates fully
   with RPC implementations that do not support RPC-over-TLS.  When an
   RPC-over-TLS-enabled peer encounters a peer that does not support
   RPC-over-TLS, policy settings on the RPC-over-TLS-enabled peer
   determine whether RPC operation continues without the use of TLS, or
   RPC operation is not permitted.


> ** Section 4.1.  Per “RPC operation can continue …”, it might be worth
> repeating what was stated earlier that  “[t]he RPC operation can continue if
> permitted by local policy …”

How about:

OLD:

   Conversely, if the Reply's reply_stat is not MSG_ACCEPTED, if its
   verifier flavor is not AUTH_NONE, or if its verifier does not contain
   the "STARTTLS" token, the RPC client MUST NOT send a "ClientHello"
   message.  RPC operation can continue, however it will be without any
   confidentiality, integrity or authentication protection from (D)TLS.

NEW:

   Conversely, if the Reply's reply_stat is not MSG_ACCEPTED, if its
   verifier flavor is not AUTH_NONE, or if its verifier does not contain
   the "STARTTLS" token, the RPC client MUST NOT send a "ClientHello"
   message.  RPC operation may continue, depending on local policy, but
   without confidentiality, integrity, or peer authentication protection
   from (D)TLS.

[ ... snipped ... ]

> ** Editorial Nits:
> -- Section 5.  Typo. s/Similary/Similarly/
> 
> -- Section 7.1.2. Typo. s/connnection/connection/

Fixed, thanks.


--
Chuck Lever