Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt

> I've been studying RFC 8471 to understand what would be needed to support
> TLS token binding with RPC. It appears there are two components:

 > - The TLS handshake is extended to indicate support for token binding
>   and negotiate the supported version

>  - The upper layer protocol (RPC, in our case) is required to send a Token
>   Binding message as the first message

> We would need to provide a mechanism for encapsulating this message in
> the RPC protocol similar to what RFC 8473 does for HTTPS. Potentially,
> RPCSEC GSS could provide a mechanism for transporting this message.

As I understand things, one of the potential goals here is to satisfactorily
authenticate the client so that AUTH_SYS can reasonably used.  For that use
case, I'm not sure how depending on RPCSEC GSS would fit in.

> It appears to me that there is a natural boundary between what we have
> already described in draft-cel-nfsv4-rpc-tls and support for TLS Token
> Binding, such that Token Binding could be handled by a separate document.

That makes sense.

> That would allow the quick completion

Since this is the IETF, let's just say "quicker completion".

> of rpc-tls to enable encryption by
> default using self-signed certificates, with support for Token Binding
> to appear later.

It depens on how much later.  I don't see how it would be necessary to get
through the RFC process, including that rigorous search for split
infinitives, cycles
of discussion of RFC2119 terms before starting the follow-up work on token
binding.   Once rpc-tls is accepted as a working group document, the group
would
be in a position to make plans for the follow-on  work that seems to be
warranted.

> Thoughts, comments...

If work on client autehentication is to be punted, then the document will
need to reflect that.
In particular, if you, as a server, are prepared to accept an
unauthenticatted client's user
identifications, then your security is pretty much non-existent, despite
the fact that
enryption prevents eavesdropping.  In that case, it probably best to say
nothing about use
of AUTH_SYS.

> Am I on the wrong track?

No.

On Fri, Jan 4, 2019 at 10:53 AM Chuck Lever <chuck.lever@oracle.com> wrote:

>
> > On Nov 19, 2018, at 5:33 PM, McDonald, Alex <alexmc@netapp.com> wrote:
> >
> > Hi Chuck
> >
> > Apologies for top posting, blame MS
> >
> > I was interested in the comment "We believe the combination of host
> authentication via TLS and user authentication via RPC provides optimal
> security, efficiency, and flexibility,". There's been a huge amount of
> negative press for TLS client auth, but there's been a push for TLS token
> binding as a basis for better client/server authentication. Does the
> proposal need to consider work in this area?
>
> I've been studying RFC 8471 to understand what would be needed to support
> TLS token binding with RPC. It appears there are two components:
>
>  - The TLS handshake is extended to indicate support for token binding
>    and negotiate the supported version
>
>  - The upper layer protocol (RPC, in our case) is required to send a Token
>    Binding message as the first message
>
> We would need to provide a mechanism for encapsulating this message in
> the RPC protocol similar to what RFC 8473 does for HTTPS. Potentially,
> RPCSEC GSS could provide a mechanism for transporting this message.
>
> It appears to me that there is a natural boundary between what we have
> already described in draft-cel-nfsv4-rpc-tls and support for TLS Token
> Binding, such that Token Binding could be handled by a separate document.
> That would allow the quick completion of rpc-tls to enable encryption by
> default using self-signed certificates, with support for Token Binding
> to appear later.
>
> Thoughts, comments... Am I on the wrong track?
>
>
> > -----Original Message-----
> > From: nfsv4 <nfsv4-bounces@ietf.org> On Behalf Of Chuck Lever
> > Sent: Monday, November 19, 2018 15:56
> > To: NFSv4 <nfsv4@ietf.org>
> > Subject: [nfsv4] Fwd: New Version Notification for
> draft-cel-nfsv4-rpc-tls-01.txt
> >
> >
> > Hi-
> >
> >> Begin forwarded message:
> >>
> >> From: internet-drafts@ietf.org
> >> Subject: New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt
> >> Date: November 19, 2018 at 10:52:07 AM EST
> >> To: "Trond Myklebust" <trond.myklebust@hammerspace.com>, "Charles
> >> Lever" <chuck.lever@oracle.com>, "Chuck Lever"
> >> <chuck.lever@oracle.com>
> >>
> >>
> >> A new version of I-D, draft-cel-nfsv4-rpc-tls-01.txt has been
> >> successfully submitted by Charles Lever and posted to the IETF
> >> repository.
> >>
> >> Name:         draft-cel-nfsv4-rpc-tls
> >> Revision:     01
> >> Title:                Remote Procedure Call Encryption By Default
> >> Document date:        2018-11-19
> >> Group:                Individual Submission
> >> Pages:                9
> >> URL:
> https://www.ietf.org/internet-drafts/draft-cel-nfsv4-rpc-tls-01.txt
> >> Status:
> https://datatracker.ietf.org/doc/draft-cel-nfsv4-rpc-tls/
> >> Htmlized:       https://tools.ietf.org/html/draft-cel-nfsv4-rpc-tls-01
> >> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-cel-nfsv4-rpc-tls
> >> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-cel-nfsv4-rpc-tls-01
> >>
> >> Abstract:
> >>  This document describes a mechanism that enables encryption of in-
> >>  transit Remote Procedure Call (RPC) transactions with little
> >>  administrative overhead and full interoperation with RPC
> >>  implementations that do not support this mechanism.  This document
> >>  updates RFC 5531.
> >>
> >>
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of
> >> submission until the htmlized version and diff are available at
> tools.ietf.org.
> >>
> >> The IETF Secretariat
> >
> > Minor changes in revision 01:
> > - Correct a legal issue reported by idnits
> > - Clarify terminology throughout document
> > - Add editor's note in Section 4.3 "Authentication"
> > - Wordsmithing throughout
> >
> >
> > The immediate question I have is whether members of WG feel this topic
> and document are important enough to promote rpc-tls-01 to Working Group
> document status. If yes, I can submit the next revision as
> draft-ietf-nfsv4-rpc-tls-00.
>
> --
> Chuck Lever
>
>
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>