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

[Chuck Lever <[e-mail]>]

> On Apr 1, 2019, at 4:31 PM, Olga Kornievskaia <[e-mail]> wrote:
> 
> On Mon, Apr 1, 2019 at 1:50 PM Chuck Lever <[e-mail]> wrote:
>> 
>> Olga, thanks for your comments.
>> 
>> 
>>> On Apr 1, 2019, at 12:06 PM, Olga Kornievskaia <[e-mail]> wrote:
>>> 
>>> Comments about the draft-1 and section 4.3 Authentication.
>>> 
>>> 1. Why is there no option of no client authentication and simply using
>>> server-side authentication and using AUTH_SYS on top of it (and
>>> perhaps this is addressed by the 2nd editorial comment in the [] but
>>> the lack including this as an option bothered me). I think this is the
>>> most useful option to be considered.
>> 
>> I quite agree that it is the most useful. I don't see where we are
>> specifically excluding that option, however.
> 
> Ok I guess I have issues with wording. That section talks about "host
> and user authentication". What is "host" here? Is this the NFS server
> or is this a client machine where a "user" might execute NFS
> operations? I really hope that "host" means an NFS server and it's the
> NFS server that will be authenticated via TLS (which means a
> server-side certificate will be used).

I thought that "host authentication" had an unambiguous meaning.
It means that the peer host is authenticated.

RPCSEC GSS performs host authentication using the service principals
on both peers.

With TLS, AIUI, the client can always authenticate the server, because
the server is required to have an identity (typically a certificate).
The server can authenticate a connecting client if the client has an
identity and presents it during the TLS handshake.

I can add "host authentication" and "user authentication" in the
Terminology section if people feel that would be helpful. Or should
I use "machine authentication" instead of "host authentication" ?


> That leads to Option 1 wording.
> It's not clear which side would used a self-signed certificate and why
> we right away restricting/suggestion the type of the certificate. I
> think it would be better to say: "To establish a secure TLS connection
> at least a server-side PKI certificate is required and can provides
> server authentication. Statement: "end-to-end encryption is provided
> client certificate material" ... I don't think that's what end-to-end
> encryption typically means. I would rather say. "Mutual authentication
> is provided when client also presents a PKI certification during a TLS
> handshake." (or something of that sorts).
> 
> My wording of the options:
> TLS server-side authentication only with AUTH_SYS identity: To
> establish a secure TLS connection a server-side PKI certificate is
> required and provides server authentication (either self-signed or
> CA-certified certificates can be used). After TLS connection is
> established, the RPC client uses AUTH_SYS to identify users with the
> guarantee that the UID and GID values cannot be observed or altered in
> transit.
> 
> TLS mutual authentication with AUTH_SYS:  During TLS negotiation, the
> client identifies itself to the server with a PKI certificate.  As
> with encryption-only with AUTH_SYS, UID and GID values are well
> protected.  In addition, the server can use the client's PKI identity
> to perform additional authorization of this client's requests.
> 
> TLS server-side authentication only with RPCSEC GSS Kerberos identify:
> To establish a secure TLS connection a server-side PKI certificate is
> required and provides server authentication (either self-signed or
> CA-certified certificates can be used). The RPC client uses Kerberos
> to identify the client host and its users, but does not request GSS
> integrity or privacy services as the connection is already secured.
> 
> TLS mutual authentication with AUTH_NONE:  Each user establishes her
> own TLS context with the server, identified by a user PKI certficate.
> There is no need for any additional information at the RPC layer, so
> the RPC client can use the simplest authentication flavor for RPC
> transactions.  This configuration is not typical for NFS deployments,
> but it does enable strong certificate-based user authentication, which
> is currently not afforded by GSS.

This appears to be based on an outdated version of this document.
The latest version is here:

https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpc-tls/

I hope Section 4.2 of the latest revision answers your questions.


