Re: [nfsv4] NFSv4 on TLS

[Trond Myklebust <[e-mail]>]

On Tue, 16 Oct 2018 at 17:03, Trond Myklebust <[e-mail]> wrote:

>
>
> On Tue, 16 Oct 2018 at 16:02, Benjamin Kaduk <[e-mail]> wrote:
>
>> I'm not really in a position to speak of the level of demand for such a
>> proposal, but...
>>
>> On Tue, Oct 16, 2018 at 03:53:32PM -0400, Trond Myklebust wrote:
>> > So here is a quick proposal: we add a new security type AUTH_TLS, which
>> can
>> > act as the equivalent of a "STARTTLS command" to signal that we want to
>> > initiate TLS security negotiation if the server supports it.
>> >
>> > When the client has set up the TCP connection, and is ready to initiate
>> the
>> > TLS negotiation, it pings the server with a NULL RPC request with an
>> > auth_flavor of AUTH_TLS. If the server doesn't recognise that flavour,
>> and
>> > returns AUTH_ERROR (+AUTH_BADCRED?), then the client knows that the
>> server
>> > is unlikely to support stepping up to TLS on this connection.
>> >
>> > There should be no need for the credential to carry any form of
>> > authentication payload, so just model it on AUTH_NONE, but have the
>> server
>> > return a payload of "STARTTLS" in the body of the verifier. That
>> > differentiates it from AUTH_NONE, and allows the client to distinguish
>> > servers that recognise AUTH_TLS, and servers that just ignore the
>> > authentication header altogether in NULL RPC calls. If the payload
>> matches,
>> > then the client kicks off TLS negotiation before sending any further RPC
>> > calls on this connection.
>> >
>> > If the client tries to use AUTH_TLS for anything other than a NULL RPC
>> > ping, then a server would presumably be expected to return AUTH_ERROR
>> with
>> > AUTH_TOOWEAK.
>> >
>> > Once the TLS negotiation is complete, then the client and server will
>> have
>> > established a secure channel for communicating, and can then use the
>>
>> Any such document would need to discuss the client authentication
>> semantics
>> for the TLS connection, whether a single per-host client cert is used vs.
>> per-user certs, etc.  BCP 195/RFC 7525 would of course play a role, too.
>>
>
> This is transport level security, so in order to have per-user certs, we'd
> presumably have to have a TCP connection per user? That is certainly not
> something that I can envision wanting to ever implement for a kernel NFS
> client.
> IOW: As far as this working group is concerned, I'd see TLS as mainly
> practical for providing machine level authentication, not user level.
>
>
I should note, OTOH, that using TLS for machine authentication, and being
able to use certificate information in my /etc/exports file would be highly
useful!


> I agree that there are issues addressed by RFC7525 that we may want to
> discuss.
>
>
>>
>> > standard security flavours on top of that channel (presumably after
>> > negotiating down the irrelevant RPCSEC_GSS privacy and integrity
>> mechanisms
>> > and applying channel binding).
>>
>> Anyone considering GSSAPI channel binding should probably consider the
>> issues that
>> https://tools.ietf.org/html/draft-ietf-kitten-channel-bound-flag-03 tries
>> to address, and also that the tls-unique-based binding value in RFC 5929
>> is
>> rather overtaken by events.  There would probably be a need to define a
>> new
>> TLS exporter-based value that requires the use of TLS 1.3 or
>> extended-master-secret.
>>
>>
> Is that discussion relevant to the NFSv4 working group though? NFSv4 only
> requires servers to support RPCSEC_GSSv2 (or RPCSEC_GSSv3 for NFSv4.2).
> Both those protocols have explicit channel binding RPC calls that return
> success/failure, and a separate service type (rpc_gss_svc_channel_prot)
> that as far as I can tell should meet the requirements in the above
> document. Am I wrong?
>
>
>
> -Ben
>>
>> > Is this a proposal that might be of interest to members of this group,
>> and
>> > hence be worth documenting in an RFC?
>> >
>> > Cheers
>> >   Trond
>> >
>> > On Tue, 28 Aug 2018 at 07:57, Rick Macklem <[e-mail]>
>> wrote:
>> >
>> > > David Noveck wrote:
>> > > [stuff snipped]
>> > > >> AUTH_SYS with UIDs/GIDs is too limited.
>> > > >
>> > > >As far as I know, AUTH_SYS includes 32-bit UIDs/GIDs.   Those seemed
>> > > ample when
>> > > >AUTH_SYS was designed.
>> > > >
>> > > >It certainly is too limited now, but it is difficult to change. Even
>> more
>> > > of a
>> > > >barrier than the existiing OTW formats, is the fact that most flle
>> systems
>> > > >used with NFS reserve 32 bits in the inode for each of owner and
>> group.
>> > > >Further complicating matters is that in-kernel VFS's and POSIX API's
>> are
>> > > >built around this very limited approach to user identity.
>> > > >
>> > > >> I have no objection to a mechanism like AUTH_SYS-over-TLS
>> > > >
>> > > >I don't know of any AUTH_SYS mechanism that uses anything other than
>> > > >32-bit ids.
>> > > >
>> > > >> that uses name@domain to be consistent with the rest of NFSv4.
>> > > I think he was referring to a new authentication flavour that had the
>> > > "user@domain" string as the authenticator. (There is a 400byte
>> limit, but
>> > > that might be sufficient.) I might have called it AUTH_NAME or
>> AUTH_OWNER.
>> > >
>> > > I'd guess that 99.9% of FreeBSD NFS usage is AUTH_SYS, although
>> Kerberos is
>> > > in the system. I do think a way to use TLS (or similar) to encrypt at
>> the
>> > > transport
>> > > level would be a good thing and would get used more widely.
>> > >
>> > > Many of the FreeBSD sites (I won't guess the %) use AUTH_SYS but
>> ignore the
>> > > gid list and generate a gid list on the server from the uid. As such,
>> I
>> > > don't think
>> > > putting gids/owner_group names in a new authentication mechanism is
>> needed.
>> > >
>> > > For folks that have a 32bit uniform uid space, AUTH_SYS in transport
>> > > encryption
>> > > seems ok to me.
>> > > For sites where the uid space isn't uniform or doesn't fit in 32bits,
>> a
>> > > "user@domaim"
>> > > to uid/gid list mapping in the server can be done using this new one.
>> > >
>> > > >Within NFSv4 proper, you could use name@domain, but there is really
>> no
>> > > >point if you are using AUTH_SYS.    You are allowed to use numeric
>> ids
>> > > >as attributes and most people using AUTH_SYS choose to do so, to
>> avoid
>> > > >the overhead of a translation that provides no benefits.
>> > > They could use this mapping with AUTH_OWNER when AUTH_SYS won't
>> > > work for them.
>> > >
>> > > rick
>> > > ps: I, for one, am not interested in implementing a new GSSAPI
>> mechanism
>> > > that
>> > >       isn't in the open source Kerberos distros. As such, any
>> complicated
>> > > setup
>> > >       involving writing of a lot of new code probably wouldn't make
>> it in
>> > > FreeBSD
>> > >       for a long time. However, something that mostly uses the extant
>> code
>> > > for
>> > >       supporting "https" should be doable.
>> > > [more stuff snipped]
>> > >
>> > > _______________________________________________
>> > > nfsv4 mailing list
>> > > [e-mail]
>> > > https://www.ietf.org/mailman/listinfo/nfsv4
>> > >
>>
>> > _______________________________________________
>> > nfsv4 mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/nfsv4
>>
>>