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

From: Chuck Lever <[email-masked]>
Date: Mon, 3 Jun 2013 15:54:40 -0400

Summarizing comments:

  o  Domain-based service names (RFC 5178) were considered, but
     because they would require DNSSEC, were rejected

  o  It was suggested that the service name should match the
     IANA-assigned port name: "fedfs_admin"

  o  The service name SHOULD NOT be used to authenticate other
     services (such as a putative FEDFS_SEC_SASLGSSAPI mode)

  o  The Area Director prefers options 4 or 5 below over options
     1, 2 or 3

  o  Barring a fresh RFC document, we as a community can adopt
     the convention of using a particular service name for
     authenticating the FedFS ADMIN protocol

According to [RFC2743], requesting an addition to the "GSSAPI/Kerberos/SASL Service Names" registry requires a specification.  [RFC2743] limits GSSAPI service names to contain alphanumeric characters and the characters '+', '-', and '.'

A very brief RFC document that contains the following text can be submitted once the FedFS ADMIN protocol document has been assigned an RFC number.  Or, we can fold this into a larger ADMINv2 document depending on the outcome of the "Compromised NSDB" discussion.

  Section 6 of [RFC-FEDFS-ADMIN-PROTOCOL] requires a FedFS ADMIN
  server to support the RPCSEC_GSS framework [RFC2203].  This
  document specifies the GSS-API service name, as described in
  Section 4.1 of [RFC2743], to be used for the FedFS ADMIN protocol.

  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-admin

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

       fedfs-admin/hostname

  This service name SHOULD NOT be used to authenticate other GSS-API
  services.

  IANA Considerations

  In accordance with Section 4.1 of [RFC2743], the service name
  "fedfs-admin" will be registered in the GSSAPI Service Name
  registry at

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

  The new entry should reference the present document as the
  specification.

  Normative References

  [RFC2119]
  [RFC2203]
  [RFC2743]
  [RFC-FEDFS-ADMIN-PROTOCOL]

On Apr 12, 2013, at 12:42 PM, Chuck Lever <[email-masked]> wrote:

> 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: Nico Williams <[email-masked]>
Date: Mon, 3 Jun 2013 15:23:05 -0500

>      because they would require DNSSEC, were rejected

Domain-based naming doesn't require DNSSEC.  Or have I forgotten
something specific to ADMIN?

The bigger problem here is that the traditional RPCSEC_GSS API from
Solaris is lame and requires the use of hostbased service names.

> According to [RFC2743], requesting an addition to the "GSSAPI/Kerberos/SASL Service Names" registry requires a specification.  [RFC2743] limits GSSAPI service names to contain alphanumeric characte…

This should probably be relaxed to expert review.

Nico
--