idnits 2.17.1 draft-mcd-identifier-access-security-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 25, 2019) is 1577 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'OpenID' is defined on line 374, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-11) exists of draft-ietf-uta-tls-bcp-09 == Outdated reference: A later version (-08) exists of draft-mcd-identifier-access-responce-00 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force (IETF) C. Ma 2 Internet Draft J. Chen 3 Intended status: Experimental X. Fan 4 Expires: June 25, 2020 M. Chen 5 Z. Li 6 China Academy of Information and Communications Technology 7 December 25, 2019 9 Security Services for the Industrial Internet Identifier Data Access 10 Protocol (IIIDAP) 11 draft-mcd-identifier-access-security-00 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on June 25, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. Code Components extracted from this 47 document must include Simplified BSD License text as described in 48 Section 4.e of the Trust Legal Provisions and are provided without 49 warranty as described in the Simplified BSD License. 51 Abstract 53 The Industrial Internet Identifier Data Access Protocol (IIIDAP) 54 provides "RESTful" web services to retrieve identifier metadata from 55 Second-Level Node (SLN). This document describes information 56 security services, including access control, authentication, 57 authorization, availability, data confidentiality, and data 58 integrity for IIIDAP. 60 Table of Contents 62 1. Introduction ................................................ 2 63 2. Conventions used in this document............................ 3 64 2.1. Acronyms and Abbreviations.............................. 3 65 3. Information Security Services and IIIDAP..................... 3 66 3.1. Access Control ......................................... 3 67 3.2. Authentication ......................................... 3 68 3.3. Authorization .......................................... 4 69 3.4. Availability ........................................... 5 70 3.5. Data Confidentiality.................................... 5 71 3.6. Data Integrity ......................................... 6 72 4. Privacy Threats Associated with Industrial Internet Identifier 73 Data ........................................................... 7 74 5. Security Considerations...................................... 7 75 6. References .................................................. 8 76 6.1. Normative References.................................... 8 77 6.2. Informative References.................................. 9 79 1. Introduction 81 One goal of IIIDAP is to provide security services, including access 82 control, authentication, authorization, availability, data 83 confidentiality, and data integrity. This document describes how 84 each of these services is achieved by IIIDAP using features that are 85 available in other protocol layers. Additional or alternative 86 mechanisms can be added in the future. 88 2. Conventions used in this document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [RFC2119]. 94 2.1. Acronyms and Abbreviations 96 HTTP: Hypertext Transfer Protocol 98 JSON: JavaScript Object Notation 100 IIIDAP: Industrial Internet Identifier Data Access Protocol 102 SLN: Second-Level Nodes 104 ELN: Enterprise-Level Nodes 106 TLS: Transport Layer Security 108 3. Information Security Services and IIIDAP 110 IIIDAP itself does not include native security services. Instead, 111 IIIDAP relies on features that are available in other protocol 112 layers to provide needed security services, including access 113 control, authentication, authorization, availability, data 114 confidentiality, and data integrity. A description of each of these 115 security services can be found in "Internet Security Glossary, 116 Version 2" [RFC4949]. No requirements have been identified for other 117 security services. 119 3.1. Access Control 121 As described in the following sections, IIIDAP includes features to 122 identify, authenticate, and authorize clients, allowing server 123 operators to control access to information based on a client's 124 identity and associated authorizations. Information returned to a 125 client can be clearly marked with a status value (see Section 13 of 126 [IDENTIFIER-RESPONSES]) that identifies the access granted to the 127 client. 129 3.2. Authentication 131 This section describes security authentication mechanisms and the 132 need for authorization policies to include them. It describes 133 requirements for the implementations of clients and servers but does 134 not dictate the policies of server operators. For example, a server 135 operator with no policy regarding differentiated or tiered access to 136 data will have no authorization mechanisms and will have no need for 137 any type of authentication. A server operator with policies on 138 differentiated access will have to construct an authorization scheme 139 and will need to follow the specified authentication requirements. 141 IIIDAP's authentication framework needs to accommodate anonymous 142 access as well as verification of identities using a range of 143 authentication methods and credential services. To that end, IIIDAP 144 clients and servers MUST implement the authentication framework 145 specified in "Hypertext Transfer Protocol (HTTP/1.1): 146 Authentication" [RFC7235]. The "basic" scheme can be used to send a 147 client's user name and password to a server in plaintext, base64- 148 encoded form. The "digest" scheme can be used to authenticate a 149 client without exposing the client's plaintext password. If the 150 "basic" scheme is used, HTTP over TLS [RFC2818] MUST be used to 151 protect the client's credentials from disclosure while in transit 152 (see Section 3.5). 154 Servers MUST support either Basic or Digest authentication; they are 155 not required to support both. Clients MUST support both to 156 interoperate with servers that support one or the other. Servers may 157 provide a login page that triggers HTTP authentication. Clients 158 should continue sending the HTTP authentication header once they 159 receive an initial 401 (Unauthorized) response from the HTTP server 160 as long as the scheme portion of the URL doesn't change. 162 The Transport Layer Security protocol [RFC5246] includes an optional 163 feature to identify and authenticate clients who possess and present 164 a valid X.509 digital certificate [RFC5280]. Support for this 165 feature is OPTIONAL. 167 IIIDAP does not impose any unique server authentication 168 requirements. The server authentication provided by TLS fully 169 addresses the needs of IIIDAP. In general, transports for IIIDAP 170 must either provide a TLS-protected transport (e.g., HTTPS) or a 171 mechanism that provides an equivalent level of server 172 authentication. 174 Work on HTTP authentication methods continues. IIIDAP is designed to 175 be agile enough to support additional methods as they are defined. 177 3.3. Authorization 179 Server operators MAY offer varying degrees of access depending on 180 policy and need in conjunction with the authentication methods 181 described in Section 3.2. If such varying degrees of access are 182 supported, an IIIDAP server MUST provide granular access controls 183 (that is, per identifier metadata) in order to implement 184 authorization policies. Some examples: 186 - Clients will be allowed access only to data for which they have a 187 relationship. 189 - Unauthenticated or anonymous access status may not yield any 190 contact information. 192 - Full access may be granted to a special group of authenticated 193 clients. 195 The type of access allowed by a server will most likely vary from 196 one operator to the next. A description of the response privacy 197 considerations associated with different levels of authorization can 198 be found in Section 13 of [IDENTIFIER-RESPONSES]. 200 3.4. Availability 202 An IIIDAP service has to be available to be useful. There are no 203 IIIDAP-unique requirements to provide availability, but as a general 204 security consideration, a service operator needs to be aware of the 205 issues associated with denial of service. A thorough reading of 206 "Internet Denial-of-Service Considerations" [RFC4732] is advised. 208 An IIIDAP service MAY use an HTTP throttling mechanism to limit the 209 number of queries that a single client can send in a given period of 210 time. If used, the server SHOULD return an HTTP 429 (Too Many 211 Requests) response code as described in "Additional HTTP Status 212 Codes" [RFC6585]. A client that receives a 429 response SHOULD 213 decrease its query rate and honor the Retry-After header field if 214 one is present. Note that this is not a defense against denial-of- 215 service attacks, since a malicious client could ignore the code and 216 continue to send queries at a high rate. A server might use another 217 response code if it did not wish to reveal to a client that rate 218 limiting is the reason for the denial of a reply. 220 3.5. Data Confidentiality 222 IIIDAP uses HTTP over TLS [RFC2818] to provide that protection by 223 encrypting all traffic sent on the connection between client and 224 server. HTTP over TLS MUST be used to protect all client-server 225 exchanges unless operational constraints make it impossible to meet 226 this requirement. It is also possible to encrypt discrete objects 227 (such as command path segments and JSON- encoded response objects) 228 at one endpoint, send them to the other endpoint via an unprotected 229 transport protocol, and decrypt the object on receipt. Encryption 230 algorithms as described in "Internet Security Glossary, Version 2" 231 [RFC4949] are commonly used to provide data confidentiality at the 232 object level. 234 There are no current requirements for object-level data 235 confidentiality using encryption. Support for this feature could be 236 added to IIIDAP in the future. 238 As noted in Section 3.2, the HTTP "basic" authentication scheme can 239 be used to authenticate a client. When this scheme is used, HTTP 240 over TLS MUST be used to protect the client's credentials from 241 disclosure while in transit. If the policy of the server operator 242 requires encryption to protect client-server data exchanges (such as 243 to protect non-public data that cannot be accessed without client 244 identification and authentication), HTTP over TLS MUST be used to 245 protect those exchanges. 247 A description of privacy threats that can be addressed with 248 confidentiality services can be found in Section 4. Section 13 of 249 [IDENTIFIER-RESPONSES] describes status values that can be used to 250 describe operator actions used to protect response data from 251 disclosure to unauthorized clients. 253 3.6. Data Integrity 255 Web services such as IIIDAP commonly use HTTP over TLS [RFC2818] to 256 provide that protection by using a keyed Message Authentication Code 257 (MAC) to detect modifications. It is also possible to sign discrete 258 objects (such as command path segments and JSON-encoded response 259 objects) at one endpoint, send them to the other endpoint via a 260 transport protocol, and validate the signature of the object on 261 receipt. Digital signature algorithms as described in "Internet 262 Security Glossary, Version 2" [RFC4949] are commonly used to provide 263 data integrity at the object level. 265 There are no current requirements for object-level data integrity 266 using digital signatures. Support for this feature could be added to 267 IIIDAP in the future. 269 The most specific need for this service is to provide assurance that 270 HTTP 30x redirection hints [RFC7231] and response elements returned 271 from the server are not modified while in transit. If the policy of 272 the server operator requires message integrity for client-server 273 data exchanges, HTTP over TLS MUST be used to protect those 274 exchanges. 276 4. Privacy Threats Associated with Industrial Internet Identifier Data 278 The identifiers' information of ELN SHOULD be uploaded to SLN. The 279 standardization of IIIDAP does not change or impact the data that 280 operators of SLN may require to be collected from ELN, but it 281 provides support for a number of mechanisms that may be used to 282 mitigate privacy threats to ELN should SLN choose to use them. 284 IIIDAP includes mechanisms that can be used to authenticate clients, 285 allowing servers to support tiered access based on local policy. 286 This means that all identifier data need no longer be public, and 287 personal data or data that may be considered more sensitive can have 288 its access restricted to specifically privileged clients. 290 IIIDAP data structures allow servers to indicate via status values 291 when data returned to clients has been made private, redacted, 292 obscured, by a proxy. "Private" means that the data is not 293 designated for public consumption. "Redacted" means that some 294 identifier data fields are not being made available. "Obscured" 295 means that data has been altered for the purposes of not readily 296 revealing the actual identifier information. 298 In addition to privacy risks to the information of identifiers, 299 there are also potential privacy risks for those who query 300 identifier data. For example, the fact that a SLN employee performs 301 a particular query may reveal information about the employee's 302 activities that he or she would have preferred to keep private. 303 IIIDAP supports the use of HTTP over TLS to provide privacy 304 protection for those querying identifier data, unless operational 305 constraints make it impossible to meet this requirement. 307 5. Security Considerations 309 This document describes the security services provided by IIIDAP and 310 associated protocol layers, including authentication, authorization, 311 availability, data confidentiality, and data integrity. 313 As an HTTP-based protocol, IIIDAP is susceptible to code injection 314 attacks. Code injection refers to adding code into a computer system 315 or program to alter the course of execution. There are many types of 316 code injection, including SQL injection, dynamic variable or 317 function injection, include-file injection, shell injection, and 318 HTML-script injection, among others. Data confidentiality and 319 integrity services provide a measure of defense against man-in-the- 320 middle injection attacks, but vulnerabilities in both client- and 321 server-side software make it possible for injection attacks to 322 succeed. Consistently checking and validating server credentials can 323 help detect man-in-the-middle attacks. 325 There is a risk of too promiscuous, or even rogue, CAs being 326 included in the list of acceptable CAs that the TLS server sends the 327 client as part of the TLS client-authentication handshake and 328 lending the appearance of trust to certificates signed by those CAs. 329 Periodic monitoring of the list of CAs that IIIDAP servers trust for 330 client authentication can help reduce this risk. 332 The Transport Layer Security protocol [RFC5246] includes a null 333 cipher suite that does not encrypt data and thus does not provide 334 data confidentiality. This option MUST NOT be used when data 335 confidentiality services are needed. Additional considerations for 336 secure use of TLS are described in [SECURE-TLS-DTLS]. 338 Data integrity services are sometimes mistakenly associated with 339 directory service operational policy requirements focused on data 340 accuracy. "Accuracy" refers to the truthful association of data 341 elements (such as names, addresses, and telephone numbers). Accuracy 342 requirements are out of scope for this protocol. 344 Additional security considerations are described in the 345 specifications for HTTP [RFC7231], HTTP Basic and Digest access 346 authentication [RFC7235], HTTP over TLS [RFC2818], and additional 347 HTTP status codes [RFC6585]. 349 6. References 351 6.1. Normative References 353 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 354 Requirement Levels", BCP 14, RFC 2119, March 1997, 355 . 357 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000, 358 . 360 [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status 361 Codes", RFC 6585, April 2012, 362 . 364 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 365 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 366 June 2014, . 368 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 369 Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014, 370 . 372 6.2. Informative References 374 [OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final", 375 December 2007, . 377 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 378 Denial-of-Service Considerations", RFC 4732, December 379 2006, . 381 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 382 36, RFC 4949, August 2007, 383 . 385 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 386 (TLS) Protocol Version 1.2", RFC 5246, August 2008, 387 . 389 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 390 Housley, R., and W. Polk, "Internet X.509 Public Key 391 Infrastructure Certificate and Certificate Revocation List 392 (CRL) Profile", RFC 5280, May 2008, 393 . 395 [SECURE-TLS-DTLS] 396 Sheffer, Y., Holz, R., and P. Saint-Andre, 397 "Recommendations for Secure Use of TLS and DTLS", Work in 398 Progress, draft-ietf-uta-tls-bcp-09, February 2015. 400 [IDENTIFIER-RESPONSES] 401 Ma, C., "JSON Responses for the Industrial Internet 402 Identifier Data Access Protocol (IIIDAP)", Work in 403 Progress, draft-mcd-identifier-access-responce-00, 404 December 2019. 406 Authors' Addresses 408 Chendi Ma 409 CAICT 410 No.52 Huayuan North Road, Haidian District 411 Beijing, Beijing, 100191 412 China 414 Phone: +86 177 1090 9864 415 Email: machendi@caict.ac.cn 417 Chen Jian 418 CAICT 419 No.52 Huayuan North Road, Haidian District 420 Beijing, Beijing, 100191 421 China 423 Phone: +86 138 1103 3332 424 Email: chenjian3@caict.ac.cn 426 Xiaotian Fan 427 CAICT 428 No.52 Huayuan North Road, Haidian District 429 Beijing, Beijing, 100191 430 China 432 Phone: +86 134 0108 6945 433 Email: fanxiaotian@caict.ac.cn 435 Meilan Chen 436 CAICT 437 No.52 Huayuan North Road, Haidian District 438 Beijing, Beijing, 100191 439 China 441 Phone: +86 139 1143 7301 442 Email: chenmeilan@caict.ac.cn 443 Zhiping Li 444 CAICT 445 No.52 Huayuan North Road, Haidian District 446 Beijing, Beijing, 100191 447 China 449 Phone: +86 185 1107 1386 450 Email: lizhiping@caict.ac.cn