Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key
draft-ietf-tls-tls13-cert-with-extern-psk-03

Versions:

00
01
02
03
04
05
06
07
RFC 8773

The information below is for an old version of the document.

Document	Type	This is an older version of an Internet-Draft that was ultimately published as RFC 8773.
	Author	Russ Housley
	Last updated	2019-12-12 (Latest revision 2019-11-17)
	Replaces	draft-housley-tls-tls13-cert-with-extern-psk
	RFC stream	Internet Engineering Task Force (IETF)
	Formats	txt htmlized pdf bibtex bibxml
	Reviews	GENART Last Call review by Ines Robles Ready OPSDIR Last Call review by Scott Bradner Ready
	Additional resources	Mailing list discussion
Stream	WG state	Submitted to IESG for Publication
	Document shepherd	Joseph A. Salowey
	Shepherd write-up	Show Last changed 2019-07-01
IESG	IESG state	Became RFC 8773 (Experimental)
	Consensus boilerplate	Unknown
	Telechat date	(None) Needs a YES.
	Responsible AD	Benjamin Kaduk
	Send notices to	Joseph Salowey <joe@salowey.net>
IANA	IANA review state	IANA OK - Actions Needed
	IANA expert review state	Expert Reviews OK

Email authors Email WG IPR References Referenced by Nits Search email archive

draft-ietf-tls-tls13-cert-with-extern-psk-03

Network Working Group R. Housley
Internet-Draft Vigil Security
Intended status: Experimental November 17, 2019
Expires: May 20, 2020

TLS 1.3 Extension for Certificate-based Authentication with an External
Pre-Shared Key
draft-ietf-tls-tls13-cert-with-extern-psk-03

Abstract

This document specifies a TLS 1.3 extension that allows a server to
authenticate with a combination of a certificate and an external pre-
shared key (PSK).

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on May 20, 2020.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Housley Expires May 20, 2020 [Page 1]
Internet-Draft Certificate with External PSK November 2019

1. Introduction

The TLS 1.3 [RFC8446] handshake protocol provides two mutually
exclusive forms of server authentication. First, the server can be
authenticated by providing a signature certificate and creating a
valid digital signature to demonstrate that it possesses the
corresponding private key. Second, the server can be authenticated
by demonstrating that it possesses a pre-shared key (PSK) that was
established by a previous handshake. A PSK that is established in
this fashion is called a resumption PSK. A PSK that is established
by any other means is called an external PSK. This document
specifies a TLS 1.3 extension permitting certificate-based server
authentication to be combined with an external PSK as an input to the
TLS 1.3 key schedule.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.

3. Motivation and Design Rationale

The development of a large-scale quantum computer would pose a
serious challenge for the cryptographic algorithms that are widely
deployed today, including the digital signature algorithms that are
used to authenticate the server in the TLS 1.3 handshake protocol.
It is an open question whether or not it is feasible to build a
large-scale quantum computer, and if so, when that might happen.
However, if such a quantum computer is invented, many of the
cryptographic algorithms and the security protocols that use them
would become vulnerable.

The TLS 1.3 handshake protocol employs key agreement algorithms and
digital signature algorithms that could be broken by the development
of a large-scale quantum computer [I-D.hoffman-c2pq]. The key
agreement algorithms include Diffie-Hellman (DH) [DH1977] and
Elliptic Curve Diffie-Hellman (ECDH) [IEEE1363]; the digital
signature algorithms inclue RSA [RFC8017] and Elliptic Curve Digital
Signature Algorithm (ECDSA) [FIPS186]. As a result, an adversary
that stores a TLS 1.3 handshake protocol exchange today could decrypt
the associated encrypted communications in the future when a large-
scale quantum computer becomes available.

In the near-term, this document describes TLS 1.3 extension to
protect today's communications from the future invention of a large-

Housley Expires May 20, 2020 [Page 2]
Internet-Draft Certificate with External PSK November 2019

scale quantum computer by providing a strong external PSK as an input
to the TLS 1.3 key schedule while preserving the authentication
provided by the existing certificate and digital signature
mechanisms.

4. Extension Overview

This section provides a brief overview of the
"tls_cert_with_extern_psk" extension.

The client includes the "tls_cert_with_extern_psk" extension in the
ClientHello message. The "tls_cert_with_extern_psk" extension MUST
be accompanied by the "key_share", "psk_key_exchange_modes", and
"pre_shared_key" extensions. The client MAY also find it useful to
include the "supported_groups" extension. Since the
"tls_cert_with_extern_psk" extension is intended to be used only with
initial handshakes, it MUST NOT be sent alongside the "early_data"
extension. These extensions are all described in Section 4.2 of
[RFC8446], which also requires the "pre_shared_key" extension to be
the last extension in the ClientHello message.

If the server is willing to use one of the external PSKs listed in
the "pre_shared_key" extension and perform certificate-based
authentication, then the server includes the
"tls_cert_with_extern_psk" extension in the ServerHello message. The
"tls_cert_with_extern_psk" extension MUST be accompanied by the
"key_share" and "pre_shared_key" extensions. If none of the external
PSKs in the list provided by the client is acceptable to the server,
then the "tls_cert_with_extern_psk" extension is omitted from the
ServerHello message.

When the "tls_cert_with_extern_psk" extension is successfully
negotiated, the TLS 1.3 key schedule processing includes both the
selected external PSK and the (EC)DHE shared secret value. As a
result, the Early Secret, Handshake Secret, and Master Secret values
all depend upon the value of the selected external PSK. Of course,
the Early Secret does not depend upon the (EC)DHE shared secret.

The authentication of the server and optional authentication of the
client depend upon the ability to generate a signature that can be
validated with the public key in their certificates. The
authentication processing is not changed in any way by the selected
external PSK.

Each external PSK is associated with a single hash algorithm, which
is required by Section 4.2.11 of [RFC8446]. The hash algorithm MUST
be set when the PSK is established, with a default of SHA-256.

Housley Expires May 20, 2020 [Page 3]
Internet-Draft Certificate with External PSK November 2019

5. Certificate with External PSK Extension

This section specifies the "tls_cert_with_extern_psk" extension,
which MAY appear in the ClientHello message and ServerHello message.
It MUST NOT appear in any other messages. The
"tls_cert_with_extern_psk" extension MUST NOT appear in the
ServerHello message unless the "tls_cert_with_extern_psk" extension
appeared in the preceding ClientHello message. If an implementation
recognizes the "tls_cert_with_extern_psk" extension and receives it
in any other message, then the implementation MUST abort the
handshake with an "illegal_parameter" alert.

The general extension mechanisms enable clients and servers to
negotiate the use of specific extensions. Clients request extended
functionality from servers with the extensions field in the
ClientHello message. If the server responds with a HelloRetryRequest
message, then the client sends another ClientHello message as
described in Section 4.1.2 of [RFC8446], including the same
"tls_cert_with_extern_psk" extension as the original ClientHello
message or abort the handshake.

Many server extensions are carried in the EncryptedExtensions
message; however, the "tls_cert_with_extern_psk" extension is carried
in the ServerHello message. Successful negotiation of the
"tls_cert_with_extern_psk" extension affects the key used for
encryption, so it cannot be carried in the EncryptedExtensions
message. Therefore, the "tls_cert_with_extern_psk" extension is only
present in the ServerHello message if the server recognizes the
"tls_cert_with_extern_psk" extension and the server possesses one of
the external PSKs offered by the client in the "pre_shared_key"
extension in the ClientHello message.

