idnits 2.17.1 draft-cel-nfsv4-federated-fs-security-addendum-03.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 20, 2015) is 3263 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 NFSv4 C. Lever 3 Internet-Draft Oracle 4 Intended status: Standards Track May 20, 2015 5 Expires: November 21, 2015 7 Federated Filesystem Security Addendum 8 draft-cel-nfsv4-federated-fs-security-addendum-03 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 21, 2015. 38 Copyright Notice 40 Copyright (c) 2015 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 1.4. Scope Of This Document . . . . . . . . . . . . . . . . . 5 60 2. GSSAPI Service Name for the FedFS ADMIN protocol . . . . . . 5 61 3. GSSAPI Service Name for the FedFS NSDB protocol . . . . . . . 5 62 3.1. Cross-realm considerations . . . . . . . . . . . . . . . 6 63 4. Fencing Compromised NSDBs . . . . . . . . . . . . . . . . . . 6 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 8.2. Informative References . . . . . . . . . . . . . . . . . 8 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 Requirements for federated filesystems are described in [RFC5716]. 75 Specification of the protocol used by administrators to configure 76 fileservers and construct namespaces is provided in [RFC7533]. 77 Specification of the protocol allowing fileservers to store namespace 78 information is provided in [RFC7532]. 80 These documents are now immutable. However, some security-related 81 concerns have arisen that should be addressed immediately rather than 82 waiting for another version of these protocols to be ratified. 84 1.1. Problem Statement: GSSAPI service name for ADMIN 86 After IESG review, the Security Considerations chapter of [RFC7533] 87 now specifically requires that implementations of this protocol 88 support GSSAPI security mechanisms. 90 ADMIN protocol clients must use a service principal to establish a 91 GSS context shared with an ADMIN server. To construct the service 92 principal, clients need to know a priori the protocol's GSSAPI 93 service name. The form of that service name is described in section 94 4.1 of [RFC2743]. 96 Also according to the final paragraph of section 4.1, requesting an 97 addition to the "GSSAPI/Kerberos/SASL Service Names" registry 98 requires a specification. Because [RFC7533] cannot be changed, a new 99 specification must be provided. 101 1.2. Problem Statement: GSSAPI service name for NSDB 103 [RFC7532] specifies that NSDB services must be based on the LDAP 104 protocol [RFC4511]. [RFC7532] and [RFC7533] already specify a 105 mechanism to protect NSDB connections using x.509 [RFC4513]. 107 In some cases, it is inconvenient for domain administrators to 108 provide x.509 certificates for NSDBs. One reason might be that 109 administrators have no access to a public trusted Certificate 110 Authority. If a Kerberos TGT service is available locally, for 111 example, that could be a more logical choice than x.509 for managing 112 NSDB server identity. 114 The RPC [RFC5531] and LDAP protocols have GSSAPI in common. The 115 present document clarifies the use of existing SASL GSSAPI mechanisms 116 when deployed with NSDBs. It does not address how the ADMIN protocol 117 can specify SASL GSSAPI in NSDB connection parameters. 119 1.3. Problem Statement: Compromised NSDBs 121 The FedFS ADMIN RPC protocol provides a mechanism for provisioning 122 NSDBs on remote fileservers. The operations it provides are 123 FEDFS_SET_NSDB_PARAMS, FEDFS_GET_NSDB_PARAMS, and 124 FEDFS_GET_LIMITED_NSDB_PARAMS. 126 FEDFS_SET_NSDB_PARAMS specifies the name of an NSDB and the security 127 mode to use when connecting to this NSDB. The fileserver connects to 128 an NSDB in order to resolve a FedFS junction. The ADMIN protocol 129 specification further says: 131 On success, this operation returns FEDFS_OK. When the operation 132 returns, the new connection parameters SHOULD be used for all 133 subsequent LDAP connections to the given NSDB. Existing 134 connections MAY be terminated and re-established using the new 135 connection parameters. The connection parameters SHOULD be 136 durable across fileserver reboots. 138 There are two security modes defined in the protocol specification: 139 FEDFS_SEC_NONE, which does not authenticate the LDAP server; and 140 FEDFS_SEC_TLS, which uses START_TLS (RFC 4513) to authenticate the 141 LDAP server. 143 When FEDFS_SEC_TLS is specified with the FEDFS_SET_NSDB_PARAMS 144 operation, an x.509v3 certificate chain is also provided to the 145 fileserver. The fileserver uses the provided certificate to 146 authenticate subsequent connections to this NSDB. The 147 FEDFS_SET_NSDB_PARAMS operation can change the connection security 148 used by a fileserver to connect to a particular NSDB from NONE to TLS 149 or TLS to NONE. 151 Over time, domain administrators add NSDB connection parameters to 152 each of their fileservers to enable FedFS junction resolution. The 153 specified NSDB may be the domain's own, or it might be an NSDB in a 154 foreign domain. 156 Many junctions on multiple fileservers can be created that use a 157 particular NSDB. There is no way to find such junctions without an 158 exhaustive search. Since filesystem namespace topology can evolve 159 arbitrarily over time, a recorded pathname of any junction is almost 160 guaranteed to become stale. 162 Now suppose we have two FedFS domains: example.net and 163 university.edu. Suppose university.edu fileservers have a number of 164 junctions that refer to locations maintained by example.net, and thus 165 university.net's fileservers are configured to resolve junctions on 166 example.net's NSDB. 168 One day Mallory compromises example.net's NSDB, but the domain 169 administrator there is on a long vacation. The administrator at 170 university.net discovers the compromise immediately, but has no 171 control over the foreign NSDB and cannot create a fresh x.509 172 certificate or verify that the contents of the NSDB are unmolested. 173 The only choice is to find and remove every junction in the 174 university.edu domain that contains the compromised NSDB. 176 If university.edu is using a good implementation of FedFS, the 177 administrative tools it provides might allow an administrator to 178 simply visit each of its fileservers and mark the example.net NSDB as 179 compromised. Any junction resolution that attempts to use that NSDB 180 would fail, but all junctions remain in place. When example.net's 181 administrator gets back from holiday and cleans up the mess, the 182 university.edu administrator can then update each of her fileservers 183 with fresh connection parameters for that NSDB. 185 However, none of this can be done remotely using the FedFS ADMIN 186 protocol. It does not have a mechanism for removing NSDB connection 187 parameters or for fencing a compromised NSDB. 189 1.4. Scope Of This Document 191 This document specifies additional requirements for the FedFS ADMIN 192 protocol specified in [RFC7533], which is a standards track 193 specification. 195 2. GSSAPI Service Name for the FedFS ADMIN protocol 197 Section 6 of [RFC7533] requires a FedFS ADMIN server to support the 198 RPCSEC_GSS framework [RFC2203]. The present document specifies the 199 GSSAPI service name, as described in Section 4.1 of [RFC2743], to be 200 used for the FedFS ADMIN protocol. 202 Regardless of what security mechanism under RPCSEC_GSS is in use, a 203 FedFS ADMIN server MUST identify itself in GSSAPI via a 204 GSS_C_NT_HOSTBASED_SERVICE name type. GSS_C_NT_HOSTBASED_SERVICE 205 names are of the form: 207 service@hostname 209 For the ADMIN protocol, the "service" element is 211 fedfs-admin 213 Implementations of security mechanisms will convert fedfs- 214 admin@hostname to various different forms. For Kerberos V5, the 215 following form is RECOMMENDED: 217 fedfs-admin/hostname 219 This service name SHOULD NOT be used to authenticate other GSSAPI 220 services. 222 3. GSSAPI Service Name for the FedFS NSDB protocol 224 Section 5.2.1.1 of [RFC4513] specifies the GSS service name for LDAP. 225 LDAP servers acting as NSDBs MUST use this service name, which is of 226 the form: 228 service@hostname 230 When accessing an NSDB service, the "service" element is 232 ldap 234 Implementations of security mechanisms will convert ldap@hostname to 235 various different forms. For Kerberos V5, the following form is 236 RECOMMENDED: 238 ldap/hostname 240 FedFS-enabled file servers act as NSDB clients when resolving FedFS 241 junctions. In order to access NSDBs via SASL GSSAPI, such clients 242 would first authenticate to a KDC. To avoid a requirement for human 243 interaction (say, to enter a Kerberos password), such clients should 244 utilize a key stored in a keytab. Clients MAY use nfs/hostname, but 245 MUST NOT use fedfs-admin/hostname. 247 3.1. Cross-realm considerations 249 Note that the target NSDB's REALM is not specified above. When 250 authenticating a GSSAPI service, NSDB clients typically have a 251 service name (in this case "ldap") and the fully qualified domain 252 name of the NSDB server. The underlying LDAP client library will 253 either: 255 1. Find the server's REALM based on local configuration, or 257 2. Request a referral from the local KDC if the NSDB server's FQDN 258 is not registered in the default REALM. 260 Therefore, a pre-existing trust relationship must exist between the 261 REALM of a FedFS-enabled file server and the REALMs containing 262 foreign NSDBs containing junctions that file server wants to resolve. 263 In this instance, an x.509 certificate may be a preferrable approach. 265 4. Fencing Compromised NSDBs 267 An NSDB is considered "foreign" relative to a particular FedFS domain 268 if that domain's administrator has no administrative access to that 269 NSDB. 271 When a FedFS domain administrator is faced with a foreign NSDB that 272 is compromised or otherwise unusable, and in the absense of an 273 implementation-provided mechanism for fencing an NSDB, the 274 administrator can fence that NSDB using the following technique. 276 1. The administrator locally generates a new certificate for the 277 compromised foreign NSDB. The certificate can be self-signed, or 278 signed by the administrator's local certificate authority. 280 2. The administrator distributes this certificate to all of her 281 domain's fileservers using the FedFS ADMIN protocol or some other 282 secure means. The connection security for the foreign NSDB is 283 set to FEDFS_SEC_TLS on each of the local domain's fileservers. 285 3. The administrator requests fresh certificate material from the 286 administrator of the foreign NSDB. 288 4. When the threat has passed and the foreign NSDB is safe to use 289 again, the administrator can distribute the new valid certificate 290 material to her domain's fileservers. 292 No change to the ADMIN protocol as specified in [RFC7533] is required 293 to fence a compromised NSDB. Step 2 guarantees that, on fileservers 294 in the administrator's local FedFS domain, resolving a junction that 295 references the compromised foreign NSDB will fail until updated 296 certificate material is provided. 298 5. Security Considerations 300 When deploying FedFS, the use of security mechanisms that maintain 301 the confidentiality of all network communications is recommended. 302 This includes the use of any pseudoflavor that supports the 303 rpc_gss_svc_privacy service for the FedFS ADMIN protocol, and the use 304 of TLS message encryption for the NSDB protocol. 306 When creating x.509 certificates for authenticating NSDBs, 307 implementations should utilize keys that are as large as practical, 308 especially if certificate lifetimes are long. 310 Operational security is further enhanced by ensuring that all 311 hardware entropy sources are verified for cryptographic use. This 312 recommendation applies to the creation of x.509 certificate material, 313 random-variant UUIDs, and handshake keys used to secure transports, 314 for example. 316 Information stored in fedfsDescr and fedfsAnnotation attributes are 317 readable by any unauthenticated user of an NSDB, and therefore should 318 contain no sensitive information. 320 6. IANA Considerations 322 In accordance with Section 4.1 of [RFC2743], the service name "fedfs- 323 admin" will be registered in the GSSAPI Service Name registry at 324 http://www.iana.org/assignments/gssapi-service-names/ gssapi-service- 325 names.xml 327 The new entry should reference the present document as the 328 specification. 330 7. Acknowledgements 332 The author of this document gratefully acknowledges the contributions 333 of Simo Sorce, Nico Williams, Robert Thurlow, Spencer Shepler, Tom 334 Haynes, and David Noveck. 336 8. References 338 8.1. Normative References 340 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 341 Requirement Levels", BCP 14, RFC 2119, March 1997. 343 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 344 Specification", RFC 2203, September 1997. 346 [RFC2743] Linn, J., "Generic Security Service Application Program 347 Interface Version 2, Update 1", RFC 2743, January 2000. 349 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 350 (LDAP): The Protocol", RFC 4511, June 2006. 352 [RFC4513] Harrison, R., "Lightweight Directory Access Protocol 353 (LDAP): Authentication Methods and Security Mechanisms", 354 RFC 4513, June 2006. 356 [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol 357 Specification Version 2", RFC 5531, May 2009. 359 [RFC7532] Lentini, J., Tewari, R., and C. Lever, "Namespace Database 360 (NSDB) Protocol for Federated File Systems", RFC 7532, 361 March 2015. 363 [RFC7533] Lentini, J., Tewari, R., and C. Lever, "Administration 364 Protocol for Federated File Systems", RFC 7533, March 365 2015. 367 8.2. Informative References 369 [RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. 370 Naik, "Requirements for Federated File Systems", RFC 5716, 371 January 2010. 373 Author's Address 374 Charles Lever 375 Oracle Corporation 376 1015 Granger Avenue 377 Ann Arbor, MI 48104 378 US 380 Phone: +1 734 274 2396 381 Email: chuck.lever@oracle.com