Subject: [nfsv4] Problem statement: FedFS ADMIN protocol document does not specify a GSSAPI service name

From: Chuck Lever <[email-masked]>
Date: Fri, 12 Apr 2013 12:42:51 -0400

Hi-

After IESG review, the Security Considerations chapter of the FedFS ADMIN protocol draft now specifically requires that implementations of this protocol support GSSAPI security mechanisms.

ADMIN protocol clients must use a service principal to establish a GSS context shared with the ADMIN server.  To construct that principal, they need to know a priori the protocol's GSSAPI service name.

This service name can be provided by a specification.  This is typical practice to ensure interoperability between independent implementations.  For NFS, RFC 2623, chapter 3.1 specifies the service name required for an NFS server that supports GSSAPI.

In general, the form of that service name is specified in RFC 2724, chapter 4.  

> Documents specifying means for GSS integration into a particular
> protocol should state either:
> 
>    (a) that a specific IANA-registered name associated with that
>    protocol shall be used for the "service" element (this admits, if
>    needed, the possibility that a single name can be registered and
>    shared among a related set of protocols), or
> 
>    (b) that the generic name "host" shall be used for the "service"
>    element, or
> 
>    (c) that, for that protocol, fallback in specified order (a, then
>    b) or (b, then a) shall be applied.
> 
> IANA registration of specific names per (a) should be handled in
> accordance with the "Specification Required" assignment policy,
> defined by BCP 26, RFC 2434 as follows: "Values and their meaning
> must be documented in an RFC or other available reference, in
> sufficient detail so that interoperability between independent
> implementations is possible."

An IANA registry exists that contains such names:

  http://www.iana.org/assignments/gssapi-service-names/gssapi-service-names.xml

Here are several naive options for addressing this issue:

1.  The FedFS ADMIN protocol always uses the server's host principal.

2.  The FedFS ADMIN protocol always uses the server's nfs principal.

3.  The FedFS ADMIN protocol specification provides a new and unique service name, and will register it with IANA.

4.  Because the FedFS ADMIN protocol specification is already in the RFC Editor's queue, a separate RFC is created to specify a new service name and register it with IANA.

5.  Because the FedFS ADMIN protocol specification is already in the RFC Editor's queue, an RFC is created specifying version 2 of the ADMIN protocol, and the service name is specified there (along with other changes, of course).

For option 3, I propose the following language, inserted after the 2nd paragraph of Chapter 6 "Security Considerations":

   Regardless of what security mechanism under RPCSEC_GSS is in use,
   a FedFS ADMIN server MUST identify itself in GSS-API via a
   GSS_C_NT_HOSTBASED_SERVICE name type.
   GSS_C_NT_HOSTBASED_SERVICE names are of the form:

        service@hostname

   For the ADMIN protocol, the "service" element is

        fedfs

   Implementations of security mechanisms will convert fedfs@hostname
   to various different forms.  For Kerberos V5, the following form is
   RECOMMENDED:

        fedfs/hostname

In addition, the ADMIN protocol draft should request an IANA action to add "fedfs" to the GSSAPI Service Name registry.  The new entry should reference the ADMIN protocol specification.

My preference is option 3.

Thoughts?  Comments?  Did I miss anything?

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

---

From: Chuck Lever <[email-masked]>
Date: Fri, 19 Apr 2013 10:25:12 -0700

Hi-

> Thoughts?  Comments?  Did I miss anything?

I received one offline comment for this one.  Another option would be to specify domain-based service authentication, but this would require deploying DNS SEC (as I read it).

Can this problem statement be considered along with the "compromised NSDB" issue?

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 26 Apr 2013 17:44:03 +0200

Hi Chuck, all,

On 04/12/2013 06:42 PM, Chuck Lever wrote:
[...]

