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

[Chuck Lever <[e-mail]>]

Hi Ben-

I'm nearly done with the new text. I need some clarification below.


> On Jul 8, 2020, at 2:56 AM, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-nfsv4-rpc-tls-08: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpc-tls/
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I'm surprised that we don't make a normative reference to BCP 195's
> "Recommendations for Secure Use of Transport Layer Security (TLS) and
> Datagram Transport Layer Security (DTLS)" (we have only an informative
> reference from the security considerations).

Is there a specific change you'd like to see?


>   *  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.
> 
> I think this is only true from a certain point of view.  They have to be
> related, and (assuming Kerberos since non-Kerberos RPCSEC_GSS isn't really a
> thing) a cross-realm relationship would have to exist in at least one
> direction when client system and user provisioning are managed by separate
> kerberos realms, but the authorities in question do not need to be exactly
> the same.

I'm not clear what needs to change.


>   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.
> 
> To clarify Roman's comment, it seems worth specifying that this is without
> additional *per-client* keying material.  Generating per-server keying
> material is clearly a minimum requirement.

The text was updated at Roman's request. It now reads:

   Encryption By Default:  Transport encryption can be enabled without
      additional administrative tasks such as identifying client systems
      to a trust authority and providing each with keying material.

Can you confirm this adequately addresses your comment?


> Section 4.1
> 
>   The mechanism described in the current document interoperates fully
>   with RPC implementations that do not support RPC-over-TLS.  Policy
>   settings on the RPC-over-TLS-enabled peer determine whether RPC
> 
> I'd consider joining the two sentences via ", subject to policy settings on
> the RPC-over-TLS-enabled peer that determine".

The text was updated at some point during IESG review. It 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.

Can you confirm this is adequate?


>   As soon as a client initializes a UDP socket for use with an RPC
>   server, it uses the mechanism described in Section 4.1 to discover
>   DTLS support for an RPC program on a particular port.  It then
>   negotiates a DTLS session.
> 
> We could probably normalize the wording between the TCP and UDP cases (e.g.,
> TCP says "typically, once a client completes the TCP handshake, it uses the
> mechanism [...]" but this uses descriptive text).  That would also let us
> decide whether or not to mention that (D)TLS usage is contingent on mutual
> support for STARTTLS.

The reason the TCP and UDP text diverge is because TCP is connection
oriented and UDP is not. The current UDP text is the result of some
earlier review comments in this area. Let me know if there is a
specific change you'd like to see here.

Also, I don't understand the last sentence of your comment. Can you
elucidate?


> Section 8.1
> 
> Isn't it codepoint squatting to claim auth flavor 7 before IANA has
> allocated it?  (This is usually a Discuss-level issue, but that part is too
> long already so I left it here.)

I agree it is slightly improper, but the authors were not aware of
IANA's authority over RPC authentication flavors until late in the
document's life cycle. It was a good faith oversight.

I believe we have IANA's permission at this point to use the value 7.

Is there a text change needed here?


--
Chuck Lever