The Extension structure is defined in [RFC8446]; it is repeated here
for convenience.

struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;

The "extension_type" identifies the particular extension type, and
the "extension_data" contains information specific to the particular
extension type.

This document specifies the "tls_cert_with_extern_psk" extension,
adding one new type to ExtensionType:

Housley Expires May 20, 2020 [Page 4]
Internet-Draft Certificate with External PSK November 2019

enum {
tls_cert_with_extern_psk(TBD), (65535)
} ExtensionType;

The "tls_cert_with_extern_psk" extension is relevant when the client
and server possess an external PSK in common that can be used as an
input to the TLS 1.3 key schedule. The "tls_cert_with_extern_psk"
extension is essentially a flag to use the external PSK in the key
schedule, and it has the following syntax:

struct {
select (Handshake.msg_type) {
case client_hello: Empty;
case server_hello: Empty;
};
} CertWithExternPSK;

5.1. Companion Extensions

Section 4 lists the extensions that are required to accompany the
"tls_cert_with_extern_psk" extension. Most of those extension are
not impacted in any way. This section discusses the impacts on the
other extensions.

The "psk_key_exchange_modes" extension is defined in Section 4.2.9 of
[RFC8446]. The "psk_key_exchange_modes" extension restricts both the
use of PSKs offered in this ClientHello and those which the server
might supply via a subsequent NewSessionTicket. As a result, when
the "psk_key_exchange_modes" extension is included in the ClientHello
message, clients MUST include psk_dhe_ke mode. In addition, clients
MAY also include psk_ke mode to support a subsequent
NewSessionTicket. When the "psk_key_exchange_modes" extension is
included in the ServerHello message, servers MUST select the
psk_dhe_ke mode for the initial handshake. Servers MUST select a key
exchange mode that is listed by the client for subsequent handshakes
that include the resumption PSK from the initial handshake.

The "pre_shared_key" extension is defined in Section 4.2.11 of
[RFC8446]. The syntax is repeated below for convenience. All of the
listed PSKs MUST be external PSKs. If a resumption PSK is listed
along with the "tls_cert_with_extern_psk" extension, the server MUST
abort the handshake with an "illegal_parameter" alert.

Housley Expires May 20, 2020 [Page 5]
Internet-Draft Certificate with External PSK November 2019

struct {
opaque identity<1..2^16-1>;
uint32 obfuscated_ticket_age;
} PskIdentity;

opaque PskBinderEntry<32..255>;

struct {
PskIdentity identities<7..2^16-1>;
PskBinderEntry binders<33..2^16-1>;
} OfferedPsks;

struct {
select (Handshake.msg_type) {
case client_hello: OfferedPsks;
case server_hello: uint16 selected_identity;
};
} PreSharedKeyExtension;

The OfferedPsks contains the list of PSK identities and associated
binders for the external PSKs that the client is willing to use with
the server.

The identities are a list of external PSK identities that the client
is willing to negotiate with the server. Each external PSK has an
associated identity that is known to the client and the server; the
associated identities may be know to other parties as well. In
addition, the binder validation (see below) confirms that the client
and server have the same key associated with the identity.

The obfuscated_ticket_age is not used for external PSKs. As stated
in Section 4.2.11 of [RFC8446], clients SHOULD set this value to 0,
and servers MUST ignore the value.

The binders are a series of HMAC values, one for each external PSK
offered by the client, in the same order as the identities list. The
HMAC value is computed using the binder_key, which is derived from
the external PSK, and a partial transcript of the current handshake.
Generation of the binder_key from the external PSK is described in
Section 7.1 of [RFC8446]. The partial transcript of the current
handshake includes a partial ClientHello up to and including the
PreSharedKeyExtension.identities field as described in
Section 4.2.11.2 of [RFC8446].

The selected_identity contains the index of the external PSK identity
that the server selected from the list offered by the client. As
described in Section 4.2.11.2 of [RFC8446], the server MUST validate

Housley Expires May 20, 2020 [Page 6]
Internet-Draft Certificate with External PSK November 2019

the binder value that corresponds to the selected external PSK, and
if the binder does not validate, the server MUST abort the handshake
with an "illegal_parameter" alert.

5.2. Authentication

When the "tls_cert_with_extern_psk" extension is successfully
negotiated, authentication of the server depends upon the ability to
generate a signature that can be validated with the public key in the
server's certificate. This is accomplished by the server sending the
Certificate and CertificateVerify messages as described in Sections
4.4.2 and 4.4.3 of [RFC8446].

TLS 1.3 does not permit the server to send a CertificateRequest
message when a PSK is being used. This restriction is removed when
the "tls_cert_with_extern_psk" extension is negotiated, allowing
certificate-based authentication for both the client and the server.
If certificate-based client authentication is desired, this is
accomplished by the client sending the Certificate and
CertificateVerify messages as described in Sections 4.4.2 and 4.4.3
of [RFC8446].

5.3. Keying Material

Section 7.1 of [RFC8446] specifies the TLS 1.3 Key Schedule. The
successful negotiation of the "tls_cert_with_extern_psk&14.8. Operation 67: IO_ADVISE - Application I/O access
pattern hints . . . . . . . . . . . . . . . . . . . . . . 77
14.9. Changes to Operation 51: LAYOUTRETURN . . . . . . . . . . 82
14.10. Operation 65: READ_PLUS . . . . . . . . . . . . . . . . . 85
14.11. Operation 66: SEEK . . . . . . . . . . . . . . . . . . . 90
15. NFSv4.2 Callback Operations . . . . . . . . . . . . . . . . . 91
15.1. Operation 15: CB_OFFLOAD - Report results of an
asynchronous operation . . . . . . . . . . . . . . . . . 91
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 93
17.1. Normative References . . . . . . . . . . . . . . . . . . 93
17.2. Informative References . . . . . . . . . . . . . . . . . 93
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 95
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 96
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 96

Haynes Expires September 15, 2013 [Page 4]
Internet-Draft NFSv4.2 March 2013

1. Introduction

1.1. The NFS Version 4 Minor Version 2 Protocol

The NFS version 4 minor version 2 (NFSv4.2) protocol is the third
minor version of the NFS version 4 (NFSv4) protocol. The first minor
version, NFSv4.0, is described in [I-D.ietf-nfsv4-rfc3530bis] and the
second minor version, NFSv4.1, is described in [RFC5661]. It follows
the guidelines for minor versioning that are listed in Section 11 of
[I-D.ietf-nfsv4-rfc3530bis].

As a minor version, NFSv4.2 is consistent with the overall goals for
NFSv4, but extends the protocol so as to better meet those goals,
based on experiences with NFSv4.1. In addition, NFSv4.2 has adopted
some additional goals, which motivate some of the major extensions in
NFSv4.2.

1.2. Scope of This Document

This document describes the NFSv4.2 protocol. With respect to
NFSv4.0 and NFSv4.1, this document does not:

o describe the NFSv4.0 or NFSv4.1 protocols, except where needed to
contrast with NFSv4.2

o modify the specification of the NFSv4.0 or NFSv4.1 protocols

o clarify the NFSv4.0 or NFSv4.1 protocols. I.e., any
clarifications made here apply to NFSv4.2 and neither of the prior
protocols

The full XDR for NFSv4.2 is presented in [4.2xdr].

