idnits 2.17.1 draft-yu-imap-client-id-06.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. 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 (May 25, 2021) is 1039 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: 5 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 November 25, 2021 May 25, 2021 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. Background ............................................... 5 66 5.2. Applying heuristics to CLIENTID .......................... 6 67 5.3. Utility of CLIENTID ...................................... 6 68 5.4. Use Cases of CLIENTID .................................... 7 69 5.5. Other IMAP Client Identifiers ............................ 8 70 5.6. Future Considerations .................................... 8 71 6. Client Identity Types ........................................ 8 72 7. Examples ..................................................... 10 73 7.1. UUID as Client Identity .................................. 10 74 7.2. Malformed CLIENTID Command ............................... 11 75 7.3. Client Identity Without a TLS/SSL Session ................ 11 76 7.4. Client Identity Leading to Rejection ..................... 11 77 8. Security Considerations ...................................... 12 78 9. IANA Considerations .......................................... 12 79 10. References ................................................... 12 80 10.1. Normative References ..................................... 12 81 Appendix A. CLIENTID Product Support ............................ 13 82 Contributors ..................................................... 13 83 Authors' Addresses ............................................... 13 85 1. Introduction 87 The [IMAP] protocol and its extensions describe methods whereby an 88 client may provide identity and/or authentication information to 89 an IMAP server. However, these existing methods are subject to 90 limitations and none offer a way to identify the IMAP client with 91 absolute confidence. This document defines an IMAP service extension 92 to provide an additional identity token which can represent the IMAP 93 client with a higher degree of certainty when accessing the IMAP 94 server. 96 Typically IMAP clients enter the authenticated state by using either 97 the AUTHENTICATE or LOGIN command. IMAP servers are often subject to 98 malicious clients attempting to use authorization credentials and/or 99 identities not intended for their use (e.g. stolen credentials or 100 brute force attacks). When such an attack is attempted, the IMAP 101 server may be unable to identify the impersonation and restrict such 102 an unintended use by someone other than the authorized user or said 103 credentials. While there are ways to identify the source of the IMAP 104 client such as its IP address, it would be useful if there was an 105 additional way to uniquely identify the client in a method solely 106 available across an encrypted channel. 108 Using the CLIENTID extension, an IMAP client can provide an 109 additional identity token to the server called its "client identity". 110 The client identity can provide unique characteristics about the 111 client accessing the IMAP service and may be combined with existing 112 identification mechanisms in order to identify the client. An IMAP 113 server may then apply additional security policies using this 114 identity such as restricting use of the service to clients presenting 115 recognized client identities or only allowing use of authorized 116 identities that match previously established client identities. 118 The CLIENTID extension is present in any IMAP implementation that 119 returns "CLIENTID" as one of the supported capabilities to the 120 CAPABILITY command. 122 2. Conventions Used in This Document 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [KEYWORDS]. 128 Formal syntax is specified using [ABNF]. 130 Example lines prefaced by "C:" are sent by the client and ones 131 prefaced by "S:" by the server. 133 "Connection" refers to the entire sequence of client/server 134 interaction from the initial establishment of the network connection 135 until its termination. 137 3. CLIENTID 139 3.1. CLIENTID Command 141 Arguments: client identity type 142 client identity token 144 Responses: no specific responses for this command 146 Result: OK - clientid completed, client identity stored 147 BAD - command unknown or arguments invalid 149 Note that a valid CLIENTID command will never return the NO result 150 because heuristics MUST NOT be applied to the CLIENTID arguments at 151 this stage. Instead the client identity information SHOULD be stored 152 and passed along to any and all [SASL] authentication mechanisms. 154 3.2. CLIENTID Arguments 156 The CLIENTID command takes the following two arguments: 158 1. client identity type: A string identifying the identity type the 159 client is providing. It MUST be between 1 and 16 alphanumeric 160 and dash characters. 162 2. client identity token: A string identifying the client. It MUST 163 be between 1 and 128 printable characters. 165 The IMAP server MUST reject any CLIENTID command with badly formatted 166 arguments. The IMAP server MUST accept the arguments from a valid 167 CLIENTID command and SHOULD store it at the minimum for the remaining 168 duration of the IMAP connection. 170 3.3. Advertising the CLIENTID capability 172 The CLIENTID capability is used to tell the IMAP client that the IMAP 173 server supports the CLIENTID extension. However, certain conditions 174 MUST be met before the IMAP server advertises the CLIENTID 175 capability. 177 1. The IMAP server and IMAP client MUST negotiate encryption via 178 STARTTLS/SSL or some other secure mechanism. 180 2. The IMAP server MUST be in the non-authenticated state. 182 3. The IMAP server MUST have the CLIENTID extension support enabled. 184 While all the conditions are met, the IMAP server MUST advertise the 185 CLIENTID capability in all proceeding CAPABILITY commands. 187 3.4. Restrictions on the CLIENTID command 189 Under certain circumstances, the use of the CLIENTID command will be 190 restricted: 192 1. Before the CLIENTID capability has been advertised, the IMAP 193 server MUST reject any issued CLIENTID commmand and the IMAP 194 client MUST NOT issue the CLIENTID command. 196 2. Outside of the non-authenticated state, the IMAP server MUST 197 reject any CLIENTID command issued by the IMAP client and the IMAP 198 client MUST NOT issue the CLIENTID command. 200 3. Once a valid CLIENTID command has been issued, the IMAP server 201 MUST reject any further CLIENTID command issued by the IMAP client 202 and the IMAP client MUST NOT issue any subsequent CLIENTID 203 commands. 205 4. Formal Syntax 207 The following syntax specification uses the Augmented Backus-Naur 208 Form notation as specified in [ABNF]. [IMAP] defines the 209 non-terminals "capability" and "command-nonauth". 211 Except as noted otherwise, all alphabetic characters are case- 212 insensitive. The use of upper or lower case characters to define 213 token strings is for editorial clarity only. Implementations MUST 214 accept these strings in a case-insensitive fashion. 216 capability =/ "CLIENTID" 218 command-nonauth =/ client-id 220 client-id = "CLIENTID" SP client-id-type SP client-id-token 222 client-id-type = 1*16 ALPHA / DIGIT / "-" 223 ;; alphanumeric with dash character 225 client-id-token = 1*128 VCHAR 226 ;; any printable US-ASCII character 228 5. Discussion 230 5.1 Background 232 The historical standard of using the user and password combination as 233 a means of authentication is no longer effective in this day and age 234 with recent developments in the world. 236 1. ISPs transistioning to Carrier-grade NAT due to IPv4 address 237 exhaustion placing multiple devices behind the same IP address. 239 2. Numerous large scale data breaches exposing millions of user and 240 password combinations. 242 3. Continued propensity for user to use same simple passwords across 243 multiple accounts. 245 4. Botnets growing larger and more sophisticated due to the 246 profileration of IoT devices. 248 As a result, brute force attacks against web services have become 249 increasingly effective as malicious actors have easy access to 250 millions of email addresses, commonly used passwords and massive 251 botnets while the safety practices of users have not improved. 253 The traditional methods of defending against these types of attacks 254 like rate limiting and blocking by IP addresses are no longer viable 255 without collateral damange as thousands of devices could potentially 256 be behind the same IP address as more ISPs adopt the CGN/LSN/NAT444 257 standard, i.e. blocking an IP address due to the actions of a single 258 malicious actor bears the risk of blocking legitimate users. 260 By introducing CLIENTID as another non-public factor to be used in 261 tandem with the user and password combination, authentication becomes 262 much more resilient against brute force attacks. The email addresses 263 and passwords exposed from the data breaches will no longer be 264 sufficient to authenticate. Rate limiting and blocking can be 265 performed based on the CLIENTID such that only a subset of devices 266 behind the same IP address gets blocked. CLIENTID would also be 267 backwards compatible with existing authentication protocols 268 encouraging adoption. 270 5.2. Applying heuristics to CLIENTID 272 This section discusses the possible heuristics that can be applied to 273 the information that is presented via the CLIENTID command. This 274 information includes whether a valid CLIENTID command was issued, the 275 client identity type and the client identity token. 277 1. The IMAP server MAY choose to require that a successful CLIENTID 278 command be issued or that a particular client identity type be 279 presented before processing or accepting an authentication 280 request. 282 2. The IMAP server MAY reject any authentication request not preceded 283 with a client identity type that matches ACL's or rules as defined 284 in the IMAP server. 286 3. An IMAP server MAY reject any authentication request preceded by a 287 CLIENTID command that contains a client identity type or client 288 identity token that the server chooses not to accept for any 289 reason such as by policy. 291 4. An IMAP server MAY reject any authentication request preceded by a 292 CLIENTID command that contains a client identity type or client 293 identity token that the server has chosen to disable or revoke use 294 of either temporarily or permanently. 296 The IMAP server SHOULD only ever reject an IMAP client based on 297 CLIENTID information during or after the authentication 298 process/handler. In the interest of limiting the amount of 299 information being revealed, the rejection message SHOULD be as generic 300 as possible and SHOULD NOT reveal any information on the heuristics. 302 Even if the client identity type and/or client identity token are not 303 recognized, supported or permitted by the server and/or the owner of 304 the authentication credentials, the presented information may still be 305 useful for analysis. 307 5.3. Utility of CLIENTID 309 Regardless of how frowned upon, users commonly reuse authorization 310 information (like the username and password pair) across multiple 311 services. When one service is compromised, malicious actors can also 312 gain access to other services where the user also used the same 313 credentials. Based on this representative problem alone, the utility 314 of CLIENTID as an additional layer of determining the rights to 315 present such authorization information becomes quickly apparent. 317 The utility of CLIENTID may be seen by considering the following: 319 1. An IMAP server could recognize a device not historically known to 320 have presented the authentication credentials before. 322 2. An IMAP server could restrict authentication from actors not 323 presenting a valid CLIENTID, or an account holder that the IMAP 324 server provides service for could restrict authentication to only 325 those devices that present valid CLIENTID. 327 3. An IMAP server could restrict authentication to only devices which 328 present a CLIENTID containing a client type identifier which the 329 account holder or operator of the server deems to be permitted. 330 (Eg. Only allow vendor A's devices) 332 4. An IMAP server could alert an account holder that an attempt to 333 present their authorization credentials came from an unknown, 334 unrecgonized, or different device. 336 However, this extends beyond just the restriction of authentication. 337 While it might be argued that this can be served as a special form 338 of SASL, by implementing this in the IMAP service itself, the IMAP 339 service can choose before allowing a connection to be passed to a 340 SASL implementation, allowing it to perform other heuristics, such 341 as brute force attacks, more effeciently. 343 While 'forgery' and/or the use of random client identifier is 344 possible, such behavior is also more readily detectable when a device 345 identifier is presented. 347 1. The IMAP server, when faced with hundreds of devices behind the 348 same IP address, during an attack can restrict authentication 349 attempts to only connections presenting a valid client identifier 350 token. 352 2. The IMAP server, during an attack, can restrict authentication to 353 only historically known devices. 355 3. The IMAP server can differentiate between many different devices 356 behind the same IP, and apply maximum connections per device, 357 rather than maximum connections per IP. 359 4. While a person may present authentication credentials from many 360 different geographical locations, eg, home, office, and travel, a 361 single device will not in general be able to be in two 362 geographical locations at the same time. The IMAP server will 363 have new information to apply to threat detection heuristics, ie 364 to treat the use of the same client indentifier token from 365 two locations, as a possible brute force or forgery situation. 367 5.4. Use Cases of CLIENTID 369 With CLIENTID the IMAP server has additional information it may use 370 in its interactions with the client. It may: 372 1. Restrict use of an authorization tokens to a set of client 373 identity token identities, thereby offering an added level 374 of security. For example the use of authorization credentials may 375 only be accompanied by a specified set of CLIENTID tokens and/or 376 types for a specific account holder, or set of account holders 378 2. Identify that the same CLIENTID token is used to access multiple 379 authorized identities, and restrict access to the IMAP service. 380 For example a malicious client that has attempted to gain access 381 using multiple authorization tokens may be identified through its 382 unusual behavior. 384 3. Retain knowledge of CLIENTID tokens previously presented with 385 specific authorization credentials, and if the token has not been 386 previously seen, restrict access to the IMAP service. 388 4. Require that the IMAP client present a token such as a license key 389 established outside of the IMAP session in order to make use of 390 any authorized identity. 392 5. Apply different security policies to clients that provide a 393 CLIENTID token versus those which do not. For example, provide 394 clients providing such an identity with additional trust. 396 6. Ability to rate limit or block based on the presented 397 client-identifier-token, when multiple devices use a shared IP 398 address, without affecting other devices. 400 7. Ability to detect distributed and localized dictionary attacks 401 and brute force attacks. 403 8. Use the client-indentifier-token as a third factor to be passed 404 to authentication methods. [SASL] 406 5.5. Other IMAP Client Identifiers 408 The [IMAP] protocol and its extensions describe methods whereby an 409 IMAP client may provide identity information to an IMAP server. Some 410 of these identitiers are listed for contrast: 412 1. The client connection provides a source IP address associated 413 with the IMAP session. This may be accompanied by a PTR record 414 and/or GeoIP information. 416 2. The AUTHENTICATE and LOGIN command allows the client to present 417 a user and/or password/authentication mechanism for an IMAP 418 session. 420 5.6. Future Considerations 422 In the future there may be a demand for being able to provide 423 multiple CLIENTID commands with different client identity types. 424 For instance, it may be desirable for a device to indentify itself, 425 both with a hardware device identifier, and a software identifier. 426 We believe this to be out of scope, and can be accomodated with a 427 special client-identifier-token which encapsulates both. 429 6. Client Identity Types 431 This document does not specify any CLIENTID identity type that MUST 432 be supported. The client identity type is meant to be defined by 433 the client implementation that is designed to access the IMAP server 434 and protocol. For instance, many IMAP client software 435 implementations already create a distinct UUID for each account. 436 Some commercial email clients have a license key. Some physical 437 devices that need to interact with IMAP might have a unique hardware 438 ID. While there is no pre-defined list of client identity type 439 defined by this RFC, and all IMAP servers should be prepared to 440 accept any form of client identity type that conforms to the 441 definition, it is suggested that IMAP client developers carefully 442 consider the name of the client identity type. For example, rather 443 that using a client identity type of UUID, consider the advantages of 444 making it more distinct, e.g. "UUID". This way 445 the IMAP server can better record histories, eg the difference 446 between say a Thunderbird generated unique id, and a Mutt generated 447 unique id. 449 Some examples of identity type might be UUID, LICENSE, DEVICE_ID, 450 and/or COOKIE. It is expected that the most common types might be 451 related to distinct UUID, LICENSEKEY, or HARDWAREID. 453 An IMAP server SHOULD NOT reject an unidentified CLIENTID type, except 454 for specific policy use cases. 456 It is envisioned that in the future it will be useful to propose 457 a set of standardized client-indentity-type to help with validation, 458 or to allow the IMAP server to apply ACL rules on expected types, 459 this would be an extension to this RFC. 461 1. UUID 463 UUID is a common practice to represent either a individual user, 464 hardware device or software installation associated with a 465 specific individual. The support of UUID enables existing UUID 466 implementations to be used to semi-uniquely identify a device 467 associated with an individual. A definition of the format should 468 be considered. Otherwise non-standard UUID might be a separate 469 type specific to the software implementation, for instance 470 TBIRD-UUID. 472 2. LICENSE 474 An IMAP client may find it useful to identify the license key of 475 software it is using. Such licenses are typically crafted such 476 that they are unique and useful to identify a software 477 installation. This is more normally suited for a software 478 designed for a single-user. While LICENSE could be standard type 479 again, it might more more helpful to specify a vendor specific 480 type such as BBLICENSEKEY. 482 3. DEVICE_ID 484 Many hardware devices are designed to be used by a single 485 individual and already have an associated hardware device id. 487 While a standard type might be defined, it also might be more 488 helpful to use a vendor specific type, such as ATOM-DEVICEID. 490 4. COOKIE 492 While not guranteed to be consistent many web applications are 493 designed to access IMAP directly and may need to have a 494 semi-unique identifier available as part of the web based 495 transaction. It is assumed that COOKIE encompasses the group of 496 web based tokens known to persist from session to session. A 497 specific web based application can provide sufficient information 498 in the actual client-identifier-token to differentiate between 499 applications and or websites, and are convenient as they can be 500 related to very specific domains, and are universally available to 501 web application designers. 503 As a reminder, an IMAP server SHOULD NOT retain and/or store the 504 CLIENTID information WITH authentication credentials or 505 authentication systems directly, but the IMAP service MAY 506 associate the CLIENTID with a specific account holder, eg to create 507 a history file of known CLIENTID tokens associated or permitted to 508 access or present authentication credentials for that account holder. 510 This document recommends that an IMAP server handle any given client 511 identity type from a CLIENTID command in one or more of the following 512 manners. 514 1. Handled but treat as not presented (ignored, no persistance) 515 2. Store in IMAP session but treat as not presented (debugging) 516 3. Store in the IMAP session, so it is available to System log 517 4. Store in the IMAP session, so it is available to User log 518 5. Use for authentication 519 6. Use for alert when authentication fails 520 7. Use for alert when authentication succeeds 521 8. Unused 523 7. Examples 525 7.1. UUID as Client Identity 527 C: [connection established over a plaintext connection] 528 C: a001 CAPABILITY 529 S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI LOGINDISABLED 530 S: a001 OK CAPABILITY completed 531 C: a002 STARTTLS 532 S: a002 OK STARTLS completed 533 534 C: a003 CAPABILITY 535 S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN CLIENTID 536 S: a003 OK CAPABILITY completed 537 C: a004 CLIENTID UUID 23bf83be-aad7-46aa-9e0f-39191ccf402f 538 S: a004 OK CLIENTID completed 539 C: a005 LOGIN joe password 540 S: a005 OK LOGIN completed 542 7.2. Malformed CLIENTID Command 544 C: [connection established over a plaintext connection] 545 C: a001 CAPABILITY 546 S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI LOGINDISABLED 547 S: a001 OK CAPABILITY completed 548 C: a002 STARTTLS 549 S: a002 OK STARTLS completed 550 551 C: a003 CAPABILITY 552 S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN CLIENTID 553 S: a003 OK CAPABILITY completed 554 C: a004 CLIENTID UUID 555 S: a004 BAD Error in IMAP command received by server 557 The IMAP server rejects the CLIENTID command as it is not well 558 formed due to there being only a single parameter provided. 560 7.3. Client Identity without TLS/SSL Session 562 C: [connection established over a plaintext connection] 563 C: a001 CAPABILITY 564 S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI LOGINDISABLED 565 S: a001 OK CAPABILITY completed 566 C: a002 CLIENTID UUID 23bf83be-aad7-46aa-9e0f-39191ccf402f 567 S: a002 BAD Unknown IMAP command received by server 569 The IMAP server rejects use of the CLIENTID command as the CLIENTID 570 capability had not been advertised because no encryption was 571 negotiated between the IMAP server and IMAP client. 573 7.4. Client Identity Leading to Rejection 575 C: [connection established over a plaintext connection] 576 C: a001 CAPABILITY 577 S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI LOGINDISABLED 578 S: a001 OK CAPABILITY completed 579 C: a002 STARTTLS 580 S: a002 OK STARTLS completed 581 582 C: a003 CAPABILITY 583 S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN CLIENTID 584 S: a003 OK CAPABILITY completed 585 C: a004 CLIENTID UUID 23bf83be-aad7-46aa-9e0f-39191ccf402f 586 S: a004 OK CLIENTID completed 587 C: a005 LOGIN joe password 588 S: a005 BAD Failed to authenticate 590 The IMAP server rejects use of the system during the LOGIN command 591 after deciding that the provided client identity does not establish 592 sufficient privileges. Note that the error message that's returned 593 to the client is very generic and does not reveal any information 594 about CLIENTID and/or the existence of 'joe' and/or the validity of 595 the password. 597 8. Security Considerations 599 As this extension provides an additional means of communicating 600 information from a client to a server it is clear there is additional 601 information divulged to the server. This may have privacy 602 considerations depending on the client identity type or its contents. 603 For example, it may reveal a MAC address of the device used to 604 communicate with a server that would not previously have been 605 revealed. While it has been useful to use identifier such as email 606 address for authentication it is easy for these authetication tokens 607 to be shared and/or reused and/or be publically available for other 608 purposes. An IMAP server and or its operators SHOULD not share 609 any CLIENTID information presented with a third party as it may 610 represent or be linked to an individual and SHOULD never be shared in 611 association with authentication tokens. 613 As well, while this service extension requires that the identity 614 information only be transmitted over an encrypted channel to reduce 615 the risk of eavesdropping, it does not specify any policies or 616 practices required in the establishment of such a channel, and so it 617 is the responsibility of the client and the server to determine that 618 the communication medium meets their requirements. 620 9. IANA Considerations 622 The IANA is requested to add CLIENTID to the "IMAP 4 Capabilities" 623 registry, http://www.iana.org/assignments/imap4-capabilities. 625 10. References 627 10.1. Normative References 629 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for 630 Syntax Specifications: ABNF", RFC 2234, 631 November 1997. 633 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 634 4rev1", RFC 3501, March 2003. 636 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 637 Requirement Levels", BCP 14, RFC 2119, DOI 638 10.17487/RFC2119, March 1997, . 641 [SASL] Myers, J., "Simple Authentication and Security 642 Layer (SASL)", RFC 2222, October 1997. 644 [TLS] Dierks, T. and C. Allen, "The TLS Protocol 645 Version 1.0", RFC 2246, January 1999. 647 Appendix A. CLIENTID Product Support 649 Since publishing the IMAP Client Identity RFC draft, multiple email 650 server and client vendors have implemented CLIENTID support into 651 their products, e.g. MailEnable, MagicMail, SaneBox, BlueMail, 652 emClient, and Thunderbird. 654 Contributors 656 Michael Peddemors 657 LinuxMagic 659 Authors' Addresses 661 Deion Yu 662 LinuxMagic 663 #405 - 860 Homer St. 664 Vancouver, British Columbia 665 CA V6B 2W5 667 EMail: deiony@linuxmagic.com