idnits 2.17.1 draft-yu-imap-client-id-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 5 characters 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 -- The document date (May 22, 2019) is 1791 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 22, 2019 May 22, 2019 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 characters and 159 comprised of only alphanumeric and dash 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 with dash character 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 before processing or accepting an authentication 238 request. 240 2. The IMAP server MAY reject any authentication request not preceded 241 with a client identity type that matches ACL's or rules as defined 242 in the IMAP server. 244 3. An IMAP server MAY reject any authentication request preceded by a 245 CLIENTID command that contains a client identity type or client 246 identity token that the server chooses not to accept for any 247 reason such as by policy. 249 4. An IMAP server MAY reject any authentication request preceded by a 250 CLIENTID command that contains a client identity type or client 251 identity token that the server has chosen to disable or revoke use 252 of either temporarily or permanently. 254 The IMAP server SHOULD only ever reject an IMAP client based on 255 CLIENTID information during or after the authentication 256 process/handler. In the interest of limiting the amount of 257 information being revealed, the rejection message SHOULD be as generic 258 as possible and SHOULD NOT reveal any information on the heuristics. 260 Even if the client identity type and/or client identity token are not 261 recognized, supported or permitted by the server and/or the owner of 262 the authentication credentials, the presented information may still be 263 useful for analysis. 265 5.2. Utility of CLIENTID 267 Regardless of how frowned upon, users commonly reuse authorization 268 information (like the username and password pair) across multiple 269 services. When one service is compromised, malicious actors can also 270 gain access to other services where the user also used the same 271 credentials. Based on this representative problem alone, the utility 272 of CLIENTID as an additional layer of determining the rights to 273 present such authorization information becomes quickly apparent. 275 The utility of CLIENTID may be seen by considering the following: 277 1. An IMAP server could recognize a device not historically known to 278 have presented the authentication credentials before. 280 2. An IMAP server could restrict authentication from actors not 281 presenting a valid CLIENTID, or an account holder that the IMAP 282 server provides service for could restrict authentication to only 283 those devices that present valid CLIENTID. 285 3. An IMAP server could restrict authentication to only devices which 286 present a CLIENTID containing a client type identifier which the 287 account holder or operator of the server deems to be permitted. 288 (Eg. Only allow vendor A's devices) 290 4. An IMAP server could alert an account holder that an attempt to 291 present their authorization credentials came from an unknown, 292 unrecgonized, or different device. 294 However, this extends beyond just the restriction of authentication. 295 While it might be argued that this can be served as a special form 296 of SASL, by implementing this in the IMAP service itself, the IMAP 297 service can choose before allowing a connection to be passed to a 298 SASL implementation, allowing it to perform other heuristics, such 299 as brute force attacks, more effeciently. 301 Recent evolution of the internet as a whole, has brought about large 302 scale data breaches, compromised botnets comprising of millions of 303 nodes, and transitions to Carrier Grade NAT, and the flourishing of 304 IoT devices, means traditional methods of protecting against brute 305 force attacks have become much more difficult. Traditional methods 306 such as rate limiting and/or blocking access by IP are no longer 307 viable without introducing collateral effects, such as either 308 blocking legitimate users, or creating the conditions that allow 309 DOS (Denial of Service) to legitimate users. 311 Historically, IMAP and other services used what is technically a two 312 factor, the email/user and password, albeit not effective in that the 313 email is a KNOWN value. And with the propensity for users to use a 314 simple password, and the hundreds of millions of email addresses 315 exposed in data breaches, or available by other means the ability to 316 brute force is quite simple. While of course it is recommended that 317 users use longer and more secure passwords, this is not the de facto 318 situation, and the threats when credentials get compromised are 319 significant. And with 'botnet' operators able to engage millions of 320 IoT in a distributed brute force, the status quo is dangerous. Adding 321 another non-public factor to be used as part of access control adds 322 a strength against brute force by many factors. This accomplishes 323 that in a backwards compatible fashion, encouraging adoption. 325 But for the IMAP server, it also offers additional abilities. 327 Historically, under brute force attacks, rate limiting or blocking by 328 IP Address was possible with little damage. But with the 329 proliferaction of IoT devices, smart phones, and the run-out of IP 330 space, we have conditions where thousands of devices could be 331 behind an IP Address, or IP(s) that are dynamic with devices 332 changing IP(s) in minutes, blocking or rate limiting an IP bears 333 risks of blocking legitimate users. By implementing a level of 334 uniqueness to a connecting device, introduces the ability to restrict 335 or block a subset from connecting to the service for either brute 336 force or dictionary attacks, while still allowing other devices 337 to continue to be able to present authentication successfully. 339 While 'forgery' and/or the use of random client identifier is 340 possible, such behavior is also more readily detectable when a device 341 identifier is presented. 343 1. The IMAP server, when faced with hundreds of devices behind the 344 same IP address, during an attack can restrict authentication 345 attempts to only connections presenting a valid client identifier 346 token. 348 2. The IMAP server, during an attack, can restrict authentication to 349 only historically known devices. 351 3. The IMAP server can differentiate between many different devices 352 behind the same IP, and apply maximum connections per device, 353 rather than maximum connections per IP. 355 4. While a person may present authentication credentials from many 356 different geographical locations, eg, home, office, and travel, a 357 single device will not in general be able to be in two 358 geographical locations at the same time. The IMAP server will 359 have new information to apply to threat detection heuristics, ie 360 to treat the use of the same client indentifier token from 361 two locations, as a possible brute force or forgery situation. 363 5.3. Use Cases of CLIENTID 365 With CLIENTID the IMAP server has additional information it may use 366 in its interactions with the client. It may: 368 1. Restrict use of an authorization tokens to a set of client 369 identity token identities, thereby offering an added level 370 of security. For example the use of authorization credentials may 371 only be accompanied by a specified set of CLIENTID tokens and/or 372 types for a specific account holder, or set of account holders 374 2. Identify that the same CLIENTID token is used to access multiple 375 authorized identities, and restrict access to the IMAP service. 376 For example a malicious client that has attempted to gain access 377 using multiple authorization tokens may be identified through its 378 unusual behavior. 380 3. Retain knowledge of CLIENTID tokens previously presented with 381 specific authorization credentials, and if the token has not been 382 previously seen, restrict access to the IMAP service. 384 4. Require that the IMAP client present a token such as a license key 385 established outside of the IMAP session in order to make use of 386 any authorized identity. 388 5. Apply different security policies to clients that provide a 389 CLIENTID token versus those which do not. For example, provide 390 clients providing such an identity with additional trust. 392 6. Ability to rate limit or block based on the presented 393 client-identifier-token, when multiple devices use a shared IP 394 address, without affecting other devices. 396 7. Ability to detect distributed and localized dictionary attacks 397 and brute force attacks. 399 8. Use the client-indentifier-token as a third factor to be passed 400 to authentication methods. [SASL] 402 5.4. Other IMAP Client Identifiers 404 The [IMAP] protocol and its extensions describe methods whereby an 406 IMAP client may provide identity information to an IMAP server. Some 407 of these identitiers are listed for contrast: 409 1. The client connection provides a source IP address associated 410 with the IMAP session. This may be accompanied by a PTR record 411 and/or GeoIP information. 413 2. The AUTHENTICATE and LOGIN command allows the client to present 414 a user and/or password/authentication mechanism for an IMAP 415 session. 417 5.5. Future Considerations 419 In the future there may be a demand for being able to provide 420 multiple CLIENTID commands with different client identity types. 421 For instance, it may be desirable for a device to indentify itself, 422 both with a hardware device identifier, and a software identifier. 423 We believe this to be out of scope, and can be accomodated with a 424 special client-identifier-token which encapsulates both. 426 6. Client Identity Types 428 This document does not specify any CLIENTID identity type that MUST 429 be supported. The client identity type is meant to be defined by 430 the client implementation that is designed to access the IMAP server 431 and protocol. For instance, many IMAP client software implementations 432 already create a distinct UUID for each account. Some commercial 433 email clients have a license key. Some physical devices that need to 434 of client identity type that conforms to the definition, it is 435 interact with IMAP might have a unique hardware ID or MAC Address. 436 While there is no pre-defined list of client identity type defined by 437 this RFC, and all IMAP servers should be prepared to accept any form 438 suggested that IMAP client developers carefully consider the name of 439 the client identity type. For example, rather that using a 440 client identity type of UUID, consider the advantages of making it 441 more distinct, eg "UUID". This way the IMAP 442 server can better record histories, eg the difference between say 443 a Thunderbird generated unique id, and a Mutt generated unique id. 445 Some examples of identity type might be UUID, LICENSE, 446 DEVICE_ID, MAC and/or COOKIE. It is expected that the most common 447 types might be related to distinct UUID, LICENSEKEY, or HARDWAREID. 449 An IMAP server SHOULD NOT reject an unidentified CLIENTID type, except 450 for specific policy use cases. 452 It is envisioned that in the future it will be useful to propose 453 a set of standardized client-indentity-type to help with validation, 454 or to allow the IMAP server to apply ACL rules on expected types, 455 this would be an extension to this RFC. 457 1. UUID 459 UUID is a common practice to represent either a individual user, 460 hardware device or software installation associated with a 461 specific individual. The support of UUID enables existing UUID 462 implementations to be used to semi-uniquely identify a device 463 associated with an individual. A definition of the format should 464 be considered. Otherwise non-standard UUID might be a separate 465 type specific to the software implementation, for instance 466 TBIRD-UUID. 468 2. LICENSE 470 An IMAP client may find it useful to identify the license key of 471 software it is using. Such licenses are typically crafted such 472 that they are unique and useful to identify a software 473 installation. This is more normally suited for a software 474 designed for a single-user. While LICENSE could be standard type 475 again, it might more more helpful to specify a vendor specific 476 type such as BBLICENSEKEY. 478 3. DEVICE_ID 480 Many hardware devices are designed to be used by a single 481 individual and already have an associated hardware device id. 482 While a standard type might be defined, it also might be more 483 helpful to use a vendor specific type, such as ATOM-DEVICEID. 485 4. MAC 487 The MAC address traditionally was used as a worldwide identifier 488 both of the unique device, as well as it's vendor and product 489 category, however this is not always the case anymore, in the case 490 of it's usage in 'virtual' devices. But for many hardware devices 491 which are required to access a defined IMAP resource, the MAC 492 address may still be a simple unique identifier. MAC should NOT 493 be used, unless this is a MAC address that can be associated to a 494 vendor using standard MAC registration information as defined or 495 set by the IEEE Standards Association and is meant to represent a 496 unique device. 498 5. COOKIE 500 While not guranteed to be consistent many web applications are 501 designed to access IMAP directly and may need to have a 502 semi-unique identifier available as part of the web based 503 transaction. It is assumed that COOKIE encompasses the group of 504 web based tokens known to persist from session to session. A 505 specific web based application can provide sufficient information 506 in the actual client-identifier-token to differentiate between 507 applications and or websites, and are convenient as they can be 508 related to very specific domains, and are universally available to 509 web application designers. 511 As a reminder, an IMAP server SHOULD NOT retain and/or store the 512 CLIENTID information WITH authentication credentials or 513 authentication systems directly, but the IMAP service MAY 514 associate the CLIENTID with a specific account holder, eg to create 515 a history file of known CLIENTID tokens associated or permitted to 516 access or present authentication credentials for that account holder. 518 This document recommends that an IMAP server handle any given client 519 identity type from a CLIENTID command in one or more of the following 520 manners. 522 1. Handled but treat as not presented (ignored, no persistance) 523 2. Store in IMAP session but treat as not presented (useful for debugging) 524 3. Store in the IMAP session, so it is available to System log 525 4. Store in the IMAP session, so it is available to User log 526 5. Use for authentication 527 6. Use for alert when authentication fails 528 7. Use for alert when authentication succeeds 529 8. Unused 531 7. Examples 533 7.1. UUID as Client Identity 535 C: [connection established over a plaintext connection] 536 C: a001 CAPABILITY 537 S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI LOGINDISABLED 538 S: a001 OK CAPABILITY completed 539 C: a002 STARTTLS 540 S: a002 OK STARTLS completed 541 542 C: a003 CAPABILITY 543 S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN CLIENTID 544 S: a003 OK CAPABILITY completed 545 C: a004 CLIENTID UUID 23bf83be-aad7-46aa-9e0f-39191ccf402f 546 S: a004 OK CLIENTID completed 547 C: a005 LOGIN joe password 548 S: a005 OK LOGIN completed 550 7.2. Malformed CLIENTID Command 552 C: [connection established over a plaintext connection] 553 C: a001 CAPABILITY 554 S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI LOGINDISABLED 555 S: a001 OK CAPABILITY completed 556 C: a002 STARTTLS 557 S: a002 OK STARTLS completed 558 559 C: a003 CAPABILITY 560 S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN CLIENTID 561 S: a003 OK CAPABILITY completed 562 C: a004 CLIENTID UUID 563 S: a004 BAD Error in IMAP command received by server 565 The IMAP server rejects the CLIENTID command as it is not well 566 formed due to there being only a single parameter provided. 568 7.3. Client Identity without TLS/SSL Session 570 C: [connection established over a plaintext connection] 571 C: a001 CAPABILITY 572 S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI LOGINDISABLED 573 S: a001 OK CAPABILITY completed 574 C: a002 CLIENTID UUID 23bf83be-aad7-46aa-9e0f-39191ccf402f 575 S: a002 BAD Unknown IMAP command received by server 577 The IMAP server rejects use of the CLIENTID command as the CLIENTID 578 capability had not been advertised because no encryption was 579 negotiated between the IMAP server and IMAP client. 581 7.4. Client Identity Leading to Rejection 583 C: [connection established over a plaintext connection] 584 C: a001 CAPABILITY 585 S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI LOGINDISABLED 586 S: a001 OK CAPABILITY completed 587 C: a002 STARTTLS 588 S: a002 OK STARTLS completed 589 590 C: a003 CAPABILITY 591 S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN CLIENTID 592 S: a003 OK CAPABILITY completed 593 C: a004 CLIENTID UUID 23bf83be-aad7-46aa-9e0f-39191ccf402f 594 S: a004 OK CLIENTID completed 595 C: a005 LOGIN joe password 596 S: a005 BAD Failed to authenticate 597 The IMAP server rejects use of the system during the LOGIN command 598 after deciding that the provided client identity does not establish 599 sufficient privileges. Note that the error message that's returned 600 to the client is very generic and does not reveal any information 601 about CLIENTID and/or the existence of 'joe' and/or the validity of 602 the password. 604 8. Security Considerations 606 As this extension provides an additional means of communicating 607 information from a client to a server it is clear there is additional 608 information divulged to the server. This may have privacy 609 considerations depending on the client identity type or its contents. 610 For example, it may reveal a MAC address of the device used to 611 communicate with a server that would not previously have been 612 revealed. While it has been useful to use identifier such as email 613 address for authentication it is easy for these authetication tokens 614 to be shared and/or reused and/or be publically available for other 615 purposes. An IMAP server and or its operators SHOULD not share 616 any CLIENTID information presented with a third party as it may 617 represent or be linked to an individual and SHOULD never be shared in 619 association with authentication tokens. 621 As well, while this service extension requires that the identity 622 information only be transmitted over an encrypted channel to reduce 623 the risk of eavesdropping, it does not specify any policies or 624 practices required in the establishment of such a channel, and so it 625 is the responsibility of the client and the server to determine that 626 the communication medium meets their requirements. 628 9. IANA Considerations 630 The IANA is requested to add CLIENTID to the "IMAP 4 Capabilities" 631 registry, http://www.iana.org/assignments/imap4-capabilities. 633 10. References 635 10.1. Normative References 637 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for 638 Syntax Specifications: ABNF", RFC 2234, 639 November 1997. 641 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 642 4rev1", RFC 3501, March 2003. 644 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 645 Requirement Levels", BCP 14, RFC 2119, DOI 646 10.17487/RFC2119, March 1997, . 649 [SASL] Myers, J., "Simple Authentication and Security 650 Layer (SASL)", RFC 2222, October 1997. 652 [TLS] Dierks, T. and C. Allen, "The TLS Protocol 653 Version 1.0", RFC 2246, January 1999. 655 Contributors 657 Michael Peddemors 658 LinuxMagic 660 Authors' Addresses 662 Deion Yu 663 LinuxMagic 664 #405 - 860 Homer St. 665 Vancouver, British Columbia 666 CA V6B 2W5 668 EMail: deiony@linuxmagic.com