idnits 2.17.1 draft-cel-nfsv4-federated-fs-security-addendum-00.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 (January 15, 2014) is 3753 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 January 15, 2014 5 Expires: July 19, 2014 7 Federated Filesystem Security Addendum 8 draft-cel-nfsv4-federated-fs-security-addendum-00 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 July 19, 2014. 38 Copyright Notice 40 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Problem Statement: GSSAPI service name for ADMIN . . . . . 4 57 1.2. Problem Statement: Compromised NSDBs . . . . . . . . . . . 4 58 1.3. Scope Of This Document . . . . . . . . . . . . . . . . . . 6 59 2. GSSAPI Service Name for the FedFS ADMIN protocol . . . . . . . 7 60 3. Fencing Compromised NSDBs . . . . . . . . . . . . . . . . . . 8 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 66 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 1. Introduction 71 Requirements for federated filesystems are described in [RFC5716]. 72 Specification of the protocol used by administrators to configure 73 fileservers and construct namespaces is provided in [FEDFS-ADMIN]. 74 Specification of the protocol allowing fileservers to store namespace 75 information is provided in [FEDFS-NSDB]. 77 These documents are now immutable. However, some security-related 78 concerns have arisen that should be addressed immediately rather than 79 waiting for another version of these protocols to be ratified. 81 1.1. Problem Statement: GSSAPI service name for ADMIN 83 After IESG review, the Security Considerations chapter of 84 [FEDFS-ADMIN] now specifically requires that implementations of this 85 protocol support GSSAPI security mechanisms. 87 ADMIN protocol clients must use a service principal to establish a 88 GSS context shared with an ADMIN server. To construct the service 89 principal, clients need to know a priori the protocol's GSSAPI 90 service name. The form of that service name is described in section 91 4.1 of [RFC2743]. 93 Also according to the final paragraph of section 4.1, requesting an 94 addition to the "GSSAPI/Kerberos/SASL Service Names" registry 95 requires a specification. Because [FEDFS-ADMIN] cannot be changed, a 96 new specification must be provided. 98 1.2. Problem Statement: Compromised NSDBs 100 The FedFS ADMIN RPC protocol provides a mechanism for provisioning 101 NSDBs on remote fileservers. The operations it provides are 102 FEDFS_SET_NSDB_PARAMS, FEDFS_GET_NSDB_PARAMS, and 103 FEDFS_GET_LIMITED_NSDB_PARAMS. 105 FEDFS_SET_NSDB_PARAMS specifies the name of an NSDB and the security 106 mode to use when connecting to this NSDB. The fileserver connects to 107 an NSDB in order to resolve a FedFS junction. The ADMIN protocol 108 specification further says: 110 On success, this operation returns FEDFS_OK. When the operation 111 returns, the new connection parameters SHOULD be used for all 112 subsequent LDAP connections to the given NSDB. Existing 113 connections MAY be terminated and re-established using the new 114 connection parameters. The connection parameters SHOULD be 115 durable across fileserver reboots. 117 There are two security modes defined in the protocol specification: 118 FEDFS_SEC_NONE, which does not authenticate the LDAP server; and 119 FEDFS_SEC_TLS, which uses START_TLS (RFC 4513) to authenticate the 120 LDAP server. 122 When FEDFS_SEC_TLS is specified with the FEDFS_SET_NSDB_PARAMS 123 operation, an x.509v3 certificate chain is also provided to the 124 fileserver. The fileserver uses the provided certificate to 125 authenticate subsequent connections to this NSDB. The 126 FEDFS_SET_NSDB_PARAMS operation can change the connection security 127 used by a fileserver to connect to a particular NSDB from NONE to TLS 128 or TLS to NONE. 130 Over time, domain administrators add NSDB connection parameters to 131 each of their fileservers to enable FedFS junction resolution. The 132 specified NSDB may be the domain's own, or it might be an NSDB in a 133 foreign domain. 135 Many junctions on multiple fileservers can be created that use a 136 particular NSDB. There is no way to find such junctions without an 137 exhaustive search. Since filesystem namespace topology can evolve 138 arbitrarily over time, a recorded pathname of any junction is almost 139 guaranteed to become stale. 141 Now suppose we have two FedFS domains: example.net and 142 university.edu. Suppose university.edu fileservers have a number of 143 junctions that refer to locations maintained by example.net, and thus 144 university.net's fileservers are configured to resolve junctions on 145 example.net's NSDB. 147 One day Mallory compromises example.net's NSDB, but the domain 148 administrator there is on a long vacation. The administrator at 149 university.net discovers the compromise immediately, but has no 150 control over the foreign NSDB and cannot create a fresh x.509 151 certificate or verify that the contents of the NSDB are unmolested. 152 The only choice is to find and remove every junction in the 153 university.edu domain that contains the compromised NSDB. 155 If university.edu is using a good implementation of FedFS, the 156 administrative tools it provides might allow an administrator to 157 simply visit each of its fileservers and mark the example.net NSDB as 158 compromised. Any junction resolution that attempts to use that NSDB 159 would fail, but all junctions remain in place. When example.net's 160 administrator gets back from holiday and cleans up the mess, the 161 university.edu administrator can then update each of her fileservers 162 with fresh connection parameters for that NSDB. 164 However, none of this can be done remotely using the FedFS ADMIN 165 protocol. It does not have a mechanism for removing NSDB connection 166 parameters or for fencing a compromised NSDB. 168 1.3. Scope Of This Document 170 This document specifies additional requirements for the FedFS ADMIN 171 protocol specified in [FEDFS-ADMIN], which is a standards track 172 specification. 174 2. GSSAPI Service Name for the FedFS ADMIN protocol 176 Section 6 of [FEDFS-ADMIN] requires a FedFS ADMIN server to support 177 the RPCSEC_GSS framework [RFC2203]. The present document specifies 178 the GSSAPI service name, as described in Section 4.1 of [RFC2743], to 179 be used for the FedFS ADMIN protocol. 181 Regardless of what security mechanism under RPCSEC_GSS is in use, a 182 FedFS ADMIN server MUST identify itself in GSSAPI via a 183 GSS_C_NT_HOSTBASED_SERVICE name type. GSS_C_NT_HOSTBASED_SERVICE 184 names are of the form: 186 service@hostname 188 For the ADMIN protocol, the "service" element is 190 fedfs-admin 192 Implementations of security mechanisms will convert 193 fedfs-admin@hostname to various different forms. For Kerberos V5, 194 the following form is RECOMMENDED: 196 fedfs-admin/hostname 198 This service name SHOULD NOT be used to authenticate other GSSAPI 199 services. 201 3. Fencing Compromised NSDBs 203 An NSDB is considered "foreign" relative to a particular FedFS domain 204 if that domain's administrator has no administrative access to that 205 NSDB. 207 When a FedFS domain administrator is faced with a foreign NSDB that 208 is compromised or otherwise unusable, and in the absense of an 209 implementation-provided mechanism for fencing an NSDB, the 210 administrator can fence that NSDB using the following technique. 212 1. The administrator locally generates a new certificate for the 213 compromised foreign NSDB. The certificate can be self-signed, or 214 signed by the administrator's local certificate authority. 216 2. The administrator distributes this certificate to all of her 217 domain's fileservers using the FedFS ADMIN protocol or some other 218 secure means. The connection security for the foreign NSDB is 219 set to FEDFS_SEC_TLS on each of the local domain's fileservers. 221 3. The administrator requests fresh certificate material from the 222 administrator of the foreign NSDB. 224 4. When the threat has passed and the foreign NSDB is safe to use 225 again, the administrator can distribute the new valid certificate 226 material to her domain's fileservers. 228 No change to the ADMIN protocol as specified in [FEDFS-ADMIN] is 229 required to fence a compromised NSDB. Step 2 guarantees that, on 230 fileservers in the administrator's local FedFS domain, resolving a 231 junction that references the compromised foreign NSDB will fail until 232 updated certificate material is provided. 234 4. Security Considerations 236 When deploying FedFS, the use of security mechanisms that maintain 237 the confidentiality of all network communications is recommended. 238 This includes the use of any pseudoflavor that supports the 239 rpc_gss_svc_privacy service for the FedFS ADMIN protocol, and the use 240 of TLS message encryption for the NSDB protocol. 242 When creating x.509 certificates for authenticating NSDBs, 243 implementations should utilize keys that are as large as practical, 244 especially if certificate lifetimes are long. 246 Operational security is further enhanced by ensuring that all 247 hardware entropy sources are verified for cryptographic use. This 248 recommendation applies to the creation of x.509 certificate material, 249 random-variant UUIDs, and handshake keys used to secure transports, 250 for example. 252 Information stored in fedfsDescr and fedfsAnnotation attributes are 253 readable by any unauthenticated user of an NSDB, and therefore should 254 contain no sensitive information. 256 5. IANA Considerations 258 In accordance with Section 4.1 of [RFC2743], the service name "fedfs- 259 admin" will be registered in the GSSAPI Service Name registry at 260 http://www.iana.org/assignments/gssapi-service-names/ gssapi-service- 261 names.xml 263 The new entry should reference the present document as the 264 specification. 266 6. Acknowledgements 268 The author of this document gratefully acknowledges the contributions 269 of Nico Williams, Robert Thurlow, Spencer Shepler, Tom Haynes, and 270 David Noveck. 272 7. References 274 7.1. Normative References 276 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 277 Requirement Levels", BCP 14, RFC 2119, March 1997. 279 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 280 Specification", RFC 2203, September 1997. 282 [RFC2743] Linn, J., "Generic Security Service Application Program 283 Interface Version 2, Update 1", RFC 2743, January 2000. 285 7.2. Informative References 287 [FEDFS-ADMIN] 288 Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. 289 Naik, "Administration Protocol for Federated Filesystems", 290 draft-ietf-nfsv4-federated-fs-admin (Work In Progress), 291 2010. 293 [FEDFS-NSDB] 294 Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. 295 Naik, "NSDB Protocol for Federated Filesystems", 296 draft-ietf-nfsv4-federated-fs-protocol (Work In Progress), 297 2010. 299 [RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. 300 Naik, "Requirements for Federated File Systems", RFC 5716, 301 January 2010. 303 Author's Address 305 Charles Lever 306 Oracle Corporation 307 1015 Granger Avenue 308 Ann Arbor, MI 48104 309 US 311 Phone: +1 734 274 2396 312 Email: chuck.lever@oracle.com