One document matched: draft-williams-rpcsecgssv3-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml' -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc1831 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1831.xml'>
<!ENTITY rfc2743 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2743.xml'>
<!ENTITY rfc2203 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2203.xml'>
<!ENTITY rfc3530 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3530.xml'>
<!ENTITY rfc4506 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4506.xml'>
<!ENTITY rfc5056 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5056.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc tocindent="no" ?>
<?rfc autobreaks="no" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="no"?>
<rfc ipr="trust200811" category="std" docName="draft-williams-rpcsecgssv3-00.txt">
<front>
<title abbrev="RPCSEC_GSSv3">Remote Procedure Call (RPC) Security Version 3</title>
<author initials='N.' surname="Williams" fullname='Nicolas
Williams'>
<organization abbrev="Sun">Sun Microsystems</organization>
<address>
<postal>
<street>5300 Riata Trace Ct</street>
<city>Austin</city> <region>TX</region>
<code>78727</code> <country>US</country>
</postal>
<email>Nicolas.Williams@sun.com</email>
</address>
</author>
<date month="January" year="2009"/>
<area>Security</area>
<workgroup>NETWORK WORKING GROUP</workgroup>
<keyword>Internet-Draft</keyword>
<abstract><t>This document specifies version 3 of the Remote
Procedure Call (RPC) security protocol (RPCSEC_GSS).
This protocol provides for: compound authentication of
client hosts and users to server (constructed by generic
composition), channel binding, security label assertions
for multi-level and type enforcement, privilege
assertions and identity assertions.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The original RPCSEC_GSS protocol <xref target="RFC2203"/>
provided for authentication of RPC clients and servers
to each other using the Generic Security Services
Application Programming Interface (GSS-API) <xref
target="RFC2743"/>. The second version of
RPCSEC_GSS [add ref.] added support for channel binding
<xref target="RFC5056"/>.</t>
<t>We find that GSS-API mechanisms are insufficient for
communicating certain aspects of a client's identity and
authority to a server. The GSS-API and its mechanisms
certainly could be extended to address this
shortcomming, but it seems be far simpler to address it
at the application layer, namely, in this case,
RPCSEC_GSS.</t>
<t>We therefore provide a new version of RPCSEC_GSS that
allows for the following:
<list style="symbols">
<t>compound authentication of the client host and
user to the server (done by binding of two
RPCSEC_GSS handles)</t>
<t>channel binding (even though RPCSEC_GSSv2
provides this also; see below)</t>
<t>client-side assertions of authority:
<list style="symbols">
<t>security labels (for multi-level, type
enforcement, and other labeled security
models) [add refs. for labeled
security]</t>
<t>application-specific privileges</t>
</list>
</t>
<t>client-side assertions of identity:
<list style="symbols">
<t>primary client/user identity</t>
<t>supplementary group memberships of the
client/user, including support for
specifying deltas to the membership list
as seen on the server</t>
</list>
</t>
</list>
</t>
<t>Assertions of labels, privilege and identity are
evaluated by the server, which may then map the asserted
values to other values, all according to server-side
policy.</t>
<t>We also add an option for enumerating server-side domains
of interpretation (DOI), though this seems likely to be
unnecessary.</t>
<t>RPCSEC_GSSv3 is patterned as follows:
<list style="symbols">
<t>a client uses an existing RPCSEC_GSS context
handle (of any RPCSEC_GSS version) to protect
RPCSEC_GSSv3 exchanges (this will be termed the
"parent" or "outer" handle)</t>
<t>the server issues a "child" RPCSEC_GSSv3 handle,
but the underlying GSS-API security context for
the parent handle is used in all subsequent
exchanges using the child handle (this works
because the RPCSEC_GSS handle is included in the
integrity protected RPCSEC_GSS auth/verifier
header for all versions of RPCSEC_GSS)</t>
</list>
<vspace blankLines='1'/>
This means that RPCSEC_GSSv3 depends on RPCSEC_GSS
versions 1 and/or 2 for actual GSS-API security context
establishment. This keeps the specification of
RPCSEC_GSSv3 simple by avoiding the need to duplicate
the core functionality of RPCSEC_GSS version 1.</t>
<section title="Motivation">
<t>The initial motivation for RPCSEC_GSSv3 is to add
support for labeled security. Several alternatives
to revising RPCSEC_GSS were considered:
<list style='letters'>
<t>application-level protocol extensions, such
as new operations for the Network File
System version 4 (NFSv4)
protocol <xref target="RFC3530"/>;</t>
<t>a stackable GSS-API pseudo-mechanism that
could be composed with concrete GSS-API
mechanisms to provide both, authentication
and protected security label assertions;</t>
<t>per-GSS-API mechanism extensions for
transporting security label assertions;</t>
</list>
</t>
<t>Alternative (c) is not sufficiently general. One
possible benefit of (c) might be the ability to have
per-{user, label} credentials, though that might be
difficult to manage (and, anyways, can be emulated
with regular GSS-API mechanisms through principal
naming conventions), whereas with the other
approaches there is a single credential per-user
that can be used to assert multiple security
labels.</t>
<t>Alternative (a) is not general either, though for the
purpose of the NFSv4 community it would suffice.
However, a solution at the RPCSEC_GSS or GSS-API
layers does, or arguably should, fit more naturally
into most, if not all, NFSv4 implementations.</t>
<t>Alternative (b) is certainly general enough. In
fact, it is more general than the RPCSEC_GSSv3
solution in that it could be used in non-RPC
protocols that support the use of the GSS-API.
However, the RPCSEC_GSSv3 approach is attractively
simple. For example, to pursue (b) would likely
entail having to specify a framework for mechanism
composition, as well as GSS-API interfaces to access
assertions that would typically be very
platform-specific. (The KITTEN WG has explored
stackable pseudo-mechanisms in the past, but that
work is currently stagnant.) It is possible that
stackable pseudo-mechanisms may materialize in the
future; such mechanisms would be usable through all
versions of RPCSEC_GSS so far.</t>
<t>As we considered these alternatives we also realized
that we needed other features that could all be
packed into a single solution. For example, the
assertion of security label is conceptually
equivalent, protocol-wise, to assertions of
privilege and identity.</t>
<t>Additionally, assertions need to be verified, and in
this case the one party that can verify an assertion
is the client host, which can authenticate to the
server using its own credentials. Yet we want to
continue authenticating users as well. This calls
for compound authentication.</t>
<t>Finally, because the design of RPCSEC_GSSv3 relies on
RPCSEC_GSSv1 (though v2 can also be used) to do the
actual GSS-API security context establishment, we
add support for channel binding so that implementors
who have implemented RPCSEC_GSSv1 but not version 2
can still provide channel binding without having to
implement version 2. Channel binding is
accomplished in a more simple manner in v3 also.</t>
</section>
<section title="Applications of RPCSEC_GSSv3">
<t>The common uses of RPCSEC_GSSv3, particularly for
NFSv4, are expected to be:
<list style='letters'>
<t>labeled security: client-side process label
assertion [+ privilege assertion] +
compound client host & user
authentication;</t>
<t>compound client host & user
authentication [+ privilege assertion];</t>
<t>client-side process credentials assertion [+
privilege assertion] as a replacement for
AUTH_SYS that is more secure than AUTH_SYS
while not requiring per-user credentials</t>
</list>
</t>
</section>
<section title="Conventions used in this document">
<t>The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/>.</t>
</section>
</section>
<section anchor="v3" title="The RPCSEC_GSSv3 protocol">
<t>The following External Data Representation (XDR) <xref
target="RFC4506"/> definitions are used:
</t>
<figure>
<artwork>
<![CDATA[
#define RPCSEC_GSS_VERS_3 3
enum rpc_gss3_proc_t {
RPCSEC_GSS3_DATA = 0,
RPCSEC_GSS3_LIST = 1,
RPCSEC_GSS3_CREATE = 2,
RPCSEC_GSS3_DESTROY = 3
};
struct {
rpc_gss3_proc_t gss_proc;
unsigned int seq_num;
rpc_gss_service_t service;
unsigned int handle_version;
opaque handle<>;
} rpc_gss_cred_vers_3_t;
struct {
int type;
bool critical;
opaque data<>;
} rpc_gss3_extension;
struct {
unsigned int version;
opaque handle<>;
opaque nonce<>;
opaque mic<>;
} rpc_gss3_gss_binding;
typedef opaque rpc_gss3_chan_binding<>;
typedef opaque rpc_gss3_doi<>;
struct {
rpc_gss3_doi doi;
opaque label<>;
} rpc_gss3_label;
typedef opaque rpc_gss3_privs<>;
typedef opaque rpc_gss3_name<>;
struct {
rpc_gss3_name *username;
rpc_gss3_name *groups<>;
rpc_gss3_name *groups_add<>;
rpc_gss3_name *groups_remove<>;
} rpc_gss3_id;
enum rpc_gss3_assertion_type {
LABEL = 0,
PRIVS = 1,
IDENTITY = 2
};
union switch (rpc_gss3_assertion_type atype) {
case LABEL:
rpc_gss3_label label;
case PRIVILEGES:
rpc_gss3_privs privs;
case IDENTITY:
rpc_gss3_id id;
default:
opaque ext<>;
} rpc_gss3_assertion_u;
struct rpc_gss3_assertion {
bool critical;
rpc_gss3_assertion_u assertion;
};
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;
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;
enum rpc_gss3_list_item {
DOI = 0,
PRIV = 1,
PRIV_GROUP = 2
};
struct {
rpc_gss3_list_item list_what<>;
} rpc_gss3_list_args;
union switch (rpc_gss3_list_item itype) {
case DOI:
rpc_gss3_doi dois<>;
case PRIV:
string privs;
case PRIV_GROUP:
string priv_groups;
default:
opaque ext<>;
} rpc_gss3_list_item_u;
typedef rpc_gss3_list_item_u rpc_gss3_list_res<>;
]]>
</artwork>
</figure>
<t>The rpc_gss_cred_vers_3_t type is used in much the same
way that rpc_gss_cred_vers_1_t is used in
RPCSEC_GSSv1, that is: as the arm of the rpc_gss_cred_t
discriminated union corresponding to version 3
(RPCSEC_GSS_VERS_3). It differs from
rpc_gss_cred_vers_1_t in that: a) the values for
gss_proc corresponding to control messages are
different, b) the presence of a field indicating the
version of RPCSEC_GSS used to established the context
handle used, if any.</t>
<t>RPC data messages using RPCSEC_GSSv3 context handles
differ from RPCSEC_GSSv1 only in that the version number
used MUST be '3' instead of '1' and, as described above,
in that there is one more field in the RPCSEC_GSS header
to name the version of RPCSEC_GSS used to establish the
context handle used to protect this message. All other
protocol elements from RPCSEC_GSSv1-protected RPC data
messages MUST remain the same in v3 as in v1.</t>
<t>RPCSEC_GSSv3 control messages are the same as
RPCSEC_GSSv3 data messages, but with a gss_proc value
that indicates a control message is contained in the
data payload.</t>
<section title="Control messages">
<t>There are two RPCSEC_GSSv3 control messages:
RPCSEC_GSS3_CREATE and RPCSEC_GSS3_LIST.</t>
<t>The client MUST use one of the following security
services to protect any RPCSEC_GSSv3 control
message:
<list style="symbols">
<t>rpc_gss_svc_channel_prot (see RPCSEC_GSSv2)</t>
<t>rpc_gss_svc_integrity</t>
<t>rpc_gss_svc_privacy</t>
</list>
<vspace blankLines='1'/>
Specifically the client MUST NOT use
rpc_gss_svc_none.</t>
<section title="New auth_stat values">
<t>RPCSEC_GSSv3 requires the addition of several
values to the auth_stat enumerated type
definition:</t>
<figure>
<artwork>
<![CDATA[
enum auth_stat {
...
/*
* RPCSEC_GSS errors
*/
RPCSEC_GSS3_COMPOUND_PROBEM = <TBD>,
RPCSEC_GSS3_LABEL_PROBLEM = <TBD>,
RPCSEC_GSS3_IDENTITY_PROBLEM = <TBD>
RPCSEC_GSS3_UNKNOWN_ASSERTION = <TBD>
RPCSEC_GSS3_UNKNOWN_EXTENSION = <TBD>
RPCSEC_GSS3_UNKNOWN_MESSAGE = <TBD>
};
]]>
</artwork>
</figure>
</section>
<section title="Create request">
<t>The RPCSEC_GSS3_CREATE call message consists of
inputs to bind into a new RPCSEC_GSSv3 handle.
The context handle used to protect the
RPCSEC_GSS3_CREATE call message is termed the
"parent" (or "outer") handle. The reply to this
message consists of either an error or a new
RPCSEC_GSSv3 handle, termed the "child"
handle.</t>
<t>All uses of a child context handle MUST use the
GSS-API security context associated with the
parent context handle of the RPCSEC_GSS3_CREATE
request that produced the child context handle.
The child context, however, has its own sequence
number space and window, distinct from that of
the parent.</t>
<t>As described in the introduction, the
RPCSEC_GSS3_CREATE call message binds one or
more items of several kinds into a new
RPCSEC_GSSv3 context handle:
<list style="symbols">
<t>another RPCSEC_GSS (version 1, 2, or 3)
context handle</t>
<t>a channel binding</t>
<t>authorization assertions (label,
privileges)</t>
<t>identity assertions</t>
</list>
</t>
<t>Servers MUST either ignore, reject or apply
policy to the authorization and identity
assertions. Policies should take into account
the identity of the client and/or user as
authenticated via the GSS-API. Server
implementation and policy MAY result in labels,
privileges and identities being mapped to
concepts and values that are local to the
server.</t>
<section title="Compound authentication">
<t>RPCSEC_GSSv3 allows for compound
authentication of client hosts and users to
servers. This is done by using an integrity
protected RPCSEC_GSSv3 message of
RPCSEC_GSS3_CREATE type which includes a
reference to the context handle to bind, a
nonce and a MIC of that nonce using the
GSS-API security context associated with the
named context handle. We'll term the two
context handles "parent" (or "outer") and
"inner," and the resulting context handle
the "child" handle, where the outer context
handle is the context handle providing
integrity protection to the
RPCSEC_GSS3_CREATE message, and the inner
context handle is the one referenced via the
compound_binding field of the
RPCSEC_GSS3_CREATE arguments structure
(rpc_gss3_create_args).</t>
<t>All uses of a child context handle that is
bound to an inner context MUST be treated as
speaking for the initiator principal (as
modified by any assertions in the
RPCSEC_GSS3_CREATE message) of the inner
context handle's GSS-API security
context.</t>
<t>This feature is needed, for example, when a
client wishes to use authority assertions
that the server may only grant if a user and
a client are authenticated together to the
server. Thus a server may refuse to grant
requested authority to a user acting alone
(e.g., via an unprivileged user-space
program), but may grant requested authority
to a client acting on behalf of a user if
the server trusts the client.</t>
<t>It is assumed that an unprivileged user-space
program would not have access to client host
credentials needed to establish a GSS-API
security context authenticating the client
to the server, therefore an unprivileged
user-space program could not create an
RPCSEC_GSSv3 RPCSEC_GSS3_CREATE message that
successfully binds a client and a user
security context.</t>
<t>Clients using RPCSEC_GSS context binding MUST
use, as the outer context handle, an
RPCSEC_GSS context handle that corresponds
to a GSS-API security context that
authenticates the client host, and for the
inner context handle it SHOULD use a context
handle to authenticates a user. The reverse
(outer handle authenticates user, inner
authenticates client) MUST NOT be used.
Other compounds might eventually make
sense.</t>
<t>An RPCSEC_GSSv3 context handle that is bound
to another RPCSEC_GSS context MUST be
treated by servers as authenticating the
GSS-API initiator principal authenticated by
the inner context handle's GSS-API security
context. This principal may be mapped to a
server-side notion of user or principal as
modified by any identity assertions by the
client in the same RPCSEC_GSS3_CREATE
request that the server accepts.</t>
</section>
<section title="Channel binding">
<t>RPCSEC_GSSv3 provides a different way to do
channel binding that RPCSEC_GSSv2.
Specifically: a) RPCSEC_GSSv3 builds on
RPCSEC_GSSv1 by reusing existing,
established context handles rather than
providing a different RPC security flavor
for establishing context handles, b) channel
bindings data are not hashed because the
community now agrees that it is the secure
channel's responsibility to produce channel
bindings data of manageable size. (a) is
useful in keeping RPCSEC_GSSv3 simple in
general, not just for channel binding. (b)
is useful in keeping RPCSEC_GSSv3 simple
specifically for channel binding.</t>
<t>Channel binding is accomplished as follows.
The client prefixes the channel bindings
data octet string with the channel type as
described in <xref target="RFC5056"/>, then
the client calls GSS_GetMIC() to get a MIC
of resulting octet string, using the outer
RPCSEC_GSS context handle's GSS-API security
context. The MIC is then placed in the
chan_binding_mic field of RPCSEC_GSS3_CREATE
arguments (rpc_gss3_create_args).</t>
<t>If the chan_binding_mic field of the
arguments of a RPCSEC_GSS3_CREATE control
message is set, then the server MUST verify
the client's channel binding MIC if the
server supports this feature. If channel
binding verification succeeds then the
server MUST generate a new MIC of the same
channel bindings and place it in the
chan_binding_mic field of the
RPCSEC_GSS3_CREATE results. If channel
binding verification fails or the server
doesn't support channel binding then the
server MUST indicate this in its reply by
not including a chan_binding_mic value
(chan_binding_mic is an optional field).</t>
<t>The client MUST verify the result's
chan_binding_mic value, if the server
included it, by calling GSS_VerifyMIC() with
the given MIC and the channel bindings data
(including the channel type prefix). If
client-side channel binding verification
fails then the client MUST call
RPCSEC_GSS3_DESTROY. If the client
requested channel binding but the server did
not include a chan_binding_mic field in the
results, then the client MAY continue to use
the resulting context handle as though
channel binding had never been requested,
otherwise (if the client really wanted
channel binding) it MUST call
RPCSEC_GSS3_DESTROY.</t>
<t>As per-RPCSEC_GSSv2:
<list style='symbols'>
<t>"Once a successful [channel binding]
procedure has been performed on an
[RPCSEC_GSSv3] context handle, the
initiator's implementation may map
application requests for
rpc_gss_svc_none and
rpc_gss_svc_integrity to
rpc_gss_svc_channel_prot
credentials. And if the secure
channel has privacy enabled,
requests for rpc_gss_svc_privacy can
also be mapped to
rpc_gss_svc_channel_prot."</t>
<t>...</t>
</list>
</t>
<t>Any RPCSEC_GSSv3 context handle that has been
bound to a secure channel in this way SHOULD
be used only with the
rpc_gss_svc_channel_prot, and SHOULD NOT be
used with rpc_gss_svc_none nor
rpc_gss_svc_integrity -- if the secure
channel does not provide privacy protection
then the client MAY use rpc_gss_svc_privacy
where privacy protection is needed or
desired.</t>
</section>
<section title="Label assertions">
<t>RPCSEC_GSSv3 clients MAY assert a security
label in some DOI by binding this assertion
into an RPCSEC_GSSv3 context handle. This
is done by including an assertion of type
rpc_gss3_label in the 'assertions' field
(discriminant: 'LABEL') of the
RPCSEC_GSS3_CREATE arguments to the desired
DOI and label.</t>
<t>Label encoding is specific to each DOI and
not described herein. DOI encoding is
<TBD> [fill in... Solaris uses
integers to name DOIs, and there is an IANA
registry of DOIs as 32-bit integers, and
IPsec (whence the IANA registry) and CALIPSO
use 32-bit integers for DOIs as well. So a
32-bit unsinged integer seems to be the way
to go. Add references... -Nico]</t>
<t>If a label itself requires privacy protection
(i.e., that the user can assert that label
is a secret) then the client MUST use the
rpc_gss_svc_privacy protection service for
the RPCSEC_GSS3_CREATE request or, if the
parent handle is bound to a secure channel
that provides privacy protection,
rpc_gss_svc_channel_prot.</t>
<t>If a client wants to ensure that the server
understands the asserted label then it MUST
set the 'critical' field of the label
assertion to TRUE, otherwise it MUST set it
to FALSE.</t>
<t>Servers that don't support labeling MUST
ignore non-critical label assertions.
Servers that don't support the requested DOI
MUST either ignore non-critical label
assertions or map them to a suitable label
in a supported DOI. Servers that don't
support labeling or don't support the
requested DOI MUST return an error if the
label request is critical. Servers that
support labeling in the requested DOI MAY
map the requested label to different label
as a result of server-side policy
evaluation.</t>
</section>
<section title="Privilege assertions">
<t>Privilege assertions are similar to label
assertions, except that there is no DOI, and
the privileges supported are specified by
the RPC application.</t>
<t>Privileges are encoded US-ASCII strings
containing comma-separated privilege names,
as well as up to one privilege group name
and zero or more exclusions, where each
exclusion is a privilege name or privilege
group name prefixed with an exclamation
point. Two special privilege group names
are defined hereing: "all" (which represents
all possible privileges) and "basic" (which
represents privileges normally granted to
all users).</t>
<t>RPC applications that wish to use this
facility must define the set of known
privileges, and must specify which
privileges are in the "basic" privilege
group. For example, NFSv4 might specify
privileges for reading, writing, chowning,
linking, etcetera.</t>
</section>
<section title="Identity assertions">
<t>Identity assertions can be used either to
modify the set of groups assigned on the
server-side to a given user (authenticated
by the GSS-API) or to implement an
AUTH_SYS-like <xref target="RFC1831"/>. In
the latter case the client specifies at
least a user-name and possibly groups that
it thinks the user belongs to.</t>
<t>Clients may set a username, a group list,
and/or lists of groups to be added or
removed from the group list that the server
would normally use for the given user.</t>
<t>The server MUST decide whether to accept
identity assertions by applying local
policy. Such policies is not described
herein. Example policies:
<list style='symbols'>
<t>"always accept identity
assertions"</t>
<t>"always accept identity assertions where
the identities are understood"</t>
<t>"accept identity assertions ... only
from trusted clients" (where the
identity of the client is taken from
the initiator principal of the outer
context handle's GSS-API security
context, or from the network address
of the client...)</t>
<t>"accept identity assertions ... only
from trusted clients where IPsec
policy protects this application's
packet flows between the clients and
this server"</t>
<t>"accept only removals of groups from a
user's group membership list as
determined by the server"</t>
<t>"never accept identity
assertions"</t>
<t>etcetera</t>
</list>
</t>
<t>Clients may mark an identity assertion as
being critical, in which case the server
MUST respond with an error if the server
does not accept the identity assertion
as-is.</t>
<t>The representation of users and groups is not
given here, but is left to the application.
It is expected that RPCSEC_GSSv3 identity
assertions in the context of the NFSv4
application would consist of NFSv4 user and
group representations as used on the wire in
NFSv4 access control lists (ACLs).</t>
</section>
<section title="Server assertions">
<t>Servers MAY inform clients of assertions were
granted by setting the 'granted_assertions'
field of the RPCSEC_GSS3_CREATE reply.</t>
<t>The protocol provides a field
('server_assertions') for servers to make
assertions about themselves. At this time
there is not much use for this field, though
servers MAY assert a single security label,
indicating that all contents on the server
is at that label. The client MUST, of
course, either evaluate or ignore any
server-side assertions.</t>
</section>
</section>
<section title="Context handle destruction">
<t>The RPCSEC_GSS3_DESTROY procedure is the same as
for RPCSEC_GSSv1, but with the version 3
header.</t>
</section>
<section title="List request">
<t>The RPCSEC_GSS3_LIST call message consists of a
single integer indicating what should be listed,
and the reply consists of an error or the
requested list.</t>
<t>The client may list DOIs, privilege names, or
privilege group names.</t>
<t>The result is an opaque octet string containing a
list of DOIs [encoding <TBD>] or a
US-ASCII string containing a comma-separated
list of privilege names or privilege group
names.</t>
</section>
<section title="Extensibility">
<t>Assertion types may be added in the future by
adding arms to the 'rpc_gss3_assertion_u' union.
Every assertion has a 'critical' flag that can
be used to indicate criticality.</t>
<t>New fields may be added through the 'extensions'
typed hole. All such extensions have a
'critical' flag.</t>
<t>New message types may be added.</t>
<t>Clients receiving unknown critical server
assertions MUST destroy the established
RPCSEC_GSSv3 context handle. Servers receiving
unknown critical client assertions or unknown
RPCSEC_GSS_v3 extensions MUST return an
error.</t>
<t>There is no IANA or other registry for
RPCSEC_GSSv3 extensions. All extensions MUST be
done by IETF Protocol Action.</t>
</section>
</section>
</section>
<section title="Privileges and identity representation for
NFSv4">
<t>The representation of users and groups for use in
identity assertions in RPCSEC_GSSv3 SHALL be the same as
the user and group representations used by NFSv4 for
access control list subjects on the wire, cast as an
octet string ("opaque").</t>
<t>The following privileges are defined for use with the
NFSv4 protocol:
<list style='hanging'>
<t hangText="file_chown">Generally allows the caller
to change a file's owner regardless of who owns
the file.</t>
<t hangText="file_chown_self">Generally allows the
caller to change the owner of a file it
owns.</t>
<t hangText="file_dac_execute">Generally allows the
caller to read any file for execution.</t>
<t hangText="file_dac_read">Generally allows the
caller to read any file or directory.</t>
<t hangText="file_dac_search">Generally allows the
caller to search any directory.</t>
<t hangText="file_dac_write">Generally allows the
caller to write to any file (or
create/delete/link objects in directories).</t>
<t hangText="file_link_any">Generally allows the
caller to create hardlinks to files not owned by
the caller.</t>
<t hangText="file_owner">Generally allows the caller
to modify the access, modification and other
timestamps of a filesystem object, as well as
its permissions and ACL.</t>
<t hangText="file_setid">Generally allows the caller
to set the set-user-ID and set-group-ID bits of
a file.</t>
<t hangText="file_downgrade_sl">Generally allows the
caller to downgrade the security label of a
filesystem object.</t>
<t hangText="file_update_sl">Generally allows the
caller to upgrade the security label of a
filesystem object.</t>
</list>
</t>
<t>[What about NFSv3? The representation of privs would be
the same for v3 as for v4, though there'd be no privs
for dealing with labels (file_downgrade_sl and
file_update_sl). And the representation of users/groups
would NFSv3's representation thereof. But should we
bother to specify this? -Nico]</t>
<t>[Also, this is derived from Solaris' notion of
privileges. We should look at how well this scheme
relates to other operating systems as NFSv4 clients and
servers. -Nico]</t>
<t>The contents of the 'basic' privilege set is not defined
herein. Note that 'file_link_any' and 'file_chown_self'
may be present in the server's notion of the basic
privilege set.</t>
<t>The NFSv4-specific privileges may be limited by the
server in ways not specified above. For example, the
server may deny access for certain operations that would
normally be granted given the granted assertion of a
given privilege (e.g., "no one may write to files owned
by such and such user"), or the server may require that
all privileges be asserted (and granted, of course) in
order to allow certain operations (e.g., "all privileges
are required in order to write to files owned by such
and such user, not just file_dac_write").</t>
</section>
<section title="Security Considerations">
<t>This entire document deals with security issues.</t>
<t>The RPCSEC_GSSv3 protocol allows for client-side
assertions of data that is relevant to server-side
authorization decisions. These assertions must be
evaludated by the server in the context of whether the
client and/or user are authenticated, whether
compound authentication was used, whether the client is
trusted, what ranges of assertions are allowed for the
client and the user (separately or together), and any
relevant server-side policy.</t>
<t>The security semantics of assertions carried by
RPCSEC_GSSv3 are application protocol-specific.</t>
<t>RPCSEC_GSSv3 supports a notion of critical assertions
(and extensions), but there's no need for peers to tell
each other what assertions were granted, or what they
were mapped to.</t>
<t>Note that RPSEC_GSSv3 is not a complete solution for
labeling: it conveys the labels of actors, but not the
labels of objects. RPC application protocols may
require extending in order to carry object label
information.</t>
<t>The RPCSEC_GSSv3 protocol also provides for a replacement
of the old AUTH_SYS RPC authentication flavor. AUTH_SYS
relies on "privileged port numbers" for
"authentication," and was quite limited in what
assertions it supported and incompatible with NFSv4
representations of identity. To replace AUTH_SYS with
RPCSEC_GSSv3 simply use a GSS-API mechanism to
authenticate the client (but not the user) and let the
client assert the user's identity. This is more secure
than AUTH_SYS in that at least the client can be
strongly authenticated using GSS-API mechanisms, and it
is more functional than AUTH_SYS in that identity
representations are defined by the application
layer.</t>
<t>It is possible that a GSS-API mechanism that does not
provide any security services could be created so as to
make it possible to replace AUTH_SYS with RPCSEC_GSSv3
while retaining the same privileged port semantics.
Such a mechanism is out of scope for this document and
would have its own security considerations.</t>
<t>There may be interactions with NFSv4's callback security
scheme and NFSv4.1's GSS-API "SSV" mechanisms.
Specifically, the NFSv4 callback scheme requires that
the server initiate GSS-API security contexts, which
does not work well in practice, and in the context of
client-side processes running as the same user but with
different privileges and security labels the NFSv4
callback security scheme seems particularly unlikely to
work well. NFSv4.1 has the server use an existing,
client-initiated RPCSEC_GSS context handle to protect
server-initiated callback RPCs. The NFSv4.1 callback
security scheme lacks all the problems of the NFSv4
scheme, however, it is important that the server pick an
appropriate RPCSEC_GSS context handle to protect any
callbacks. Specifically, it is important that the
server use RPCSEC_GSS context handles which authenticate
the client to protect any callbacks relating to server
state initiated by RPCs protected by RPCSEC_GSSv3
contexts. [Add text about interaction with
GSS-SSV...]</t>
<t>[Anything else?]</t>
</section>
<section title="IANA Considerations">
<t>There are no IANA considerations in this document.</t>
<t>TBDs in this document will be assigned by the ONC RPC
registrart (which is not IANA, as I recall).</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;&rfc1831;&rfc2203;&rfc2743;&rfc3530;&rfc4506;&rfc5056;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:55:20 |