> 3.  The FedFS ADMIN protocol specification provides a new and unique
> service name, and will register it with IANA.
>
> 4.  Because the FedFS ADMIN protocol specification is already in the
> RFC Editor's queue, a separate RFC is created to specify a new
> service name and register it with IANA.
>
> 5.  Because the FedFS ADMIN protocol specification is already in the
> RFC Editor's queue, an RFC is created specifying version 2 of the
> ADMIN protocol, and the service name is specified there (along with
> other changes, of course).
>
>
> For option 3, I propose the following language, inserted after the
> 2nd paragraph of Chapter 6 "Security Considerations":
>
> Regardless of what security mechanism under RPCSEC_GSS is in use, a
> FedFS ADMIN server MUST identify itself in GSS-API via a
> GSS_C_NT_HOSTBASED_SERVICE name type. GSS_C_NT_HOSTBASED_SERVICE
> names are of the form:
>
> service@hostname
>
> Implementations of security mechanisms will convert fedfs@hostname to
> various different forms.  For Kerberos V5, the following form is
> RECOMMENDED:
>
> fedfs/hostname
>
> In addition, the ADMIN protocol draft should request an IANA action
> to add "fedfs" to the GSSAPI Service Name registry.  The new entry
> should reference the ADMIN protocol specification.
>

Option 3 doesn't formally work anymore, as the fedfs drafts are now with 
the RFC editor.

Option 4 or 5 would work.

   Martin

-- 
[email-masked]

NEC Laboratories Europe
NEC Europe Limited
Registered Office:
Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB
Registered in England 2832014

---

From: Chuck Lever <[email-masked]>
Date: Fri, 26 Apr 2013 11:51:54 -0400

On Apr 26, 2013, at 11:44 AM, Martin Stiemerling <[email-masked]> wrote:

> Option 3 doesn't formally work anymore, as the fedfs drafts are now with the RFC editor.
> 

Until we embark on one of those options, can we agree as a community that our GSSAPI-enabled ADMIN protocol implementations will use "fedfs@hostname" by convention as the service principal?

---

From: Nico Williams <[email-masked]>
Date: Fri, 26 Apr 2013 11:34:50 -0500

> Until we embark on one of those options, can we agree as a community that our GSSAPI-enabled ADMIN protocol implementations will use "fedfs@hostname" by convention as the service principal?

Yes.  Is there an IANA port number and service name registered for
this protocol?

Nico
--

---

From: Chuck Lever <[email-masked]>
Date: Fri, 26 Apr 2013 12:38:33 -0400

> Yes.  Is there an IANA port number and service name registered for

An RPC program number is registered: "fedfs_admin"

  http://www.iana.org/assignments/rpc-program-numbers/rpc-program-numbers.xml

---

From: Nico Williams <[email-masked]>
Date: Fri, 26 Apr 2013 11:53:57 -0500

> An RPC program number is registered: "fedfs_admin"

Sometimes I wish that the GSS-API service name registry matched up
better with the IANA port registry, which is why I ask.  But fedfs
will do.  If you think that in the future there might be more fedfs
protocols where we need a service name and we'd want to distinguish
admin from !admin, then I think fedfs_admin would be better.

---

From: Chuck Lever <[email-masked]>
Date: Fri, 26 Apr 2013 13:38:21 -0400

> admin from !admin, then I think fedfs_admin would be better.

Something to consider is how a FEDFS_SEC_SASLGSSAPI NSDB connection security mode might work.

Can/should we use the same service principal for mutual authentication between fileservers and LDAP (NSDB) servers?  In that case, "fedfs@hostname" might be better?

---

From: Nico Williams <[email-masked]>
Date: Fri, 26 Apr 2013 13:53:37 -0500

> Can/should we use the same service principal for mutual authentication between fileservers and LDAP (NSDB) servers?  In that case, "fedfs@hostname" might be better?

Or even nfs@hostname.

There is one thing to keep in mind when sharing principals this way.
Kerberos is a one-round trip protocol that needs a replay cache, but
as it is used in RPCSEC_GSS the replay cache is not needed[*] because
the client always sends something first after establishing the
context, such that the client's first per-message token (MIC or wrap)
can act as a challenge confirmation that then obviates the need for a
replay cache.  You'd not want to share a service name between services
that have this "feature" and ones that don't, because then you lose
the ability to not have a replay cache for those that have this
feature.

[*] To be accurate, for Kerberos, this only happens when using RFC4121
with "newer" enctypes, meaning AES and Camellia, but not 1DES nor 3DES
(I don't recall the situation for RC4).

Nico
--