1.3. NFSv4.2 Goals

The goal of the design of NFSv4.2 is to take common local file system
features and offer them remotely. These features might

o already be available on the servers, e.g., sparse files

o be under development as a new standard, e.g., SEEK_HOLE and
SEEK_DATA

o be used by clients with the servers via some proprietary means,
e.g., Labeled NFS

but the clients are not able to leverage them on the server within
the confines of the NFS protocol.

Haynes Expires September 15, 2013 [Page 5]
Internet-Draft NFSv4.2 March 2013

1.4. Overview of NFSv4.2 Features

1.4.1. Server-side Copy

A traditional file copy from one server to another results in the
data being put on the network twice - source to client and then
client to destination. New operations are introduced to allow the
client to authorize the two servers to interact directly. As this
copy can be lengthy, asynchronous support is also provided.

1.4.2. Application I/O Advise

Applications and clients want to advise the server as to expected I/O
behavior. Using IO_ADVISE (see Section 14.8) to communicate future
I/O behavior such as whether a file will be accessed sequentially or
randomly, and whether a file will or will not be accessed in the near
future, allows servers to optimize future I/O requests for a file by,
for example, prefetching or evicting data. This operation can be
used to support the posix_fadvise function as well as other
applications such as databases and video editors.

1.4.3. Sparse Files

Sparse files are ones which have unallocated data blocks as holes in
the file. Such holes are typically transferred as 0s during I/O.
READ_PLUS (see Section 14.10) allows a server to send back to the
client metadata describing the hole and WRITE_PLUS (see Section 14.7)
allows the client to punch holes into a file. In addition, SEEK (see
Section 14.11) is provided to scan for the next hole or data from a
given location.

1.4.4. Space Reservation

When a file is sparse, one concern applications have is ensuring that
there will always be enough data blocks available for the file during
future writes. A new attribute, space_reserved (see Section 12.2.4)
provides the client a guarantee that space will be available.

1.4.5. Application Data Hole (ADH) Support

Some applications treat a file as if it were a disk and as such want
to initialize (or format) the file image. We extend both READ_PLUS
and WRITE_PLUS to understand this metadata as a new form of a hole.

1.4.6. Labeled NFS

While both clients and servers can employ Mandatory Access Control
(MAC) security models to enforce data access, there has been no

Haynes Expires September 15, 2013 [Page 6]
Internet-Draft NFSv4.2 March 2013

protocol support to allow full interoperability. A new file object
attribute, sec_label (see Section 12.2.2) allows for the server to
store and enforce MAC labels. The format of the sec_label
accommodates any MAC security system.

1.5. Differences from NFSv4.1

In NFSv4.1, the only way to introduce new variants of an operation
was to introduce a new operation. I.e., READ becomes either READ2 or
READ_PLUS. With the use of discriminated unions as parameters to
such functions in NFSv4.2, it is possible to add a new arm in a
subsequent minor version. And it is also possible to move such an
operation from OPTIONAL/RECOMMENDED to REQUIRED. Forcing an
implementation to adopt each arm of a discriminated union at such a
time does not meet the spirit of the minor versioning rules. As
such, new arms of a discriminated union MUST follow the same
guidelines for minor versioning as operations in NFSv4.1 - i.e., they
may not be made REQUIRED. To support this, a new error code,
NFS4ERR_UNION_NOTSUPP, is introduced which allows the server to
communicate to the client that the operation is supported, but the
specific arm of the discriminated union is not.

2. Minor Versioning

To address the requirement of an NFS protocol that can evolve as the
need arises, the NFSv4 protocol contains the rules and framework to
allow for future minor changes or versioning.

The base assumption with respect to minor versioning is that any
future accepted minor version will be documented in one or more
Standards Track RFCs. Minor version 0 of the NFSv4 protocol is
represented by [I-D.ietf-nfsv4-rfc3530bis], minor version 1 by
[RFC5661], and minor version 2 by this document. The COMPOUND and
CB_COMPOUND procedures support the encoding of the minor version
being requested by the client.

The following items represent the basic rules for the development of
minor versions. Note that a future minor version may modify or add
to the following rules as part of the minor version definition.

1. Procedures are not added or deleted.

To maintain the general RPC model, NFSv4 minor versions will not
add to or delete procedures from the NFS program.

2. Minor versions may add operations to the COMPOUND and
CB_COMPOUND procedures.

Haynes Expires September 15, 2013 [Page 7]
Internet-Draft NFSv4.2 March 2013

The addition of operations to the COMPOUND and CB_COMPOUND
procedures does not affect the RPC model.

* Minor versions may append attributes to the bitmap4 that
represents sets of attributes and to the fattr4 that
represents sets of attribute values.

This allows for the expansion of the attribute model to allow
for future growth or adaptation.

* Minor version X must append any new attributes after the last
documented attribute.

Since attribute results are specified as an opaque array of
per-attribute, XDR-encoded results, the complexity of adding
new attributes in the midst of the current definitions would
be too burdensome.

3. Minor versions must not modify the structure of an existing
operation's arguments or results.

Again, the complexity of handling multiple structure definitions
for a single operation is too burdensome. New operations should
be added instead of modifying existing structures for a minor
version.

This rule does not preclude the following adaptations in a minor
version:

* adding bits to flag fields, such as new attributes to
GETATTR's bitmap4 data type, and providing corresponding
variants of opaque arrays, such as a notify4 used together
with such bitmaps

* adding bits to existing attributes like ACLs that have flag
words

* extending enumerated types (including NFS4ERR_*) with new
values

* adding cases to a switched union

4. Note that when adding new cases to a switched union, a minor
version must not make new cases be REQUIRED. While the
encapsulating operation may be REQUIRED, the new cases (the
specific arm of the discriminated union) is not. The error code

Haynes Expires September 15, 2013 [Page 8]
Internet-Draft NFSv4.2 March 2013

NFS4ERR_UNION_NOTSUPP is used to notifify the client when the
server does not support such a case.

5. Minor versions must not modify the structure of existing
attributes.

6. Minor versions must not delete operations.

This prevents the potential reuse of a particular operation
"slot" in a future minor version.

7. Minor versions must not delete attributes.

8. Minor versions must not delete flag bits or enumeration values.

9. Minor versions may declare an operation MUST NOT be implemented.

Specifying that an operation MUST NOT be implemented is
equivalent to obsoleting an operation. For the client, it means
that the operation MUST NOT be sent to the server. For the
server, an NFS error can be returned as opposed to "dropping"
the request as an XDR decode error. This approach allows for
the obsolescence of an operation while maintaining its structure
so that a future minor version can reintroduce the operation.

1. Minor versions may declare that an attribute MUST NOT be
implemented.

2. Minor versions may declare that a flag bit or enumeration
value MUST NOT be implemented.

10. Minor versions may declare an operation to be OBSOLESCENT, which
indicates an intention to remove the operation (i.e., make it
MANDATORY TO NOT implement) in a subsequent minor version. Such
labeling is separate from the question of whether the operation
is REQUIRED or RECOMMENDED or OPTIONAL in the current minor
version. An operation may be both REQUIRED for the given minor
version and marked OBSOLESCENT, with the expectation that it
will be MANDATORY TO NOT implement in the next (or other
subsequent) minor version.

11. Note that the early notification of operation obsolescence is
put in place to mitigate the effects of design and
implementation mistakes, and to allow protocol development to
adapt to unexpected changes in the pace of implementation. Even
if an operation is marked OBSOLESCENT in a given minor version,
it may end up not being marked MANDATORY TO NOT implement in the

