idnits 2.17.1 draft-mcd-identifier-access-security-02.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 (July 13, 2020) is 1376 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'OpenID' is defined on line 379, 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 Summary: 3 errors (**), 0 flaws (~~), 3 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: Informational X. Fan 4 Expires: January 13, 2021 M. Chen 5 Z. Li 6 China Academy of Information and Communications Technology 7 July 13, 2020 9 Security Services for the Industrial Internet Identifier Data Access 10 Protocol (IIIDAP) 11 draft-mcd-identifier-access-security-02 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 January 13, 2021. 36 Copyright Notice 38 Copyright (c) 2020 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 specified in "Hypertext Transfer Protocol (HTTP/1.1): 147 Authentication" [RFC7235]. The "basic" scheme can be used to send a 148 client's user name and password to a server in plaintext, base64- 149 encoded form. The "digest" scheme can be used to authenticate a 150 client without exposing the client's plaintext password. If the 151 "basic" scheme is used, HTTP over TLS [RFC2818] MUST be used to 152 protect the client's credentials from disclosure while in transit 153 (see Section 3.5). 155 Servers MUST support either Basic or Digest authentication; they are 156 not required to support both. Clients MUST support both to 157 interoperate with servers that support one or the other. Servers may 158 provide a login page that triggers HTTP authentication. Clients 159 should continue sending the HTTP authentication header once they 160 receive an initial 401 (Unauthorized) response from the HTTP server 161 as long as the scheme portion of the URL doesn't change. 163 The Transport Layer Security protocol [RFC5246] includes an optional 164 feature to identify and authenticate clients who possess and present 165 a valid X.509 digital certificate [RFC5280]. Support for this 166 feature is OPTIONAL. 168 IIIDAP does not impose any unique server authentication 169 requirements. The server authentication provided by TLS fully 170 addresses the needs of IIIDAP. In general, transports for IIIDAP 171 must either provide a TLS-protected transport (e.g., HTTPS) or a 172 mechanism that provides an equivalent level of server 173 authentication. 175 Work on HTTP authentication methods continues. IIIDAP is designed to 176 be agile enough to support additional methods as they are defined. 178 3.3. Authorization 180 Server operators MAY offer varying degrees of access depending on 181 policy and need in conjunction with the authentication methods 182 described in Section 3.2. If such varying degrees of access are 183 supported, an IIIDAP server MUST provide granular access controls 184 (that is, per identifier metadata) in order to implement 185 authorization policies. Some examples: 187 - Clients will be allowed access only to data for which they have a 188 relationship. 190 - Unauthenticated or anonymous access status may not yield any 191 contact information. 193 - Full access may be granted to a special group of authenticated 194 clients. 196 The type of access allowed by a server will most likely vary from 197 one operator to the next. A description of the response privacy 198 considerations associated with different levels of authorization can 199 be found in Section 13 of [IDENTIFIER-RESPONSES]. 201 3.4. Availability 203 An IIIDAP service has to be available to be useful. There are no 204 IIIDAP-unique requirements to provide availability, but as a general 205 security consideration, a service operator needs to be aware of the 206 issues associated with denial of service. A thorough reading of 207 "Internet Denial-of-Service Considerations" [RFC4732] is advised. 209 An IIIDAP service MAY use an HTTP throttling mechanism to limit the 210 number of queries that a single client can send in a given period of 211 time. If used, the server SHOULD return an HTTP 429 (Too Many 212 Requests) response code as described in "Additional HTTP Status 213 Codes" [RFC6585]. A client that receives a 429 response SHOULD 214 decrease its query rate and honor the Retry-After header field if 215 one is present. Note that this is not a defense against denial-of- 216 service attacks, since a malicious client could ignore the code and 217 continue to send queries at a high rate. A server might use another 218 response code if it did not wish to reveal to a client that rate 219 limiting is the reason for the denial of a reply. 221 3.5. Data Confidentiality 223 IIIDAP uses HTTP over TLS [RFC2818] to provide that protection by 224 encrypting all traffic sent on the connection between client and 225 server. HTTP over TLS MUST be used to protect all client-server 226 exchanges unless operational constraints make it impossible to meet 227 this requirement. It is also possible to encrypt discrete objects 228 (such as command path segments and JSON- encoded response objects) 229 at one endpoint, send them to the other endpoint via an unprotected 230 transport protocol, and decrypt the object on receipt. Encryption 231 algorithms as described in "Internet Security Glossary, Version 2" 232 [RFC4949] are commonly used to provide data confidentiality at the 233 object level. 235 There are no current requirements for object-level data 236 confidentiality using encryption. Support for this feature could be 237 added to IIIDAP in the future. 239 As noted in Section 3.2, the HTTP "basic" authentication scheme can 240 be used to authenticate a client. When this scheme is used, HTTP 241 over TLS MUST be used to protect the client's credentials from 242 disclosure while in transit. If the policy of the server operator 243 requires encryption to protect client-server data exchanges (such as 244 to protect non-public data that cannot be accessed without client 245 identification and authentication), HTTP over TLS MUST be used to 246 protect those exchanges. 248 A description of privacy threats that can be addressed with 249 confidentiality services can be found in Section 4. Section 13 of 250 [IDENTIFIER-RESPONSES] describes status values that can be used to 251 describe operator actions used to protect response data from 252 disclosure to unauthorized clients. 254 3.6. Data Integrity 256 Web services such as IIIDAP commonly use HTTP over TLS [RFC2818] to 257 provide that protection by using a keyed Message Authentication Code 258 (MAC) to detect modifications. It is also possible to sign discrete 259 objects (such as command path segments and JSON-encoded response 260 objects) at one endpoint, send them to the other endpoint via a 261 transport protocol, and validate the signature of the object on 262 receipt. Digital signature algorithms as described in "Internet 263 Security Glossary, Version 2" [RFC4949] are commonly used to provide 264 data integrity at the object level. 266 There are no current requirements for object-level data integrity 267 using digital signatures. Support for this feature could be added to 268 IIIDAP in the future. 270 The most specific need for this service is to provide assurance that 271 HTTP 30x redirection hints [RFC7231] and response elements returned 272 from the server are not modified while in transit. If the policy of 273 the server operator requires message integrity for client-server 274 data exchanges, HTTP over TLS MUST be used to protect those 275 exchanges. 277 4. Privacy Threats Associated with Industrial Internet Identifier Data 279 The identifiers' information of ELN SHOULD be uploaded to SLN. The 280 standardization of IIIDAP does not change or impact the data that 281 operators of SLN may require to be collected from ELN, but it 282 provides support for a number of mechanisms that may be used to 283 mitigate privacy threats to ELN should SLN choose to use them. 285 IIIDAP includes mechanisms that can be used to authenticate clients, 286 allowing servers to support tiered access based on local policy. 287 This means that all identifier data need no longer be public, and 288 personal data or data that may be considered more sensitive can have 289 its access restricted to specifically privileged clients. 291 IIIDAP data structures allow servers to indicate via status values 292 when data returned to clients has been made private, redacted, 293 obscured, by a proxy. "Private" means that the data is not 294 designated for public consumption. "Redacted" means that some 295 identifier data fields are not being made available. "Obscured" 296 means that data has been altered for the purposes of not readily 297 revealing the actual identifier information. 299 In addition to privacy risks to the information of identifiers, 300 there are also potential privacy risks for those who query 301 identifier data. For example, the fact that a SLN employee performs 302 a particular query may reveal information about the employee's 303 activities that he or she would have preferred to keep private. 304 IIIDAP supports the use of HTTP over TLS to provide privacy 305 protection for those querying identifier data, unless operational 306 constraints make it impossible to meet this requirement. 308 5. Security Considerations 310 This document describes the security services provided by IIIDAP and 311 associated protocol layers, including authentication, authorization, 312 availability, data confidentiality, and data integrity. 314 As an HTTP-based protocol, IIIDAP is susceptible to code injection 315 attacks. Code injection refers to adding code into a computer system 316 or program to alter the course of execution. There are many types of 317 code injection, including SQL injection, dynamic variable or 318 function injection, include-file injection, shell injection, and 319 HTML-script injection, among others. Data confidentiality and 320 integrity services provide a measure of defense against man-in-the- 321 middle injection attacks, but vulnerabilities in both client- and 322 server-side software make it possible for injection attacks to 323 succeed. Consistently checking and validating server credentials can 324 help detect man-in-the-middle attacks. 326 There is a risk of too promiscuous, or even rogue, CAs being 327 included in the list of acceptable CAs that the TLS server sends the 328 client as part of the TLS client-authentication handshake and 329 lending the appearance of trust to certificates signed by those CAs. 330 Periodic monitoring of the list of CAs that IIIDAP servers trust for 331 client authentication can help reduce this risk. 333 The Transport Layer Security protocol [RFC5246] includes a null 334 cipher suite that does not encrypt data and thus does not provide 335 data confidentiality. This option MUST NOT be used when data 336 confidentiality services are needed. Additional considerations for 337 secure use of TLS are described in [SECURE-TLS-DTLS]. 339 Data integrity services are sometimes mistakenly associated with 340 directory service operational policy requirements focused on data 341 accuracy. "Accuracy" refers to the truthful association of data 342 elements (such as names, addresses, and telephone numbers). Accuracy 343 requirements are out of scope for this protocol. 345 Additional security considerations are described in the 346 specifications for HTTP [RFC7231], HTTP Basic and Digest access 347 authentication [RFC7235], HTTP over TLS [RFC2818], and additional 348 HTTP status codes [RFC6585]. 350 6. IANA Considerations 352 7. References 354 References to IIIDAP are subject to the latest edition. 356 7.1. Normative References 358 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 359 Requirement Levels", BCP 14, RFC 2119, March 1997, 360 . 362 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000, 363 . 365 [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status 366 Codes", RFC 6585, April 2012, 367 . 369 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 370 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 371 June 2014, . 373 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 374 Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014, 375 . 377 7.2. Informative References 379 [OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final", 380 December 2007, . 382 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 383 Denial-of-Service Considerations", RFC 4732, December 384 2006, . 386 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 387 36, RFC 4949, August 2007, 388 . 390 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 391 (TLS) Protocol Version 1.2", RFC 5246, August 2008, 392 . 394 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 395 Housley, R., and W. Polk, "Internet X.509 Public Key 396 Infrastructure Certificate and Certificate Revocation List 397 (CRL) Profile", RFC 5280, May 2008, 398 . 400 [SECURE-TLS-DTLS] 401 Sheffer, Y., Holz, R., and P. Saint-Andre, 402 "Recommendations for Secure Use of TLS and DTLS", Work in 403 Progress, draft-ietf-uta-tls-bcp-09, February 2015. 405 [IDENTIFIER-RESPONSES] 406 Ma, C., "JSON Responses for the Industrial Internet 407 Identifier Data Access Protocol (IIIDAP)", Work in 408 Progress, draft-mcd-identifier-access-responce, June 2020. 410 Authors' Addresses 412 Chendi Ma 413 CAICT 414 No.52 Huayuan North Road, Haidian District 415 Beijing, Beijing, 100191 416 China 418 Phone: +86 177 1090 9864 419 Email: machendi@caict.ac.cn 421 Chen Jian 422 CAICT 423 No.52 Huayuan North Road, Haidian District 424 Beijing, Beijing, 100191 425 China 427 Phone: +86 138 1103 3332 428 Email: chenjian3@caict.ac.cn 430 Xiaotian Fan 431 CAICT 432 No.52 Huayuan North Road, Haidian District 433 Beijing, Beijing, 100191 434 China 436 Phone: +86 134 0108 6945 437 Email: fanxiaotian@caict.ac.cn 439 Meilan Chen 440 CAICT 441 No.52 Huayuan North Road, Haidian District 442 Beijing, Beijing, 100191 443 China 445 Phone: +86 139 1143 7301 446 Email: chenmeilan@caict.ac.cn 447 Zhiping Li 448 CAICT 449 No.52 Huayuan North Road, Haidian District 450 Beijing, Beijing, 100191 451 China 453 Phone: +86 185 1107 1386 454 Email: lizhiping@caict.ac.cn