idnits 2.17.1 draft-yu-imap-client-id-01.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: As this extension provides an additional means of communicating information from a client to a server it is clear there is additional information divulged to the server. This may have privacy considerations depending on the client identity type or its contents. For example, it may reveal a MAC address of the device used to communicate with a server that would not previously have been revealed. While it has been useful to use identifier such as email address for authentication it is easy for these authetication tokens to be shared and/or reused and/or be publically available for other purposes. An IMAP server and or its operators SHOULD not share any CLIENTID information presented with a third party as it may represent or be linked to an individual and SHOULD never be shared in association with authentication tokens. -- The document date (November 19, 2018) is 1978 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Y. Deion 3 LinuxMagic 4 Intended Status: Standards Track 5 Expires May 19, 2018 November 19, 2018 7 IMAP Service Extension for Client Identity 8 10 Abstract 12 This document defines an Internet Message Access Protocol (IMAP) 13 service extension called "CLIENTID" which provides a method for 14 clients to indicate an identity to the server. 16 This identity is an additional token that may be used for security 17 and/or informational purposes, and with it a server may optionally 18 apply heuristics using this token. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. Internet-Drafts are working 24 documents of the Internet Engineering Task Force (IETF), its areas, 25 and its working groups. Note that other groups may also distribute 26 working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction ................................................. 2 57 2. Conventions Used in This Document ............................ 3 58 3. CLIENTID ..................................................... 3 59 3.1. CLIENTID Command ......................................... 3 60 3.2. CLIENTID Arguments ....................................... 3 61 3.3. Advertising the CLIENTID capability ....................... 4 62 3.4. Restrictions on the CLIENTID command ...................... 4 63 4. Formal Syntax ................................................ 4 64 5. Discussion ................................................... 5 65 5.1. Applying heuristics to CLIENTID ........................... 5 66 5.2. Utility of CLIENTID ....................................... 5 67 5.3. Use Cases of CLIENTID ..................................... 6 68 5.4. Other IMAP Client Identifiers ............................. 6 69 5.5. Future Considerations ..................................... 7 70 6. Client Identity Types ........................................ 7 71 7. Examples ..................................................... 8 72 7.1. UUID as Client Identity .................................. 8 73 7.2. Malformed CLIENTID Command ............................... 8 74 7.3. Client Identity Without a TLS/SSL Session ................ 9 75 7.4. Client Identity Leading to Rejection ..................... 9 76 8. Security Considerations ...................................... 9 77 9. IANA Considerations .......................................... 10 78 10. References ................................................... 10 79 10.1. Normative References ..................................... 10 80 Contributors ..................................................... 10 81 Authors' Addresses ............................................... 10 83 1. Introduction 85 The [IMAP] protocol and its extensions describe methods whereby an 86 client may provide identity and/or authentication information to 87 an IMAP server. However, these existing methods are subject to 88 limitations and none offer a way to identify the IMAP client with 89 absolute confidence. This document defines an IMAP service extension 90 to provide an additional identity token which can represent the IMAP 91 client with a higher degree of certainty when accessing the IMAP 92 server. 94 Typically IMAP clients enter the authenticated state by using either 95 the AUTHENTICATE or LOGIN command. IMAP servers are often subject to 96 malicious clients attempting to use authorization credentials and/or 97 identities not intended for their use (e.g. stolen credentials or 98 brute force attacks). When such an attack is attempted, the IMAP 99 server may be unable to identify the impersonation and restrict such 100 an unintended use by someone other than the authorized user or said 101 credentials. While there are ways to identify the source of the IMAP 102 client such as its IP address, it would be useful if there was an 103 additional way to uniquely identify the client in a method solely 104 available across an encrypted channel. 106 Using the CLIENTID extension, an IMAP client can provide an 107 additional identity token to the server called its "client identity". 109 The client identity can provide unique characteristics about the 110 client accessing the IMAP service and may be combined with existing 111 identification mechanisms in order to identify the client. An IMAP 112 server may then apply additional security policies using this 113 identity such as restricting use of the service to clients presenting 114 recognized client identities or only allowing use of authorized 115 identities that match previously established client identities. 117 The CLIENTID extension is present in any IMAP implementation that 118 returns "CLIENTID" as one of the supported capabilities to the 119 CAPABILITY command. 121 2. Conventions Used in This Document 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [KEYWORDS]. 127 Formal syntax is specified using [ABNF]. 129 Example lines prefaced by "C:" are sent by the client and ones 130 prefaced by "S:" by the server. 132 "Connection" refers to the entire sequence of client/server 133 interaction from the initial establishment of the network connection 134 until its termination. 136 3. CLIENTID 138 3.1. CLIENTID Command 140 Arguments: client identity type 141 client identity token 143 Responses: no specific responses for this command 145 Result: OK - clientid completed, client identity stored 146 BAD - command unknown or arguments invalid 148 Note that a valid CLIENTID command will never return the NO result 149 because heuristics MUST NOT be applied to the CLIENTID arguments at 150 this stage. Instead the client identity information SHOULD be stored 151 and passed along to any and all [SASL] authentication mechanisms. 153 3.2. CLIENTID Arguments 155 The CLIENTID command takes the following two arguments: 157 1. client identity type: A string identifying the identity type the 158 client is providing. It MUST be between 1 and 16 alphanumeric 159 characters. 161 2. client identity token: A string identifying the client. It MUST 162 be between 1 and 128 printable characters. 164 The IMAP server MUST reject any CLIENTID command with badly formatted 165 arguments. The IMAP server MUST accept the arguments from a valid 166 CLIENTID command and SHOULD store it at the minimum for the remaining 167 duration of the IMAP connection. 169 3.3. Advertising the CLIENTID capability 171 The CLIENTID capability is used to tell the IMAP client that the IMAP 172 server supports the CLIENTID extension. However, certain conditions 173 MUST be met before the IMAP server advertises the CLIENTID 174 capability. 176 1. The IMAP server and IMAP client MUST negotiate encryption via 177 STARTTLS/SSL or some other secure mechanism. 179 2. The IMAP server MUST be in the non-authenticated state. 181 3. The IMAP server MUST have the CLIENTID extension support enabled. 183 While all the conditions are met, the IMAP server MUST advertise the 184 CLIENTID capability in all proceeding CAPABILITY commands. 186 3.4. Restrictions on the CLIENTID command 188 Under certain circumstances, the use of the CLIENTID command will be 189 restricted: 191 1. Before the CLIENTID capability has been advertised, the IMAP 192 server MUST reject any issued CLIENTID commmand and the IMAP 193 client MUST NOT issue the CLIENTID command. 195 2. Outside of the non-authenticated state, the IMAP server MUST 196 reject any CLIENTID command issued by the IMAP client and the IMAP 197 client MUST NOT issue the CLIENTID command. 199 3. Once a valid CLIENTID command has been issued, the IMAP server 200 MUST reject any further CLIENTID command issued by the IMAP client 201 and the IMAP client MUST NOT issue any subsequent CLIENTID 202 commands. 204 4. Formal Syntax 206 The following syntax specification uses the Augmented Backus-Naur 207 Form notation as specified in [ABNF]. [IMAP] defines the 208 non-terminals "capability" and "command-nonauth". 210 Except as noted otherwise, all alphabetic characters are case- 211 insensitive. The use of upper or lower case characters to define 212 token strings is for editorial clarity only. Implementations MUST 213 accept these strings in a case-insensitive fashion. 215 capability =/ "CLIENTID" 217 command-nonauth =/ client-id 218 client-id = "CLIENTID" SP client-id-type SP client-id-token 220 client-id-type = 1*16 ALPHA / DIGIT 221 ;; alphanumeric 223 client-id-token = 1*128 VCHAR 224 ;; any printable US-ASCII character 226 5. Discussion 228 5.1. Applying heuristics to CLIENTID 230 This section discusses the possible heuristics that can be applied to 231 the information that is presented via the CLIENTID command. This 232 information includes whether a valid CLIENTID command was issued, the 233 client identity type and the client identity token. 235 1. The IMAP server MAY choose to require that a successful CLIENTID 236 command be issued or that a particular client identity type be 237 presented. 239 2. The IMAP server MAY reject any CLIENTID command with a client 240 identity type that is not recognized by the IMAP server. 242 3. The IMAP server MAY reject any CLIENTID command with a client 243 identity type that is not supported by the IMAP server. 245 4. An IMAP server MAY reject any CLIENTID command that contains a 246 client identity type or client identity token that the server 247 chooses not to accept for any reason such as by policy. 249 5. An IMAP server MAY reject any CLIENTID command that contains a 250 client identity type or client identity that the server has chosen 251 to disable or revoke use of either temporarily or permanently. 253 The IMAP server SHOULD only ever reject an IMAP client based on 254 CLIENTID information during or after the authentication 255 process/handler. In the interest of limiting the amount of 256 information being revealed, the rejection message SHOULD be as generic 257 as possible and SHOULD NOT reveal any information on the heuristics. 259 Even if the client identity type and/or client identity token are not 260 recognized, supported or permitted by the server and/or the owner of 261 the authentication credentials, the presented information may still be 262 useful for analysis. 264 5.2. Utility of CLIENTID 266 Regardless of how much it is frowned upon, common authorization 267 information like the username and password pair are reused across 268 multiple web services. When this authorization is compromised on a 269 single web service, malicious actors usually also gain access to 270 other web services. Based on this information alone, the utility of 271 CLIENTID as an additional layer of authentication that is only 272 available across an encrypted channel becomes more apparent. 274 The utility of CLIENTID may be seen by considering the following: 276 1. An IMAP client may utilize the same IMAP server with multiple 277 different authorized identities, so an identity that persists 278 across authorized identities is lacking. 280 2. An authorized identity may make use of multiple discrete devices 281 over different IMAP sessions, so an identity persisting on one 282 device is lacking. 284 3. Existing identity information available from the connection such 285 as network address or IP changes frequently as devices are 286 becoming more mobile in nature. 288 4. Individual IMAP services have no method to determine if devices 289 types should be permitted e.g. private IMAP services that do not 290 persist across different connections. 292 5. There is no method for legacy authentication methods to associate 293 a given set of authentication tokens to an individual and or that 294 individuals registered devices. 296 5.3. Use Cases of CLIENTID 298 With CLIENTID the IMAP server has additional information it may use 299 in its interactions with the client. It may: 301 1. Restrict use of an authorization tokens to a set of client 302 identities, thereby offering an added level of security. For 303 example the use of an authorization token may only be accompanied 304 by a specified set of CLIENTID tokens and/or types. 306 2. Identify that the same CLIENTID token is used to access multiple 307 authorized identities, and restrict access to the IMAP service. 308 For example a malicious client that has attempted to gain access 309 using multiple authorization tokens may be identified through its 310 unusual behavior. 312 3. Retain knowledge of CLIENTID tokens previously presented with 313 specific authorization credentials, and if the token has not been 314 previously seen, restrict access to the IMAP service. 316 4. Require that the IMAP client present a token such as a license key 317 established outside of the IMAP session in order to make use of 318 any authorized identity. 320 5. Apply different security policies to clients that provide a 321 CLIENTID token versus those which do not. For example, provide 322 clients providing such an identity with additional trust. 324 5.4. Other IMAP Client Identifiers 326 The [IMAP] protocol and its extensions describe methods whereby an 327 IMAP client may provide identity information to an IMAP server. Some 328 of these identitiers are listed for contrast: 330 1. The client connection provides a source IP address associated 331 with the IMAP session. This may be accompanied by a PTR record 332 and/or GeoIP information. 334 2. The AUTHENTICATE and LOGIN command allows the client to present 335 a user and/or password/authentication mechanism for an IMAP 336 session. 338 5.5. Future Considerations 340 In the future there may be a demand for being able to provide 341 multiple CLIENTID commands with different client identity types. 343 6. Client Identity Types 345 This document does not specify any CLIENTID identity type that MUST 346 be supported. Some examples of identity type are UUID, LICENSE, 347 DEVICE_ID, MAC and COOKIE. To start with certain types such as UUID 348 and LICENSE SHOULD be supported. It is intended that any CLIENTID 349 type be accepted but in the future standards on types may be set but 350 a IMAP server SHOULD NOT reject an unidentified CLIENTID type, except 351 for specific policy use cases. 353 It is envisioned that in the future it will be useful to propose 354 identity types to support. 356 1. UUID 358 UUID is a common practice to represent either a individual user, 359 hardware device or software installation associated with a 360 specific individual. The support of UUID enables existing UUID 361 implementations to be used to semi-uniquely identify a device 362 associated with an individual. 364 2. LICENSE 366 An IMAP client may find it useful to identify the license key of 367 software it is using. Such licenses are typically crafted such 368 that they are unique and useful to identify a software 369 installation. 371 3. DEVICE_ID 373 Many hardware devices are designed to be used by a single 374 individual and already have an associated hardware device id. 376 4. MAC 378 The MAC address is not always available or consistent. However, 379 for certain use cases the MAC may be the only information 380 available to specify a specific device. 382 5. COOKIE 384 While not guranteed to be consistent many web applications are 385 designed to access IMAP directly and may need to have a 386 semi-unique identifier available as part of the web based 387 transaction. 389 This document recommends that an IMAP server handle any given client 390 identity type from a CLIENTID command in one or more of the following 391 manners. 393 1. Handled but treat as not presented 394 2. Store in session but treat as not presented (useful for debugging) 395 3. System log 396 4. User log 397 5. Use for authentication 398 6. Use for alert when authentication fails 399 7. Use for alert when authentication succeeds 400 8. Unused 402 7. Examples 404 7.1. UUID as Client Identity 406 C: [connection established over a plaintext connection] 407 C: a001 CAPABILITY 408 S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI LOGINDISABLED 409 S: a001 OK CAPABILITY completed 410 C: a002 STARTTLS 411 S: a002 OK STARTLS completed 412 413 C: a003 CAPABILITY 414 S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN CLIENTID 415 S: a003 OK CAPABILITY completed 416 C: a004 CLIENTID UUID 23bf83be-aad7-46aa-9e0f-39191ccf402f 417 S: a004 OK CLIENTID completed 418 C: a005 LOGIN joe password 419 S: a005 OK LOGIN completed 421 7.2. Malformed CLIENTID Command 423 C: [connection established over a plaintext connection] 424 C: a001 CAPABILITY 425 S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI LOGINDISABLED 426 S: a001 OK CAPABILITY completed 427 C: a002 STARTTLS 428 S: a002 OK STARTLS completed 429 430 C: a003 CAPABILITY 431 S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN CLIENTID 432 S: a003 OK CAPABILITY completed 433 C: a004 CLIENTID UUID 434 S: a004 BAD Error in IMAP command received by server 435 The IMAP server rejects the CLIENTID command as it is not well 436 formed due to there being only a single parameter provided. 438 7.3. Client Identity without TLS/SSL Session 440 C: [connection established over a plaintext connection] 441 C: a001 CAPABILITY 442 S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI LOGINDISABLED 443 S: a001 OK CAPABILITY completed 444 C: a002 CLIENTID UUID 23bf83be-aad7-46aa-9e0f-39191ccf402f 445 S: a002 BAD Unknown IMAP command received by server 447 The IMAP server rejects use of the CLIENTID command as the CLIENTID 448 capability had not been advertised because no encryption was 449 negotiated between the IMAP server and IMAP client. 451 7.4. Client Identity Leading to Rejection 453 C: [connection established over a plaintext connection] 454 C: a001 CAPABILITY 455 S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI LOGINDISABLED 456 S: a001 OK CAPABILITY completed 457 C: a002 STARTTLS 458 S: a002 OK STARTLS completed 459 460 C: a003 CAPABILITY 461 S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN CLIENTID 462 S: a003 OK CAPABILITY completed 463 C: a004 CLIENTID UUID 23bf83be-aad7-46aa-9e0f-39191ccf402f 464 S: a004 OK CLIENTID completed 465 C: a005 LOGIN joe password 466 S: a005 BAD Failed to authenticate 468 The IMAP server rejects use of the system during the LOGIN command 469 after deciding that the provided client identity does not establish 470 sufficient privileges. Note that the error message that's returned 471 to the client is very generic and does not reveal any information 472 about CLIENTID and/or the existence of 'joe' and/or the validity of 473 the password. 475 8. Security Considerations 477 As this extension provides an additional means of communicating 478 information from a client to a server it is clear there is additional 479 information divulged to the server. This may have privacy 480 considerations depending on the client identity type or its contents. 481 For example, it may reveal a MAC address of the device used to 482 communicate with a server that would not previously have been 483 revealed. While it has been useful to use identifier such as email 484 address for authentication it is easy for these authetication tokens 485 to be shared and/or reused and/or be publically available for other 486 purposes. An IMAP server and or its operators SHOULD not share 487 any CLIENTID information presented with a third party as it may 488 represent or be linked to an individual and SHOULD never be shared in 489 association with authentication tokens. 491 As well, while this service extension requires that the identity 492 information only be transmitted over an encrypted channel to reduce 493 the risk of eavesdropping, it does not specify any policies or 494 practices required in the establishment of such a channel, and so it 495 is the responsibility of the client and the server to determine that 496 the communication medium meets their requirements. 498 9. IANA Considerations 500 The IANA is requested to add CLIENTID to the "IMAP 4 Capabilities" 501 registry, http://www.iana.org/assignments/imap4-capabilities. 503 10. References 505 10.1. Normative References 507 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for 508 Syntax Specifications: ABNF", RFC 2234, 509 November 1997. 511 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 512 4rev1", RFC 3501, March 2003. 514 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", BCP 14, RFC 2119, DOI 516 10.17487/RFC2119, March 1997, . 519 [SASL] Myers, J., "Simple Authentication and Security 520 Layer (SASL)", RFC 2222, October 1997. 522 [TLS] Dierks, T. and C. Allen, "The TLS Protocol 523 Version 1.0", RFC 2246, January 1999. 525 Contributors 527 Michael Peddemors 528 LinuxMagic 530 Authors' Addresses 532 Deion Yu 533 LinuxMagic 534 #405 - 860 Homer St. 535 Vancouver, British Columbia 536 CA V6B 2W5 538 EMail: deiony@linuxmagic.com