idnits 2.17.1 draft-cel-nfsv4-federated-fs-security-addendum-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 2, 2016) is 2915 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network File System Version 4 C. Lever 3 Internet-Draft Oracle 4 Intended status: Standards Track May 2, 2016 5 Expires: November 3, 2016 7 Federated Filesystem Security Addendum 8 draft-cel-nfsv4-federated-fs-security-addendum-05 10 Abstract 12 This document addresses critical security-related items that are 13 missing from existing FedFS Proposed Standards. 15 Requirements Language 17 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 18 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 19 document are to be interpreted as described in [RFC2119]. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on November 3, 2016. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Problem Statement: GSSAPI service name for ADMIN . . . . 2 57 1.2. Problem Statement: GSSAPI service name for NSDB . . . . . 3 58 1.3. Problem Statement: Compromised NSDBs . . . . . . . . . . 3 59 2. GSSAPI Service Name for the FedFS ADMIN protocol . . . . . . 4 60 3. GSSAPI Service Name for the FedFS NSDB protocol . . . . . . . 5 61 3.1. Cross-realm considerations . . . . . . . . . . . . . . . 6 62 4. Fencing Compromised NSDBs . . . . . . . . . . . . . . . . . . 6 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 8.2. Informative References . . . . . . . . . . . . . . . . . 8 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 Requirements for federated filesystems are described in [RFC5716]. 74 Specification of the protocol used by administrators to configure 75 fileservers and construct namespaces is provided in [RFC7533]. 76 Specification of the protocol allowing fileservers to store namespace 77 information is provided in [RFC7532]. 79 These documents are now immutable. However, some security-related 80 concerns have arisen that should be addressed immediately rather than 81 waiting for another version of these protocols to be ratified. 83 1.1. Problem Statement: GSSAPI service name for ADMIN 85 After IESG review, the Security Considerations chapter of [RFC7533] 86 now specifically requires that implementations of this protocol 87 support GSSAPI security mechanisms. 89 ADMIN protocol clients must use a service principal to establish a 90 GSS context shared with an ADMIN server. To construct the service 91 principal, clients need to know a priori the protocol's GSSAPI 92 service name. The form of that service name is described in section 93 4.1 of [RFC2743]. 95 Also according to the final paragraph of section 4.1, requesting an 96 addition to the "GSSAPI/Kerberos/SASL Service Names" registry 97 requires a specification. Because [RFC7533] cannot be changed, a new 98 specification must be provided. 100 1.2. Problem Statement: GSSAPI service name for NSDB 102 [RFC7532] specifies that NSDB services must be based on the LDAP 103 protocol [RFC4511]. [RFC7532] and [RFC7533] already specify a 104 mechanism to protect NSDB connections using x.509 [RFC4513]. 106 In some cases, it is inconvenient for domain administrators to 107 provide x.509 certificates for NSDBs. One reason might be that 108 administrators have no access to a public trusted Certificate 109 Authority. If a Kerberos TGT service is available locally, for 110 example, that could be a more logical choice than x.509 for managing 111 NSDB server identity. 113 The RPC [RFC5531] and LDAP protocols have GSSAPI in common. The 114 present document clarifies the use of existing SASL GSSAPI mechanisms 115 when deployed with NSDBs. It does not address how the ADMIN protocol 116 can specify SASL GSSAPI in NSDB connection parameters. 118 1.3. Problem Statement: Compromised NSDBs 120 The FedFS ADMIN RPC protocol provides a mechanism for provisioning 121 NSDBs on remote fileservers. The operations it provides are 122 FEDFS_SET_NSDB_PARAMS, FEDFS_GET_NSDB_PARAMS, and 123 FEDFS_GET_LIMITED_NSDB_PARAMS. 125 FEDFS_SET_NSDB_PARAMS specifies the name of an NSDB and the security 126 mode to use when connecting to this NSDB. The fileserver connects to 127 an NSDB in order to resolve a FedFS junction. The ADMIN protocol 128 specification further says: 130 On success, this operation returns FEDFS_OK. When the operation 131 returns, the new connection parameters SHOULD be used for all 132 subsequent LDAP connections to the given NSDB. Existing 133 connections MAY be terminated and re-established using the new 134 connection parameters. The connection parameters SHOULD be 135 durable across fileserver reboots. 137 There are two security modes defined in the protocol specification: 138 FEDFS_SEC_NONE, which does not authenticate the LDAP server; and 139 FEDFS_SEC_TLS, which uses START_TLS (RFC 4513) to authenticate the 140 LDAP server. 142 When FEDFS_SEC_TLS is specified with the FEDFS_SET_NSDB_PARAMS 143 operation, an x.509v3 certificate chain is also provided to the 144 fileserver. The fileserver uses the provided certificate to 145 authenticate subsequent connections to this NSDB. The 146 FEDFS_SET_NSDB_PARAMS operation can change the connection security 147 used by a fileserver to connect to a particular NSDB from NONE to TLS 148 or TLS to NONE. 150 Over time, domain administrators add NSDB connection parameters to 151 each of their fileservers to enable FedFS junction resolution. The 152 specified NSDB may be the domain's own, or it might be an NSDB in a 153 foreign domain. 155 Many junctions on multiple fileservers can be created that use a 156 particular NSDB. There is no way to find such junctions without an 157 exhaustive search. Since filesystem namespace topology can evolve 158 arbitrarily over time, a recorded pathname of any junction is almost 159 guaranteed to become stale. 161 Now suppose we have two FedFS domains: example.net and 162 university.edu. Suppose university.edu fileservers have a number of 163 junctions that refer to locations maintained by example.net, and thus 164 university.net's fileservers are configured to resolve junctions on 165 example.net's NSDB. 167 One day Mallory compromises example.net's NSDB, but the domain 168 administrator there is on a long vacation. The administrator at 169 university.net discovers the compromise immediately, but has no 170 control over the foreign NSDB and cannot create a fresh x.509 171 certificate or verify that the contents of the NSDB are unmolested. 172 The only choice is to find and remove every junction in the 173 university.edu domain that contains the compromised NSDB. 175 If university.edu is using a good implementation of FedFS, the 176 administrative tools it provides might allow an administrator to 177 simply visit each of its fileservers and mark the example.net NSDB as 178 compromised. Any junction resolution that attempts to use that NSDB 179 would fail, but all junctions remain in place. When example.net's 180 administrator gets back from holiday and cleans up the mess, the 181 university.edu administrator can then update each of her fileservers 182 with fresh connection parameters for that NSDB. 184 However, none of this can be done remotely using the FedFS ADMIN 185 protocol. It does not have a mechanism for removing NSDB connection 186 parameters or for fencing a compromised NSDB. 188 2. GSSAPI Service Name for the FedFS ADMIN protocol 190 Section 6 of [RFC7533] requires a FedFS ADMIN server to support the 191 RPCSEC_GSS framework [RFC2203]. The present document specifies the 192 GSSAPI service name, as described in Section 4.1 of [RFC2743], to be 193 used for the FedFS ADMIN protocol. 195 Regardless of what security mechanism under RPCSEC_GSS is in use, a 196 FedFS ADMIN server MUST identify itself in GSSAPI via a 197 GSS_C_NT_HOSTBASED_SERVICE name type. GSS_C_NT_HOSTBASED_SERVICE 198 names are of the form: 200 service@hostname 202 For the ADMIN protocol, the "service" element is 204 fedfs-admin 206 Implementations of security mechanisms will convert fedfs- 207 admin@hostname to various different forms. For Kerberos V5, the 208 following form is RECOMMENDED: 210 fedfs-admin/hostname 212 This service name SHOULD NOT be used to authenticate other GSSAPI 213 services. 215 3. GSSAPI Service Name for the FedFS NSDB protocol 217 Section 5.2.1.1 of [RFC4513] specifies the GSS service name for LDAP. 218 LDAP servers acting as NSDBs MUST use this service name, which is of 219 the form: 221 service@hostname 223 When accessing an NSDB service, the "service" element is 225 ldap 227 Implementations of security mechanisms will convert ldap@hostname to 228 various different forms. For Kerberos V5, the following form is 229 RECOMMENDED: 231 ldap/hostname 233 FedFS-enabled file servers act as NSDB clients when resolving FedFS 234 junctions. In order to access NSDBs via SASL GSSAPI, such clients 235 would first authenticate to a KDC. To avoid a requirement for human 236 interaction (say, to enter a Kerberos password), such clients should 237 utilize a key stored in a keytab. Clients MAY use nfs/hostname, but 238 MUST NOT use fedfs-admin/hostname. 240 3.1. Cross-realm considerations 242 Note that the target NSDB's REALM is not specified above. When 243 authenticating a GSSAPI service, NSDB clients typically have a 244 service name (in this case "ldap") and the fully qualified domain 245 name of the NSDB server. The underlying LDAP client library will 246 either: 248 1. Find the server's REALM based on local configuration, or 250 2. Request a referral from the local KDC if the NSDB server's FQDN 251 is not registered in the default REALM. 253 Therefore, a pre-existing trust relationship must exist between the 254 REALM of a FedFS-enabled file server and the REALMs containing 255 foreign NSDBs containing junctions that file server wants to resolve. 256 In this instance, an x.509 certificate may be a preferrable approach. 258 4. Fencing Compromised NSDBs 260 An NSDB is considered "foreign" relative to a particular FedFS domain 261 if that domain's administrator has no administrative access to that 262 NSDB. 264 When a FedFS domain administrator is faced with a foreign NSDB that 265 is compromised or otherwise unusable, and in the absense of an 266 implementation-provided mechanism for fencing an NSDB, the 267 administrator can fence that NSDB using the following technique. 269 1. The administrator locally generates a new certificate for the 270 compromised foreign NSDB. The certificate can be self-signed, or 271 signed by the administrator's local certificate authority. 273 2. The administrator distributes this certificate to all of her 274 domain's fileservers using the FedFS ADMIN protocol or some other 275 secure means. The connection security for the foreign NSDB is 276 set to FEDFS_SEC_TLS on each of the local domain's fileservers. 278 3. The administrator requests fresh certificate material from the 279 administrator of the foreign NSDB. 281 4. When the threat has passed and the foreign NSDB is safe to use 282 again, the administrator can distribute the new valid certificate 283 material to her domain's fileservers. 285 No change to the ADMIN protocol as specified in [RFC7533] is required 286 to fence a compromised NSDB. Step 2 guarantees that, on fileservers 287 in the administrator's local FedFS domain, resolving a junction that 288 references the compromised foreign NSDB will fail until updated 289 certificate material is provided. 291 5. Security Considerations 293 When deploying FedFS, the use of security mechanisms that maintain 294 the confidentiality of all network communications is recommended. 295 This includes the use of any pseudoflavor that supports the 296 rpc_gss_svc_privacy service for the FedFS ADMIN protocol, and the use 297 of TLS message encryption for the NSDB protocol. 299 When creating x.509 certificates for authenticating NSDBs, 300 implementations should utilize keys that are as large as practical, 301 especially if certificate lifetimes are long. 303 Operational security is further enhanced by ensuring that all 304 hardware entropy sources are verified for cryptographic use. This 305 recommendation applies to the creation of x.509 certificate material, 306 random-variant UUIDs, and handshake keys used to secure transports, 307 for example. 309 Information stored in fedfsDescr and fedfsAnnotation attributes are 310 readable by any unauthenticated user of an NSDB, and therefore should 311 contain no sensitive information. 313 6. IANA Considerations 315 In accordance with Section 4.1 of [RFC2743], the service name "fedfs- 316 admin" will be registered in the GSSAPI Service Name registry at 317 http://www.iana.org/assignments/gssapi-service-names/ gssapi-service- 318 names.xml 320 The new entry should reference the present document as the 321 specification. 323 7. Acknowledgements 325 The author of this document gratefully acknowledges the contributions 326 of Simo Sorce, Nico Williams, Robert Thurlow, Spencer Shepler, Tom 327 Haynes, and David Noveck. 329 8. References 331 8.1. Normative References 333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 334 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 335 RFC2119, March 1997, 336 . 338 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 339 Specification", RFC 2203, DOI 10.17487/RFC2203, September 340 1997, . 342 [RFC2743] Linn, J., "Generic Security Service Application Program 343 Interface Version 2, Update 1", RFC 2743, DOI 10.17487/ 344 RFC2743, January 2000, 345 . 347 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 348 Protocol (LDAP): The Protocol", RFC 4511, DOI 10.17487/ 349 RFC4511, June 2006, 350 . 352 [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol 353 (LDAP): Authentication Methods and Security Mechanisms", 354 RFC 4513, DOI 10.17487/RFC4513, June 2006, 355 . 357 [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol 358 Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, 359 May 2009, . 361 [RFC7532] Lentini, J., Tewari, R., and C. Lever, Ed., "Namespace 362 Database (NSDB) Protocol for Federated File Systems", RFC 363 7532, DOI 10.17487/RFC7532, March 2015, 364 . 366 [RFC7533] Lentini, J., Tewari, R., and C. Lever, Ed., 367 "Administration Protocol for Federated File Systems", RFC 368 7533, DOI 10.17487/RFC7533, March 2015, 369 . 371 8.2. Informative References 373 [RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. 374 Naik, "Requirements for Federated File Systems", RFC 5716, 375 DOI 10.17487/RFC5716, January 2010, 376 . 378 Author's Address 380 Charles Lever 381 Oracle Corporation 382 1015 Granger Avenue 383 Ann Arbor, MI 48104 384 USA 386 Phone: +1 734 274 2396 387 Email: chuck.lever@oracle.com