Haynes Expires September 15, 2013 [Page 9]
Internet-Draft NFSv4.2 March 2013

next minor version. In unusual circumstances, it might not be
marked OBSOLESCENT in a subsequent minor version, and never
become MANDATORY TO NOT implement.

12. Minor versions may downgrade features from REQUIRED to
RECOMMENDED, from RECOMMENDED to OPTIONAL, or from OPIONAL to
MANDATORY TO NOT implement. Also, if a feature was marked as
OBSOLESCENT in the prior minor version, it may be downgraded
from REQUIRED to OPTIONAL from RECOMMENDED to MANDATORY TO NOT
implement, or from REQUIRED to MANDATORY TO NOT implement.

13. Minor versions may upgrade features from OPTIONAL to
RECOMMENDED, or RECOMMENDED to REQUIRED. Also, if a feature was
marked as OBSOLESCENT in the prior minor version, it may be
upgraded to not be OBSOLESCENT.

14. A client and server that support minor version X SHOULD support
minor versions 0 through X-1 as well.

15. Except for infrastructural changes, a minor version must not
introduce REQUIRED new features.

This rule allows for the introduction of new functionality and
forces the use of implementation experience before designating a
feature as REQUIRED. On the other hand, some classes of
features are infrastructural and have broad effects. Allowing
infrastructural features to be RECOMMENDED or OPTIONAL
complicates implementation of the minor version.

16. A client MUST NOT attempt to use a stateid, filehandle, or
similar returned object from the COMPOUND procedure with minor
version X for another COMPOUND procedure with minor version Y,
where X != Y.

3. Server-side Copy

3.1. Introduction

The server-side copy feature provides a mechanism for the NFS client
to perform a file copy on the server without the data being
transmitted back and forth over the network. Without this feature,
an NFS client copies data from one location to another by reading the
data from the server over the network, and then writing the data back
over the network to the server. Using this server-side copy
operation, the client is able to instruct the server to copy the data
locally without the data being sent back and forth over the network
unnecessarily.

Haynes Expires September 15, 2013 [Page 10]
Internet-Draft NFSv4.2 March 2013

If the source object and destination object are on different file
servers, the file servers will communicate with one another to
perform the copy operation. The server-to-server protocol by which
this is accomplished is not defined in this document.

3.2. Protocol Overview

The server-side copy offload operations support both intra-server and
inter-server file copies. An intra-server copy is a copy in which
the source file and destination file reside on the same server. In
an inter-server copy, the source file and destination file are on
different servers. In both cases, the copy may be performed
synchronously or asynchronously.

Throughout the rest of this document, we refer to the NFS server
containing the source file as the "source server" and the NFS server
to which the file is transferred as the "destination server". In the
case of an intra-server copy, the source server and destination
server are the same server. Therefore in the context of an intra-
server copy, the terms source server and destination server refer to
the single server performing the copy.

The operations described below are designed to copy files. Other
file system objects can be copied by building on these operations or
using other techniques. For example if the user wishes to copy a
directory, the client can synthesize a directory copy by first
creating the destination directory and then copying the source
directory's files to the new destination directory. If the user
wishes to copy a namespace junction [FEDFS-NSDB] [FEDFS-ADMIN], the
client can use the ONC RPC Federated Filesystem protocol
[FEDFS-ADMIN] to perform the copy. Specifically the client can
determine the source junction's attributes using the FEDFS_LOOKUP_FSN
procedure and create a duplicate junction using the
FEDFS_CREATE_JUNCTION procedure.

For the inter-server copy, the operations are defined to be
compatible with the traditional copy authentication approach. The
client and user are authorized at the source for reading. Then they
are authorized at the destination for writing.

3.2.1. Overview of Copy Operations

COPY_NOTIFY: For inter-server copies, the client sends this
operation to the source server to notify it of a future file copy
from a given destination server for the given user.
(Section 14.3)

Haynes Expires September 15, 2013 [Page 11]
Internet-Draft NFSv4.2 March 2013

OFFLOAD_REVOKE: Also for inter-server copies, the client sends this
operation to the source server to revoke permission to copy a file
for the given user. (Section 14.4)

COPY: Used by the client to request a file copy. (Section 14.1)

OFFLOAD_ABORT: Used by the client to abort an asynchronous file
copy. (Section 14.2)

OFFLOAD_STATUS: Used by the client to poll the status of an
asynchronous file copy. (Section 14.5)

CB_OFFLOAD: Used by the destination server to report the results of
an asynchronous file copy to the client. (Section 15.1)

3.2.2. Locking the Files

Both the source and destination file may need to be locked to protect
the content during the copy operations. A client can achieve this by
a combination of OPEN and LOCK operations. I.e., either share or
byte range locks might be desired.

3.2.3. Intra-Server Copy

To copy a file on a single server, the client uses a COPY operation.
The server may respond to the copy operation with the final results
of the copy or it may perform the copy asynchronously and deliver the
results using a CB_OFFLOAD operation callback. If the copy is
performed asynchronously, the client may poll the status of the copy
using OFFLOAD_STATUS or cancel the copy using OFFLOAD_ABORT.

A synchronous intra-server copy is shown in Figure 1. In this
example, the NFS server chooses to perform the copy synchronously.
The copy operation is completed, either successfully or
unsuccessfully, before the server replies to the client's request.
The server's reply contains the final result of the operation.

Haynes Expires September 15, 2013 [Page 12]
Internet-Draft NFSv4.2 March 2013

Figure 1: A synchronous intra-server copy.

An asynchronous intra-server copy is shown in Figure 2. In this
example, the NFS server performs the copy asynchronously. The
server's reply to the copy request indicates that the copy operation
was initiated and the final result will be delivered at a later time.
The server's reply also contains a copy stateid. The client may use
this copy stateid to poll for status information (as shown) or to
cancel the copy using a OFFLOAD_ABORT. When the server completes the
copy, the server performs a callback to the client and reports the
results.

Haynes Expires September 15, 2013 [Page 13]
Internet-Draft NFSv4.2 March 2013

Client Server
+ +
| |
|--- OPEN ---------------------------->| Client opens
|<------------------------------------/| the source file
| |
|--- OPEN ---------------------------->| Client opens
|<------------------------------------/| the destination file
| |
|--- COPY ---------------------------->| Client requests
|<------------------------------------/| a file copy
| |
| |
|--- OFFLOAD_STATUS ------------------>| Client may poll
|<------------------------------------/| for status
| |
| . | Multiple OFFLOAD_STATUS
| . | operations may be sent.
| . |
| |
|<-- CB_OFFLOAD -----------------------| Server reports results
|\------------------------------------>|
| |
|--- CLOSE --------------------------->| Client closes
|<------------------------------------/| the destination file
| |
|--- CLOSE --------------------------->| Client closes
|<------------------------------------/| the source file
| |
| |

Figure 2: An asynchronous intra-server copy.

3.2.4. Inter-Server Copy

A copy may also be performed between two servers. The copy protocol
is designed to accommodate a variety of network topologies. As shown
in Figure 3, the client and servers may be connected by multiple
networks. In particular, the servers may be connected by a
specialized, high speed network (network 192.0.2.0/24 in the diagram)
that does not include the client. The protocol allows the client to
setup the copy between the servers (over network 203.0.113.0/24 in
the diagram) and for the servers to communicate on the high speed
network if they choose to do so.

