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

[Chuck Lever <[e-mail]>]

> On Sep 1, 2020, at 12:09 PM, Benjamin Kaduk <[e-mail]> wrote:
> 
> On Tue, Sep 01, 2020 at 11:06:18AM -0400, Chuck Lever wrote:
>> 
>> 
>>> On Aug 31, 2020, at 4:44 PM, Benjamin Kaduk <[e-mail]> wrote:
>>> 
>>> On Mon, Aug 31, 2020 at 11:06:51AM -0400, Chuck Lever wrote:
>>>> Hi-
>>>> 
>>>> I've now addressed Roman's DISCUSS/COMMENT position. For reference, the
>>>> current Editor's Copy with these changes can be found here:
>>> 
>>> Hmm, not quite -- the RFC 5487 ciphers are not compatible with TLS 1.3,
>>> since TLS 1.3 redefines what a ciphersuite is (which also means that TLS
>>> 1.3 provides native support for PSK handshakes), so you still need to
>>> update Section 5.2.2 of this draft to refer to RFC 8446, removing the 4279
>>> and 5487 references.
>> 
>> Whoops. A recent bad change needs to be reverted there.
>> 
>> NEW:
>> 
>> 5.2.2.  Pre-Shared Keys
>> 
>>   This mechanism is OPTIONAL to implement.  In this mode, the RPC peer
>>   is uniquely identified by keying material that has been shared out-
>>   of-band or by a previous TLS-protected connection (see Section 2.2 of
>>   [RFC8446]).  At least the following parameters of the TLS connection
>>   SHOULD be exposed to the RPC server:
>> 
>>   *  The IP address of the peer that presented the certificate
> 
> In PSK mode, there may not be a certificate (though there can be, in
> various scenarios).

And perhaps the IP address of the peer has changed since the PSK
was originally exchanged.


>>   *  TLS Identifier
> 
> Is this the PSK identifier or some other (TLS Exporter-generated?) value?

Not clear to me that we need to define a TLS Exporter.

I think the only use for the identity information is to authenticate
the peer. We're not trying to use the PSK material for anything else.

So we want something that indicates that "this peer is the same peer
we contacted when the PSK was originally exchanged."


--
Chuck Lever