idnits 2.17.1 draft-mcd-identifier-access-security-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 (June 21, 2022) is 668 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: Informational X. Fan 4 Expires: December 21, 2022 M. Chen 5 Z. Li 6 China Academy of Information and Communications Technology 7 June 21, 2022 9 Security Services for the Industrial Internet Identifier Data Access 10 Protocol (IIIDAP) 11 draft-mcd-identifier-access-security-05 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 21, 2022. 36 Copyright Notice 38 Copyright (c) 2022 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. IANA Considerations ......................................... 8 76 7. References .................................................. 8 77 7.1. Normative References.................................... 8 78 7.2. Informative References.................................. 9 80 1. Introduction 82 One goal of IIIDAP is to provide security services, including access 83 control, authentication, authorization, availability, data 84 confidentiality, and data integrity. This document describes how 85 each of these services is achieved by IIIDAP using features that are 86 available in other protocol layers. Additional or alternative 87 mechanisms can be added in the future. 89 2. Conventions used in this document 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119 [RFC2119]. 95 2.1. Acronyms and Abbreviations 97 HTTP: Hypertext Transfer Protocol 99 JSON: JavaScript Object Notation 101 IIIDAP: Industrial Internet Identifier Data Access Protocol 103 SLN: Second-Level Nodes 105 ELN: Enterprise-Level Nodes 107 TLS: Transport Layer Security 109 3. Information Security Services and IIIDAP 111 IIIDAP itself does not include native security services. Instead, 112 IIIDAP relies on features that are available in other protocol 113 layers to provide needed security services, including access 114 control, authentication, authorization, availability, data 115 confidentiality, and data integrity. A description of each of these 116 security services can be found in "Internet Security Glossary, 117 Version 2" [RFC4949]. No requirements have been identified for other 118 security services. 120 3.1. Access Control 122 As described in the following sections, IIIDAP includes features to 123 identify, authenticate, and authorize clients, allowing server 124 operators to control access to information based on a client's 125 identity and associated authorizations. Information returned to a 126 client can be clearly marked with a status value (see Section 13 of 127 [IDENTIFIER-RESPONSES]) that identifies the access granted to the 128 client. 130 3.2. Authentication 132 This section describes security authentication mechanisms and the 133 need for authorization policies to include them. It describes 134 requirements for the implementations of clients and servers but does 135 not dictate the policies of server operators. For example, a server 136 operator with no policy regarding differentiated or tiered access to 137 data will have no authorization mechanisms and will have no need for 138 any type of authentication. A server operator with policies on 139 differentiated access will have to construct an authorization scheme 140 and will need to follow the specified authentication requirements. 142 IIIDAP's authentication framework needs to accommodate anonymous 143 access as well as verification of identities using a range of 144 authentication methods and credential services. To that end, IIIDAP 145 clients and servers MUST implement the authentication framework 146 [RFC9110]. The "basic" scheme can be used to send a client's user 147 name and password to a server in plaintext, base64-encoded form. The 148 "digest" scheme can be used to authenticate a client without 149 exposing the client's plaintext password. If the "basic" scheme is 150 used, HTTP over TLS [RFC9110] MUST be used to protect the client's 151 credentials from disclosure while in transit (see Section 3.5). 153 Servers MUST support either Basic or Digest authentication; they are 154 not required to support both. Clients MUST support both to 155 interoperate with servers that support one or the other. Servers may 156 provide a login page that triggers HTTP authentication. Clients 157 should continue sending the HTTP authentication header once they 158 receive an initial 401 (Unauthorized) response from the HTTP server 159 as long as the scheme portion of the URL doesn't change. 161 The Transport Layer Security protocol [RFC8446] includes an optional 162 feature to identify and authenticate clients who possess and present 163 a valid X.509 digital certificate [RFC5280]. Support for this 164 feature is OPTIONAL. 166 IIIDAP does not impose any unique server authentication 167 requirements. The server authentication provided by TLS fully 168 addresses the needs of IIIDAP. In general, transports for IIIDAP 169 must either provide a TLS-protected transport (e.g., HTTPS) or a 170 mechanism that provides an equivalent level of server 171 authentication. 173 Work on HTTP authentication methods continues. IIIDAP is designed to 174 be agile enough to support additional methods as they are defined. 176 3.3. Authorization 178 Server operators MAY offer varying degrees of access depending on 179 policy and need in conjunction with the authentication methods 180 described in Section 3.2. If such varying degrees of access are 181 supported, an IIIDAP server MUST provide granular access controls 182 (that is, per identifier metadata) in order to implement 183 authorization policies. Some examples: 185 - Clients will be allowed access only to data for which they have a 186 relationship. 188 - Unauthenticated or anonymous access status may not yield any 189 contact information. 191 - Full access may be granted to a special group of authenticated 192 clients. 194 The type of access allowed by a server will most likely vary from 195 one operator to the next. A description of the response privacy 196 considerations associated with different levels of authorization can 197 be found in Section 13 of [IDENTIFIER-RESPONSES]. 199 3.4. Availability 201 An IIIDAP service has to be available to be useful. There are no 202 IIIDAP-unique requirements to provide availability, but as a general 203 security consideration, a service operator needs to be aware of the 204 issues associated with denial of service. A thorough reading of 205 "Internet Denial-of-Service Considerations" [RFC4732] is advised. 207 An IIIDAP service MAY use an HTTP throttling mechanism to limit the 208 number of queries that a single client can send in a given period of 209 time. If used, the server SHOULD return an HTTP 429 (Too Many 210 Requests) response code as described in "Additional HTTP Status 211 Codes" [RFC6585]. A client that receives a 429 response SHOULD 212 decrease its query rate and honor the Retry-After header field if 213 one is present. Note that this is not a defense against denial-of- 214 service attacks, since a malicious client could ignore the code and 215 continue to send queries at a high rate. A server might use another 216 response code if it did not wish to reveal to a client that rate 217 limiting is the reason for the denial of a reply. 219 3.5. Data Confidentiality 221 IIIDAP uses HTTP over TLS [RFC9110] to provide that protection by 222 encrypting all traffic sent on the connection between client and 223 server. HTTP over TLS MUST be used to protect all client-server 224 exchanges unless operational constraints make it impossible to meet 225 this requirement. It is also possible to encrypt discrete objects 226 (such as command path segments and JSON- encoded response objects) 227 at one endpoint, send them to the other endpoint via an unprotected 228 transport protocol, and decrypt the object on receipt. Encryption 229 algorithms as described in "Internet Security Glossary, Version 2" 230 [RFC4949] are commonly used to provide data confidentiality at the 231 object level. 233 There are no current requirements for object-level data 234 confidentiality using encryption. Support for this feature could be 235 added to IIIDAP in the future. 237 As noted in Section 3.2, the HTTP "basic" authentication scheme can 238 be used to authenticate a client. When this scheme is used, HTTP 239 over TLS MUST be used to protect the client's credentials from 240 disclosure while in transit. If the policy of the server operator 241 requires encryption to protect client-server data exchanges (such as 242 to protect non-public data that cannot be accessed without client 243 identification and authentication), HTTP over TLS MUST be used to 244 protect those exchanges. 246 A description of privacy threats that can be addressed with 247 confidentiality services can be found in Section 4. Section 13 of 248 [IDENTIFIER-RESPONSES] describes status values that can be used to 249 describe operator actions used to protect response data from 250 disclosure to unauthorized clients. 252 3.6. Data Integrity 254 Web services such as IIIDAP commonly use HTTP over TLS [RFC9110] to 255 provide that protection by using a keyed Message Authentication Code 256 (MAC) to detect modifications. It is also possible to sign discrete 257 objects (such as command path segments and JSON-encoded response 258 objects) at one endpoint, send them to the other endpoint via a 259 transport protocol, and validate the signature of the object on 260 receipt. Digital signature algorithms as described in "Internet 261 Security Glossary, Version 2" [RFC4949] are commonly used to provide 262 data integrity at the object level. 264 There are no current requirements for object-level data integrity 265 using digital signatures. Support for this feature could be added to 266 IIIDAP in the future. 268 The most specific need for this service is to provide assurance that 269 HTTP 30x redirection hints [RFC9110] and response elements returned 270 from the server are not modified while in transit. If the policy of 271 the server operator requires message integrity for client-server 272 data exchanges, HTTP over TLS MUST be used to protect those 273 exchanges. 275 4. Privacy Threats Associated with Industrial Internet Identifier Data 277 The identifiers' information of ELN SHOULD be uploaded to SLN. The 278 standardization of IIIDAP does not change or impact the data that 279 operators of SLN may require to be collected from ELN, but it 280 provides support for a number of mechanisms that may be used to 281 mitigate privacy threats to ELN should SLN choose to use them. 283 IIIDAP includes mechanisms that can be used to authenticate clients, 284 allowing servers to support tiered access based on local policy. 285 This means that all identifier data need no longer be public, and 286 personal data or data that may be considered more sensitive can have 287 its access restricted to specifically privileged clients. 289 IIIDAP data structures allow servers to indicate via status values 290 when data returned to clients has been made private, redacted, 291 obscured, by a proxy. "Private" means that the data is not 292 designated for public consumption. "Redacted" means that some 293 identifier data fields are not being made available. "Obscured" 294 means that data has been altered for the purposes of not readily 295 revealing the actual identifier information. 297 In addition to privacy risks to the information of identifiers, 298 there are also potential privacy risks for those who query 299 identifier data. For example, the fact that a SLN employee performs 300 a particular query may reveal information about the employee's 301 activities that he or she would have preferred to keep private. 302 IIIDAP supports the use of HTTP over TLS to provide privacy 303 protection for those querying identifier data, unless operational 304 constraints make it impossible to meet this requirement. 306 5. Security Considerations 308 This document describes the security services provided by IIIDAP and 309 associated protocol layers, including authentication, authorization, 310 availability, data confidentiality, and data integrity. 312 As an HTTP-based protocol, IIIDAP is susceptible to code injection 313 attacks. Code injection refers to adding code into a computer system 314 or program to alter the course of execution. There are many types of 315 code injection, including SQL injection, dynamic variable or 316 function injection, include-file injection, shell injection, and 317 HTML-script injection, among others. Data confidentiality and 318 integrity services provide a measure of defense against man-in-the- 319 middle injection attacks, but vulnerabilities in both client- and 320 server-side software make it possible for injection attacks to 321 succeed. Consistently checking and validating server credentials can 322 help detect man-in-the-middle attacks. 324 There is a risk of too promiscuous, or even rogue, CAs being 325 included in the list of acceptable CAs that the TLS server sends the 326 client as part of the TLS client-authentication handshake and 327 lending the appearance of trust to certificates signed by those CAs. 328 Periodic monitoring of the list of CAs that IIIDAP servers trust for 329 client authentication can help reduce this risk. 331 The Transport Layer Security protocol [RFC8446] includes a null 332 cipher suite that does not encrypt data and thus does not provide 333 data confidentiality. This option MUST NOT be used when data 334 confidentiality services are needed. Additional considerations for 335 secure use of TLS are described in [RFC7525]. 337 Data integrity services are sometimes mistakenly associated with 338 directory service operational policy requirements focused on data 339 accuracy. "Accuracy" refers to the truthful association of data 340 elements (such as names, addresses, and telephone numbers). Accuracy 341 requirements are out of scope for this protocol. 343 Additional security considerations are described in the 344 specifications for HTTP [RFC9110], HTTP Basic and Digest access 345 authentication [RFC9110], HTTP over TLS [RFC9110], and additional 346 HTTP status codes [RFC6585]. 348 6. IANA Considerations 350 7. References 352 References to IIIDAP are subject to the latest edition. 354 7.1. Normative References 356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", BCP 14, RFC 2119, March 1997, 358 . 360 [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status 361 Codes", RFC 6585, April 2012, 362 . 364 [RFC9110] Fielding, R., Ed., M. Nottingham, Ed. and J. Reschke, Ed., 365 " HTTP Semantics", RFC 9110, June 2022, 366 . 368 7.2. Informative References 370 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 371 Denial-of-Service Considerations", RFC 4732, December 372 2006, . 374 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 375 36, RFC 4949, August 2007, 376 . 378 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 379 Housley, R., and W. Polk, "Internet X.509 Public Key 380 Infrastructure Certificate and Certificate Revocation List 381 (CRL) Profile", RFC 5280, May 2008, 382 . 384 [RFC8446] E. Rescorla, "The Transport Layer Security (TLS) Protocol 385 Version 1.3", RFC 8446, August 2018, 386 . 388 [RFC7525] Y. Sheffer, R. Holz and P. Saint-Andre "Recommendations 389 for Secure Use of Transport Layer Security (TLS) and 390 Datagram Transport Layer Security (DTLS)", RFC 7525, May 391 2015, 392 . 394 [IDENTIFIER-RESPONSES] 395 Ma, C., "JSON Responses for the Industrial Internet 396 Identifier Data Access Protocol (IIIDAP)", Work in 397 Progress, draft-mcd-identifier-access-responce, December 398 2022. 400 Authors' Addresses 402 Chendi Ma 403 CAICT 404 No.52 Huayuan North Road, Haidian District 405 Beijing, Beijing, 100191 406 China 408 Phone: +86 177 1090 9864 409 Email: machendi@caict.ac.cn 411 Chen Jian 412 CAICT 413 No.52 Huayuan North Road, Haidian District 414 Beijing, Beijing, 100191 415 China 417 Phone: +86 138 1103 3332 418 Email: chenjian3@caict.ac.cn 420 Xiaotian Fan 421 CAICT 422 No.52 Huayuan North Road, Haidian District 423 Beijing, Beijing, 100191 424 China 426 Phone: +86 134 0108 6945 427 Email: fanxiaotian@caict.ac.cn 429 Meilan Chen 430 CAICT 431 No.52 Huayuan North Road, Haidian District 432 Beijing, Beijing, 100191 433 China 435 Phone: +86 139 1143 7301 436 Email: chenmeilan@caict.ac.cn 437 Zhiping Li 438 CAICT 439 No.52 Huayuan North Road, Haidian District 440 Beijing, Beijing, 100191 441 China 443 Phone: +86 185 1107 1386 444 Email: lizhiping@caict.ac.cn