Haynes Expires September 15, 2013 [Page 14]
Internet-Draft NFSv4.2 March 2013

192.0.2.0/24
+-------------------------------------+
| |
| |
| 192.0.2.18 | 192.0.2.56
+-------+------+ +------+------+
| Source | | Destination |
+-------+------+ +------+------+
| 203.0.113.18 | 203.0.113.56
| |
| |
| 203.0.113.0/24 |
+------------------+------------------+
|
|
| 203.0.113.243
+-----+-----+
| Client |
+-----------+

Figure 3: An example inter-server network topology.

For an inter-server copy, the client notifies the source server that
a file will be copied by the destination server using a COPY_NOTIFY
operation. The client then initiates the copy by sending the COPY
operation to the destination server. The destination server may
perform the copy synchronously or asynchronously.

A synchronous inter-server copy is shown in Figure 4. In this case,
the destination server chooses to perform the copy before responding
to the client's COPY request.

An asynchronous copy is shown in Figure 5. In this case, the
destination server chooses to respond to the client's COPY request
immediately and then perform the copy asynchronously.

Haynes Expires September 15, 2013 [Page 15]
Internet-Draft NFSv4.2 March 2013

Client Source Destination
+ + +
| | |
|--- OPEN --->| | Returns os1
|<------------------/| |
| | |
|--- COPY_NOTIFY --->| |
|<------------------/| |
| | |
|--- OPEN ---------------------------->| Returns os2
|<------------------------------------/|
| | |
|--- COPY ---------------------------->|
| | |
| | |
| |<----- read -----|
| |\--------------->|
| | |
| | . | Multiple reads may
| | . | be necessary
| | . |
| | |
| | |
|<------------------------------------/| Destination replies
| | | to COPY
| | |
|--- CLOSE --------------------------->| Release open state
|<------------------------------------/|
| | |
|--- CLOSE --->| | Release open state
|<------------------/| |

Figure 4: A synchronous inter-server copy.

Haynes Expires September 15, 2013 [Page 16]
Internet-Draft NFSv4.2 March 2013

| | |
|--- OPEN ---------------------------->| Returns os2
|<------------------------------------/|
| | |
|--- LOCK ---------------------------->| Optional ...
|<------------------------------------/|
| | |
|--- COPY ---------------------------->| Need to pass in
|<------------------------------------/| os2 or lock state
| | |
| | |
| |<----- read -----|
| |\--------------->|
| | |
| | . | Multiple reads may
| | . | be necessary
| | . |
| | |
| | |
|--- OFFLOAD_STATUS ------------------>| Client may poll
|<------------------------------------/| for status
| | |
| | . | Multiple OFFLOAD_STATUS
| | . | operations may be sent
| | . |
| | |
| | |
| | |
|<-- CB_OFFLOAD -----------------------| Destination reports
|\------------------------------------>| results
| | |
|--- LOCKU --------------------------->| Only if LOCK was done
|<------------------------------------/|
| | |
|--- CLOSE --------------------------->| Release open state
|<------------------------------------/|
| | |
|--- LOCKU --->| | Only if LOCK was done
|<------------------/| |
| | |
|--- CLOSE --->| | Release open state
|<------------------/| |
| | |

Figure 5: An asynchronous inter-server copy.

Haynes Expires September 15, 2013 [Page 17]
Internet-Draft NFSv4.2 March 2013

3.2.5. Server-to-Server Copy Protocol

The source server and destination server are not required to use a
specific protocol to transfer the file data. The choice of what
protocol to use is ultimately the destination server's decision.

3.2.5.1. Using NFSv4.x as a Server-to-Server Copy Protocol

The destination server MAY use standard NFSv4.x (where x >= 1) to
read the data from the source server. If NFSv4.x is used for the
server-to-server copy protocol, the destination server can use the
filehandle contained in the COPY request with standard NFSv4.x
operations to read data from the source server. Specifically, the
destination server may use the NFSv4.x OPEN operation's CLAIM_FH
facility to open the file being copied and obtain an open stateid.
Using the stateid, the destination server may then use NFSv4.x READ
operations to read the file.

3.2.5.2. Using an alternative Server-to-Server Copy Protocol

In a homogeneous environment, the source and destination servers
might be able to perform the file copy extremely efficiently using
specialized protocols. For example the source and destination
servers might be two nodes sharing a common file system format for
the source and destination file systems. Thus the source and
destination are in an ideal position to efficiently render the image
of the source file to the destination file by replicating the file
system formats at the block level. Another possibility is that the
source and destination might be two nodes sharing a common storage
area network, and thus there is no need to copy any data at all, and
instead ownership of the file and its contents might simply be re-
assigned to the destination. To allow for these possibilities, the
destination server is allowed to use a server-to-server copy protocol
of its choice.

In a heterogeneous environment, using a protocol other than NFSv4.x
(e.g., HTTP [RFC2616] or FTP [RFC0959]) presents some challenges. In
particular, the destination server is presented with the challenge of
accessing the source file given only an NFSv4.x filehandle.

One option for protocols that identify source files with path names
is to use an ASCII hexadecimal representation of the source
filehandle as the file name.

Another option for the source server is to use URLs to direct the
destination server to a specialized service. For example, the
response to COPY_NOTIFY could include the URL
ftp://s1.example.com:9999/_FH/0x12345, where 0x12345 is the ASCII

Haynes Expires September 15, 2013 [Page 18]
Internet-Draft NFSv4.2 March 2013

hexadecimal representation of the source filehandle. When the
destination server receives the source server's URL, it would use
"_FH/0x12345" as the file name to pass to the FTP server listening on
port 9999 of s1.example.com. On port 9999 there would be a special
instance of the FTP service that understands how to convert NFS
filehandles to an open file descriptor (in many operating systems,
this would require a new system call, one which is the inverse of the
makefh() function that the pre-NFSv4 MOUNT service needs).

Authenticating and identifying the destination server to the source
server is also a challenge. Recommendations for how to accomplish
this are given in Section 3.4.1.2.4 and Section 3.4.1.4.

3.3. Requirements for Operations

The implementation of server-side copy is OPTIONAL by the client and
the server. However, in order to successfully copy a file, some
operations MUST be supported by the client and/or server.

If a client desires an intra-server file copy, then it MUST support
the COPY and CB_OFFLOAD operations. If COPY returns a stateid, then
the client MAY use the OFFLOAD_ABORT and OFFLOAD_STATUS operations.

If a client desires an inter-server file copy, then it MUST support
the COPY, COPY_NOTICE, and CB_OFFLOAD operations, and MAY use the
OFFLOAD_REVOKE operation. If COPY returns a stateid, then the client
MAY use the OFFLOAD_ABORT and OFFLOAD_STATUS operations.

If a server supports intra-server copy, then the server MUST support
the COPY operation. If a server's COPY operation returns a stateid,
then the server MUST also support these operations: CB_OFFLOAD,
OFFLOAD_ABORT, and OFFLOAD_STATUS.

If a source server supports inter-server copy, then the source server
MUST support all these operations: COPY_NOTIFY and OFFLOAD_REVOKE.
If a destination server supports inter-server copy, then the
destination server MUST support the COPY operation. If a destination
server's COPY operation returns a stateid, then the destination
server MUST also support these operations: CB_OFFLOAD, OFFLOAD_ABORT,
COPY_NOTIFY, OFFLOAD_REVOKE, and OFFLOAD_STATUS.