> If by "host" you don't mean the "server" and mean client's machine.
> And for the server we are not implying that it's OK to use self-signed
> certificates (which I really hoped we were not suggestion).
> 
> Then the options I propose should be:
> 1. TLS server-side authentication + AUTH_SYS user identity: this is
> the favorable option of no certificates on the client at all and only
> server is authenticated.
> 
> 2. TLS mutual authentication with machine certificates + AUTH_SYS user
> identity . This is where I think a suggestion to use a self-signed
> certificate can be made (however see my view below that I don't this
> client-side authentication gains us anything).
> 
> 3. TLS mutual authentication with user certificates + AUTH_SYS user identify
> 
> 4. TLS mutual authentication with machine certificate + Kerberos user identify
> 
> 5. TLS mutual authentication with user certificates + Kerberos user identify
> 
> 6. TLS mutual authentication with user certificates + AUTH_NONE
> 
> 
> 
>>> I don't see how adding
>>> self-signed client certificates adds to the security of the system but
>>> instead this adds a costly PKI operation that would impact the time it
>>> takes to establish a secure connection.
>> 
>> Self-signed certificates allow a form of weak authentication by the
>> server. At least it can audit which client is connecting. The
>> discussion of self-signed certs can be removed if it's not something
>> we want to explicitly commend.
> 
> In my personal option, adding self-signed (user) authentication
> provides no benefits as there no attack that it protects from. We are
> not proposing to use the identity gotten from the client-side of the
> TLS connection and map it to an nfs4 identity, are we (cue in the SPKM
> troubles here).

IIRC we eventually decided not to support the use of user certs
for RPC on TLS.