Each operation is performed in the context of the user identified by
the ONC RPC credential of its containing COMPOUND or CB_COMPOUND
request. For example, a OFFLOAD_ABORT operation issued by a given
user indicates that a specified COPY operation initiated by the same
user be canceled. Therefore a OFFLOAD_ABORT MUST NOT interfere with
a copy of the same file initiated by another user.

Haynes Expires September 15, 2013 [Page 19]
Internet-Draft NFSv4.2 March 2013

An NFS server MAY allow an administrative user to monitor or cancel
copy operations using an implementation specific interface.

3.3.1. netloc4 - Network Locations

The server-side copy operations specify network locations using the
netloc4 data type shown below:

enum netloc_type4 {
NL4_NAME = 0,
NL4_URL = 1,
NL4_NETADDR = 2
};
union netloc4 switch (netloc_type4 nl_type) {
case NL4_NAME: utf8str_cis nl_name;
case NL4_URL: utf8str_cis nl_url;
case NL4_NETADDR: netaddr4 nl_addr;
};

If the netloc4 is of type NL4_NAME, the nl_name field MUST be
specified as a UTF-8 string. The nl_name is expected to be resolved
to a network address via DNS, LDAP, NIS, /etc/hosts, or some other
means. If the netloc4 is of type NL4_URL, a server URL [RFC3986]
appropriate for the server-to-server copy operation is specified as a
UTF-8 string. If the netloc4 is of type NL4_NETADDR, the nl_addr
field MUST contain a valid netaddr4 as defined in Section 3.3.9 of
[RFC5661].

When netloc4 values are used for an inter-server copy as shown in
Figure 3, their values may be evaluated on the source server,
destination server, and client. The network environment in which
these systems operate should be configured so that the netloc4 values
are interpreted as intended on each system.

3.3.2. Copy Offload Stateids

A server may perform a copy offload operation asynchronously. An
asynchronous copy is tracked using a copy offload stateid. Copy
offload stateids are included in the COPY, OFFLOAD_ABORT,
OFFLOAD_STATUS, and CB_OFFLOAD operations.

Section 8.2.4 of [RFC5661] specifies that stateids are valid until
either (A) the client or server restart or (B) the client returns the
resource.

A copy offload stateid will be valid until either (A) the client or
server restarts or (B) the client returns the resource by issuing a
OFFLOAD_ABORT operation or the client replies to a CB_OFFLOAD

Haynes Expires September 15, 2013 [Page 20]
Internet-Draft NFSv4.2 March 2013

operation.

A copy offload stateid" extension
requires the key schedule processing to include both the external PSK
and the (EC)DHE shared secret value.

If the client and the server have different values associated with
the selected external PSK identifier, then the client and the server
will compute different values for every entry in the key schedule,
which will lead to the client aborting the handshake with a
"decrypt_error" alert.

6. IANA Considerations

IANA is requested to update the TLS ExtensionType Registry to include
"tls_cert_with_extern_psk" with a value of TBD and the list of
messages "CH, SH" in which the "tls_cert_with_extern_psk" extension
may appear.

7. Security Considerations

The Security Considerations in [RFC8446] remain relevant.

TLS 1.3 [RFC8446] does not permit the server to send a
CertificateRequest message when a PSK is being used. This

Housley Expires May 20, 2020 [Page 7]
Internet-Draft Certificate with External PSK November 2019

restriction is removed when the "tls_cert_with_extern_psk" extension
is offered by the client and accepted by the server. However, TLS
1.3 does not permit an external PSK to be used in the same fashion as
a resumption PSK, and this extension does not alter those
restrictions. Thus, a certificate MUST NOT be used with a resumption
PSK.

Implementations must protect the external pre-shared key (PSK).
Compromise of the external PSK will make the encrypted session
content vulnerable to the future development of a large-scale quantum
computer.

Implementers should not transmit the same content on a connection
that is protected with an external PSK and a connection that is not.
Doing so may allow an eavesdropper to correlate the connections,
making the content vulnerable to the future invention of a large-
scale quantum computer.

Implementations must generate external PSKs with a secure key
management technique, such as pseudo-random generation of the key or
derivation of the key from one or more other secure keys. The use of
inadequate pseudo-random number generators (PRNGs) to generate
external PSKs can result in little or no security. An attacker may
find it much easier to reproduce the PRNG environment that produced
the external PSKs and searching the resulting small set of
possibilities, rather than brute force searching the whole key space.
The generation of quality random numbers is difficult. [RFC4086]
offers important guidance in this area.

If the external PSK is known to any party other than the client and
the server, then the external PSK MUST NOT be the sole basis for
authentication. The reasoning is explained in [K2016] (see
Section 4.2). When this extension is used, authentication is based
on certificates, not the external PSK.

In this extension, the external PSK preserves secrecy if the (EC)DH
key agreement is ever broken by cryptanalysis or the future invention
of a large-scale quantum computer. As long as the attacker does not
know the PSK and the key derivation algorithm remains unbroken, the
attacker cannot derive the session secrets even if they are able to
compute the (EC)DH shared secret.

TLS 1.3 key derivation makes use of the HKDF algorithm, which depends
upon the HMAC construction and a hash function. This extension
provides the desired protection for the session secrets as long as
HMAC with the selected hash function is a pseudorandom function (PRF)
[GGM1986].

Housley Expires May 20, 2020 [Page 8]
Internet-Draft Certificate with External PSK November 2019

In the future, if the (EC)DH key agreement is broken by cryptanalysis
or the invention of a large-scale quantum computer, the forward
secrecy advantages traditionally associated with ephemeral (EC)DH
keys will no longer be relevant. Although the ephemeral private keys
used during a given TLS session would be destroyed at the end of a
session, preventing the attacker from later accessing them, the
private keys would nevertheless be recoverable due to the break in
the algorithm. A more general notion of "secrecy after key material
is destroyed" would still be achievable using external PSKs, of
course, provided that they are managed in a way that ensures their
destruction when they are no longer needed, and with the assumption
that the algorithms that use the external PSKs remain quantum-safe.

This specification does not require that external PSK is known only
by the client and server. The external PSK may be known to a group.
Since authentication depends on the public key in a certificate,
knowledge of the external PSK by other parties does not enable
impersonation. Since confidentiality depends on the shared secret
from (EC)DH, knowledge of the external PSK by other parties does not
enable eavesdropping. However, group members can record the traffic
of other members, and then decrypt it if they ever gain access to a
large-scale quantum computer. Also, when many parties know the
external PSK, there are many opportunities for theft of the external
PSK by an attacker. Once an attacker has the external PSK, they can
decrypt stored traffic if they ever gain access to a large-scale
quantum computer in the same manner as a legitimate group member.

TLS 1.3 [RFC8446] takes a conservative approach to PSKs; they are
bound to a specific hash function and KDF. By contrast, TLS 1.2
[RFC5246] allows PSKs to be used with any hash function and the TLS
1.2 PRF. Thus, the safest approach is to use a PSK exclusively with
TLS 1.2 or exclusively with TLS 1.3. Given one PSK, one can derive a
PSK for exclusive use with TLS 1.2 and derive another PSK for
exclusive use with TLS 1.3 using the mechanism specified in
[I-D.ietf-tls-external-psk-importer].

TLS 1.3 [RFC8446] has received careful security analysis, and some
informal reasoning shows that the addition of this extension does not
introduce any security defects. This extension requires the use of
certificates for authentication, but the processing of certificates
is unchanged by this extension. This extension places an external
PSK in the key schedule as part of the computation of the Early
Secret. In the initial handshake without this extension, the Early
Secret is computed as:

Early Secret = HKDF-Extract(0, 0)

With this extension, the Early Secret is computed as:

Housley Expires May 20, 2020 [Page 9]
Internet-Draft Certificate with External PSK November 2019

Early Secret = HKDF-Extract(External PSK, 0)

Any entropy contributed by the external PSK can only make the Early
Secret better; the External PSK cannot make it worse. For these two
reasons, TLS 1.3 continues to meet its security goals when this
extension is used.

8. Privacy Considerations

Appendix E.6 of [RFC8446] discusses identity exposure attacks on
PSKs. The guidance in this section remains relevant.

This extension makes use of external PSKs to improve resilience
against attackers that gain access to a large-scale quantum computer
in the future. This extension is always accompanied by the
"pre_shared_key" extension to provide the PSK identities in plaintext
in the ClientHello message. Passive observation of the these PSK
identities will aid an attacker to track users of this extension.

9. Acknowledgments

Many thanks to Liliya Akhmetzyanova, Christian Huitema, Ben Kaduk,
Geoffrey Keating, Hugo Krawczyk, Nikos Mavrogiannopoulos, Nick
Sullivan, Martin Thomson, and Peter Yee for their review and
comments; their efforts have improved this document.

10. References

10.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.

10.2. Informative References

[DH1977] Diffie, W. and M. Hellman, "New Directions in
Cryptography", IEEE Transactions on Information
Theory V.IT-22 n.6, June 1977.

Housley Expires May 20, 2020 [Page 10]
Internet-Draft Certificate with External PSK November 2019

[FIPS186] National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", Federal Information Processing
Standards Publication (FIPS PUB) 186-4, July 2013.

[GGM1986] Goldreich, O., Goldwasser, S., and S. Micali, "How to
construct random functions", J. ACM 1986 (33), pp.
792-807, 1986.

[I-D.hoffman-c2pq]
Hoffman, P., "The Transition from Classical to Post-
Quantum Cryptography", draft-hoffman-c2pq-05 (work in
progress), May 2019.

[I-D.ietf-tls-external-psk-importer]
Benjamin, D. and C. Wood, "Importing External PSKs for
TLS", draft-ietf-tls-external-psk-importer-01 (work in
progress), October 2019.

[IEEE1363]
Institute of Electrical and Electronics Engineers, "IEEE
Standard Specifications for Public-Key Cryptography", IEEE
Std 1363-2000, 2000.

[K2016] Krawczyk, H., "A Unilateral-to-Mutual Authentication
Compiler for Key Exchange (with Applications to Client
Authentication in TLS 1.3)", IACR ePrint 2016/711, August
2016.