>> It can be made a little more robust by using DANE, maybe.
>> 
>> 
>>> 2. If there is an addition of certificated-based authentication (and
>>> specifically for option #4 of PKI-based crews + AUTH_NONE) shouldn't
>>> there be wording on what it means to do PKI-based authentication (the
>>> whole fun of interpreting X.509-based certification etc).
>> 
>> Feel free to propose text, or point us to an example discussion.
> 
> Haha, sorry I probably shouldn't have said anything as I have nothing
> of use to add. Andy and I wrote the SPKM spec and dealing with X509
> identities is what killed it. Thus I don't know how to fix it. But I
> strongly feel that using generic words for allowing PKI-based
> authentication and not specifying the details might lead to
> implementation problems.
> 
>>> 3. This is about the wording of option #3 and specifically ".. doesn't
>>> need to enable costly GSS integrity or privacy services". This to me
>>> reads that GSS integrity/privacy services is more costly that doing
>>> the same with TLS which I don't believe is a true statement.
>> 
>> It is a true statement in the sense that TLS may be offloaded from the
>> host. Otherwise, I agree: if encryption is done by the host CPU, there
>> is going to be little or no difference in computational cost.
> 
> Hm, I'm curious where you would offload TLS (and specifically what)
> and why can't we state that encryption operations can be offloaded for
> the current implementation.

https://en.wikipedia.org/wiki/TLS_acceleration


>>> Shouldn't
>>> it be something like "it can forego using GSS integrity/privacy
>>> services because the transport layer already provides an encrypted
>>> connection" or something of the sorts that say we don't need to do
>>> integrity/privacy twice?
>> 
>> Sure, that's fair. I'll revise that text.
>> 
>> 
>>> 4. This is somewhat implementation specific question. If the draft is
>>> introducing an AUTH_TLS RPC security mechanism, I assume in linux we'd
>>> translate it to "sec=tls" option to be like other RPC AUTH mechanisms.
>>> But "sec=tls" doesn't quite work, it better fits with the "proto=tls"
>>> option group because "tls" by itself isn't enough. It'll always be
>>> combined with a traditional "sec=sys" or "sec=krb5". Then we are
>>> really introducing an option like "sec=tls+sys" or "sec=tls+krb5".
>> 
>> This is an implementation issue rather than a protocol issue, of
>> course, but I don't feel that sec= makes sense at this point. We
>> are not changing the way RPC users are authenticated, which is what
>> sec= controls.
> 
> You say you are not changing the way RPC users are authentication but
> isn't the option of TLS authentication + AUTH_NONE indeed changes how
> the RPC user is authenticated?
> 
>> 
>> 
>>> Then shouldn't we be introducing something like AUTH_TLS_SYS and
>>> AUTH_TLS_GSS?
>> 
>> No. The purpose of AUTH_TLS is simply to discover server support for
>> TLS. It is explicitly forbidden to be used after the TLS handshake.
> 
> So by adding AUTH_TLS you are overloading what the "enum auth_flavor"
> list provides. It lists authentication flavors so I feel it's a bit
> sinister to use it for negotiation and not authentication.

Can you elaborate on that?


>>> Or if we are really talking about "proto=tls" (or
>>> proto=dtls) do we even need AUTH_TLS and couldn't it be port-based
>>> decision to support it or not (but yes I read the RFC 2595 that
>>> discourages the use of "secure" ports as they could lead to user and
>>> administrator misconceptions). To reiterate, I feel that if AUTH_TLS
>>> is added but "sec=tls isn't used it would be confusing to users.
>> 
>> See earlier parts of this thread. I think we are purposely trying to
>> avoid introducing new ports and portmapper dependencies. A netid-
>> based solution is probably a non-starter.
>> 
>> I expect we will add a family of TLS mount and export options to
>> control transport-level security, separate from transport protocol
>> and user authentication mode.
>> 
>> 
>>> On Fri, Mar 29, 2019 at 10:18 AM Chuck Lever <[e-mail]> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Mar 28, 2019, at 8:35 PM, Tom Talpey <[e-mail]> wrote:
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Chuck Lever <[e-mail]>
>>>>>> Sent: Thursday, March 28, 2019 3:43 PM
>>>>>> To: Tom Talpey <[e-mail]>
>>>>>> Cc: Lars Eggert <[e-mail]>; NFSv4 <[e-mail]>
>>>>>> Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt
>>>>>> 
>>>>>> 
>>>>>>> On Mar 26, 2019, at 1:58 PM, Tom Talpey <[e-mail]> wrote:
>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: nfsv4 <[e-mail]> On Behalf Of Chuck Lever
>>>>>>>> Sent: Tuesday, March 26, 2019 1:52 PM
>>>>>>>> To: Lars Eggert <[e-mail]>
>>>>>>>> Cc: NFSv4 <[e-mail]>
>>>>>>>> Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-
>>>>>> 01.txt
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Mar 26, 2019, at 12:35 PM, Lars Eggert <[e-mail]> wrote:
>>>>>>>>> 
>>>>>>>>> On 2019-3-26, at 17:33, Lars Eggert <[e-mail]> wrote:
>>>>>>>>>> Also note that STARTTLS is somewhat less secure than running TLS
>>>>>> directly.
>>>>>>>> See for example Section 6 of RFC3207:
>>>>>>>>>> 
>>>>>>>>>> A man-in-the-middle attack can be launched by deleting the "250
>>>>>>>>>> STARTTLS" response from the server.  This would cause the client not
>>>>>>>>>> to try to start a TLS session.  Another man-in-the-middle attack is
>>>>>>>>>> to allow the server to announce its STARTTLS capability, but to alter
>>>>>>>>>> the client's request to start TLS and the server's response.
>>>>>>>>>> 
>>>>>>>>>> ...
>>>>>>>>> 
>>>>>>>>> And RFC8314 recommends (for mail) that "implicit TLS" should be used
>>>>>>>> instead of STARTTLS.
>>>>>>>> 
>>>>>>>> Perhaps that is what we should require for RPC on TLS;
>>>>>>>> that is, "STARTTLS MUST NOT be used"?
>>>>>>> 
>>>>>>> It's a fine requirement, but there may need to be a justification for the MUST.
>>>>>>> 
>>>>>>> It's important to note that such a requirement means you'll need to allocate
>>>>>>> a new port number for such connections. This would apply to any upper
>>>>>>> layer using the new RPC flavor, which in turn might impact the portmapper.
>>>>>>> Note, it may also have implications on the proposed negotiation. If TLS is
>>>>>>> a "done deal", negotiating the auth flavor may be moot.
>>>>>> 
>>>>>> We could create a new netid for this purpose.
>>>>>> 
>>>>>> Advertise an RPC program with this new netid, and no STARTTLS would
>>>>>> be needed. The client simply connects and begins TLS negotiation.
>>>>> 
>>>>> But, the current draft proposes using a new AUTH_TLS exchange, which
>>>>> if successful allows the client to perform a STARTTLS. If you define a netid
>>>>> and/or port number, the client would simply start in TLS, prior to even
>>>>> sending its first RPC.
>>>>> 
>>>>> Would that not simply make the whole draft unnecessary?
>>>> 
>>>> No. The current revision places a number of restrictions on how TLS
>>>> is used, and that is needed in any case. But, the draft could define
>>>> new netids and reserve a new port number for making portmapper requests
>>>> using TLS.
>>>> 
>>>> Anyway, this is a strawman. I wanted to bring it up to ensure we are
>>>> happy with using STARTTLS.
>>>> 
>>>> 
>>>> --
>>>> Chuck Lever
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> nfsv4 mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/nfsv4
>>> 
>>> _______________________________________________
>>> nfsv4 mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/nfsv4
>> 
>> --
>> Chuck Lever

--
Chuck Lever