[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.

[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.

[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/info/rfc8017>.

Housley Expires May 20, 2020 [Page 11]
Internet-Draft Certificate with External PSK November 2019#x27;s seqid MUST NOT be 0. In the context of a
copy offload operation, it is ambiguous to indicate the most recent
copy offload operation using a stateid with seqid of 0. Therefore a
copy offload stateid with seqid of 0 MUST be considered invalid.

3.4. Security Considerations

The security considerations pertaining to NFSv4
[I-D.ietf-nfsv4-rfc3530bis] apply to this chapter.

The standard security mechanisms provide by NFSv4
[I-D.ietf-nfsv4-rfc3530bis] may be used to secure the protocol
described in this chapter.

NFSv4 clients and servers supporting the inter-server copy operations
described in this chapter are REQUIRED to implement [rpcsecgssv3],
including the RPCSEC_GSSv3 privileges copy_from_auth and
copy_to_auth. If the server-to-server copy protocol is ONC RPC
based, the servers are also REQUIRED to implement the RPCSEC_GSSv3
privilege copy_confirm_auth. These requirements to implement are not
requirements to use. NFSv4 clients and servers are RECOMMENDED to
use [rpcsecgssv3] to secure server-side copy operations.

3.4.1. Inter-Server Copy Security

3.4.1.1. Requirements for Secure Inter-Server Copy

Inter-server copy is driven by several requirements:

o The specification MUST NOT mandate an inter-server copy protocol.
There are many ways to copy data. Some will be more optimal than
others depending on the identities of the source server and
destination server. For example the source and destination
servers might be two nodes sharing a common file system format for
the source and destination file systems. Thus the source and
destination are in an ideal position to efficiently render the
image of the source file to the destination file by replicating
the file system formats at the block level. In other cases, the
source and destination might be two nodes sharing a common storage
area network, and thus there is no need to copy any data at all,
and instead ownership of the file and its contents simply gets re-
assigned to the destination.

o The specification MUST provide guidance for using NFSv4.x as a
copy protocol. For those source and destination servers willing
to use NFSv4.x there are specific security considerations that

Haynes Expires September 15, 2013 [Page 21]
Internet-Draft NFSv4.2 March 2013

this specification can and does address.

o The specification MUST NOT mandate pre-configuration between the
source and destination server. Requiring that the source and
destination first have a "copying relationship" increases the
administrative burden. However the specification MUST NOT
preclude implementations that require pre-configuration.

o The specification MUST NOT mandate a trust relationship between
the source and destination server. The NFSv4 security model
requires mutual authentication between a principal on an NFS
client and a principal on an NFS server. This model MUST continue
with the introduction of COPY.

3.4.1.2. Inter-Server Copy with RPCSEC_GSSv3

When the client sends a COPY_NOTIFY to the source server to expect
the destination to attempt to copy data from the source server, it is
expected that this copy is being done on behalf of the principal
(called the "user principal") that sent the RPC request that encloses
the COMPOUND procedure that contains the COPY_NOTIFY operation. The
user principal is identified by the RPC credentials. A mechanism
that allows the user principal to authorize the destination server to
perform the copy in a manner that lets the source server properly
authenticate the destination's copy, and without allowing the
destination to exceed its authorization is necessary.

An approach that sends delegated credentials of the client's user
principal to the destination server is not used for the following
reasons. If the client's user delegated its credentials, the
destination would authenticate as the user principal. If the
destination were using the NFSv4 protocol to perform the copy, then
the source server would authenticate the destination server as the
user principal, and the file copy would securely proceed. However,
this approach would allow the destination server to copy other files.
The user principal would have to trust the destination server to not
do so. This is counter to the requirements, and therefore is not
considered. Instead an approach using RPCSEC_GSSv3 [rpcsecgssv3]
privileges is proposed.

One of the stated applications of the proposed RPCSEC_GSSv3 protocol
is compound client host and user authentication [+ privilege
assertion]. For inter-server file copy, we require compound NFS
server host and user authentication [+ privilege assertion]. The
distinction between the two is one without meaning.

RPCSEC_GSSv3 introduces the notion of privileges. We define three
privileges:

Haynes Expires September 15, 2013 [Page 22]
Internet-Draft NFSv4.2 March 2013

copy_from_auth: A user principal is authorizing a source principal
("nfs@<source>") to allow a destination principal ("nfs@
<destination>") to copy a file from the source to the destination.
This privilege is established on the source server before the user
principal sends a COPY_NOTIFY operation to the source server.

struct copy_from_auth_priv {
secret4 cfap_shared_secret;
netloc4 cfap_destination;
/* the NFSv4 user name that the user principal maps to */
utf8str_mixed cfap_username;
/* equal to seq_num of rpc_gss_cred_vers_3_t */
unsigned int cfap_seq_num;
};

cfp_shared_secret is a secret value the user principal generates.

copy_to_auth: A user principal is authorizing a destination
principal ("nfs@<destination>") to allow it to copy a file from
the source to the destination. This privilege is established on
the destination server before the user principal sends a COPY
operation to the destination server.

struct copy_to_auth_priv {
/* equal to cfap_shared_secret */
secret4 ctap_shared_secret;
netloc4 ctap_source;
/* the NFSv4 user name that the user principal maps to */
utf8str_mixed ctap_username;
/* equal to seq_num of rpc_gss_cred_vers_3_t */
unsigned int ctap_seq_num;
};

ctap_shared_secret is a secret value the user principal generated
and was used to establish the copy_from_auth privilege with the
source principal.

copy_confirm_auth: A destination principal is confirming with the
source principal that it is authorized to copy data from the
source on behalf of the user principal. When the inter-server
copy protocol is NFSv4, or for that matter, any protocol capable
of being secured via RPCSEC_GSSv3 (i.e., any ONC RPC protocol),
this privilege is established before the file is copied from the
source to the destination.

Haynes Expires September 15, 2013 [Page 23]
Internet-Draft NFSv4.2 March 2013

struct copy_confirm_auth_priv {
/* equal to GSS_GetMIC() of cfap_shared_secret */
opaque ccap_shared_secret_mic<>;
/* the NFSv4 user name that the user principal maps to */
utf8str_mixed ccap_username;
/* equal to seq_num of rpc_gss_cred_vers_3_t */
unsigned int ccap_seq_num;
};

3.4.1.2.1. Establishing a Security Context

When the user principal wants to COPY a file between two servers, if
it has not established copy_from_auth and copy_to_auth privileges on
the servers, it establishes them:

o The user principal generates a secret it will share with the two
servers. This shared secret will be placed in the
cfap_shared_secret and ctap_shared_secret fields of the
appropriate privilege data types, copy_from_auth_priv and
copy_to_auth_priv.

o An instance of copy_from_auth_priv is filled in with the shared
secret, the destination server, and the NFSv4 user id of the user
principal. It will be sent with an RPCSEC_GSS3_CREATE procedure,
and so cfap_seq_num is set to the seq_num of the credential of the
RPCSEC_GSS3_CREATE procedure. Because cfap_shared_secret is a
secret, after XDR encoding copy_from_auth_priv, GSS_Wrap() (with
privacy) is invoked on copy_from_auth_priv. The
RPCSEC_GSS3_CREATE procedure's arguments are:

struct {
rpc_gss3_gss_binding *compound_binding;
rpc_gss3_chan_binding *chan_binding_mic;
rpc_gss3_assertion assertions<>;
rpc_gss3_extension extensions<>;
} rpc_gss3_create_args;

The string "copy_from_auth" is placed in assertions[0].privs. The
output of GSS_Wrap() is placed in extensions[0].data. The field
extensions[0].critical is set to TRUE. The source server calls
GSS_Unwrap() on the privilege, and verifies that the seq_num
matches the credential. It then verifies that the NFSv4 user id
being asserted matches the source server's mapping of the user
principal. If it does, the privilege is established on the source
server as: <"copy_from_auth", user id, destination>. The
successful reply to RPCSEC_GSS3_CREATE has:

Haynes Expires September 15, 2013 [Page 24]
Internet-Draft NFSv4.2 March 2013

struct {
opaque handle<>;
rpc_gss3_chan_binding *chan_binding_mic;
rpc_gss3_assertion granted_assertions<>;
rpc_gss3_assertion server_assertions<>;
rpc_gss3_extension extensions<>;
} rpc_gss3_create_res;

The field "handle" is the RPCSEC_GSSv3 handle that the client will
use on COPY_NOTIFY requests involving the source and destination
server. granted_assertions[0].privs will be equal to
"copy_from_auth". The server will return a GSS_Wrap() of
copy_to_auth_priv.

o An instance of copy_to_auth_priv is filled in with the shared
secret, the source server, and the NFSv4 user id. It will be sent
with an RPCSEC_GSS3_CREATE procedure, and so ctap_seq_num is set
to the seq_num of the credential of the RPCSEC_GSS3_CREATE
procedure. Because ctap_shared_secret is a secret, after XDR
encoding copy_to_auth_priv, GSS_Wrap() is invoked on
copy_to_auth_priv. The RPCSEC_GSS3_CREATE procedure's arguments
are:

struct {
rpc_gss3_gss_binding *compound_binding;
rpc_gss3_chan_binding *chan_binding_mic;
rpc_gss3_assertion assertions<>;
rpc_gss3_extension extensions<>;
} rpc_gss3_create_args;

The string "copy_to_auth" is placed in assertions[0].privs. The
output of GSS_Wrap() is placed in extensions[0].data. The field
extensions[0].critical is set to TRUE. After unwrapping,
verifying the seq_num, and the user principal to NFSv4 user ID
mapping, the destination establishes a privilege of
<"copy_to_auth", user id, source>. The successful reply to
RPCSEC_GSS3_CREATE has:

struct {
opaque handle<>;
rpc_gss3_chan_binding *chan_binding_mic;
rpc_gss3_assertion granted_assertions<>;
rpc_gss3_assertion server_assertions<>;
rpc_gss3_extension extensions<>;

Haynes Expires September 15, 2013 [Page 25]
Internet-Draft NFSv4.2 March 2013

} rpc_gss3_create_res;

The field "handle" is the RPCSEC_GSSv3 handle that the client will
use on COPY requests involving the source and destination server.
The field granted_assertions[0].privs will be equal to
"copy_to_auth". The server will return a GSS_Wrap() of
copy_to_auth_priv.

3.4.1.2.2. Starting a Secure Inter-Server Copy

When the client sends a COPY_NOTIFY request to the source server, it
uses the privileged "copy_from_auth" RPCSEC_GSSv3 handle.
cna_destination_server in COPY_NOTIFY MUST be the same as the name of
the destination server specified in copy_from_auth_priv. Otherwise,
COPY_NOTIFY will fail with NFS4ERR_ACCESS. The source server
verifies that the privilege <"copy_from_auth", user id, destination>
exists, and annotates it with the source filehandle, if the user
principal has read access to the source file, and if administrative
policies give the user principal and the NFS client read access to
the source file (i.e., if the ACCESS operation would grant read
access). Otherwise, COPY_NOTIFY will fail with NFS4ERR_ACCESS.

When the client sends a COPY request to the destination server, it
uses the privileged "copy_to_auth" RPCSEC_GSSv3 handle.
ca_source_server in COPY MUST be the same as the name of the source
server specified in copy_to_auth_priv. Otherwise, COPY will fail
with NFS4ERR_ACCESS. The destination server verifies that the
privilege <"copy_to_auth&

Author's Address

Russ Housley
Vigil Security, LLC
516 Dranesville Road
Herndon, VA 20170
USA

Email: housley@vigilsec.com

Housley Expires May 20, 2020 [Page 12]

TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key draft-ietf-tls-tls13-cert-with-extern-psk-03

TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key
draft-ietf-tls-tls13-cert-with-extern-psk-03