idnits 2.17.1 draft-yu-imap-client-id-00.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 CID 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 24, 2018) is 2136 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 November 24, 2018 May 24, 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 "CID" which provides a method for clients to 14 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. CID .......................................................... 3 59 3.1. CID Command .............................................. 3 60 3.2. CID Arguments ............................................ 3 61 3.3. Advertising the CID capability ............................ 4 62 3.4. Restrictions on the CID command ........................... 4 63 4. Formal Syntax ................................................ 4 64 5. Discussion ................................................... 5 65 5.1. Applying heuristics to CID ............................... 5 66 5.2. Utility of CID ............................................ 5 67 5.3. Use Cases of CID .......................................... 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 CID 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 CID extension, an IMAP client can provide an additional 107 identity token to the server called its "client identity". The 108 client identity can provide unique characteristics about the client 109 accessing the IMAP service and may be combined with existing 110 identification mechanisms in order to identify the client. An IMAP 111 server may then apply additional security policies using this 112 identity such as restricting use of the service to clients presenting 113 recognized client identities or only allowing use of authorized 114 identities that match previously established client identities. 116 The CID extension is present in any IMAP implementation that returns 117 "CID" as one of the supported capabilities to the CAPABILITY 118 command. 120 2. Conventions Used in This Document 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [KEYWORDS]. 126 Formal syntax is specified using [ABNF]. 128 Example lines prefaced by "C:" are sent by the client and ones 129 prefaced by "S:" by the server. 131 "Connection" refers to the entire sequence of client/server 132 interaction from the initial establishment of the network connection 133 until its termination. 135 3. CID 137 3.1. CID Command 139 Arguments: client identity type 140 client identity token 142 Responses: no specific responses for this command 144 Result: OK - cid completed, client identity information stored 145 BAD - command unknown or arguments invalid 147 Note that a valid CID command will never return the NO result because 148 heuristics MUST NOT be applied to the CID arguments at this stage. 149 Instead the client identity information SHOULD be stored and passed 150 along to any and all [SASL] authentication mechanisms. 152 3.2. CID Arguments 154 The CID command takes the following two arguments: 156 1. client identity type: A string identifying the identity type the 157 client is providing. It MUST be between 1 and 16 alphanumeric 158 characters. 160 2. client identity token: A string identifying the client. It MUST 161 be between 1 and 128 printable characters. 163 The IMAP server MUST reject any CID command with badly formatted 164 arguments. The IMAP server MUST accept the arguments from a valid 165 CID command and SHOULD store it at the minimum for the remaining 166 duration of the IMAP connection. 168 3.3. Advertising the CID capability 170 The CID capability is used to tell the IMAP client that the IMAP 171 server supports the CID extension. However, certain conditions MUST 172 be met before the IMAP server advertises the CID capability. 174 1. The IMAP server and IMAP client MUST negotiate encryption via 175 STARTTLS/SSL or some other secure mechanism. 177 2. The IMAP server MUST be in the non-authenticated state. 179 3. The IMAP server MUST have the CID extension support enabled. 181 While all the conditions are met, the IMAP server MUST advertise the 182 CID capability in all proceeding CAPABILITY commands. 184 3.4. Restrictions on the CID command 186 Under certain circumstances, the use of the CID command will be 187 restricted: 189 1. Before the CID capability has been advertised, the IMAP server 190 MUST reject any issued CID commmand and the IMAP client MUST NOT 191 issue the CID command. 193 2. Outside of the non-authenticated state, the IMAP server MUST 194 reject any CID command issued by the IMAP client and the IMAP 195 client MUST NOT issue the CID command. 197 3. Once a valid CID command has been issued, the IMAP server MUST 198 reject any further CID command issued by the IMAP client and the 199 IMAP client MUST NOT issue any subsequent CID commands. 201 4. Formal Syntax 203 The following syntax specification uses the Augmented Backus-Naur 204 Form notation as specified in [ABNF]. [IMAP] defines the 205 non-terminals "capability" and "command-nonauth". 207 Except as noted otherwise, all alphabetic characters are case- 208 insensitive. The use of upper or lower case characters to define 209 token strings is for editorial clarity only. Implementations MUST 210 accept these strings in a case-insensitive fashion. 212 capability =/ "CID" 214 command-nonauth =/ cid 216 cid = "CID" SP client-id-type SP client-id-token 217 client-id-type = 1*16 ALPHA / DIGIT 218 ;; alphanumeric 220 client-id-token = 1*128 VCHAR 221 ;; any printable US-ASCII character 223 5. Discussion 225 5.1. Applying heuristics to CID 227 This section discusses the possible heuristics that can be applied to 228 the information that is presented via the CID command. This 229 information includes whether a valid CID command was issued, the 230 client identity type and the client identity token. 232 1. The IMAP server MAY choose to require that a successful CID 233 command be issued or that a particular client identity type be 234 presented. 236 2. The IMAP server MAY reject any CID command with a client identity 237 type that is not recognized by the IMAP server. 239 3. The IMAP server MAY reject any CID command with a client identity 240 type that is not supported by the IMAP server. 242 4. An IMAP server MAY reject any CID command that contains a client 243 identity type or client identity token that the server chooses not 244 to accept for any reason such as by policy. 246 5. An IMAP server MAY reject any CID command that contains a client 247 identity type or client identity that the server has chosen to 248 disable or revoke use of either temporarily or permanently. 250 The IMAP server SHOULD only ever reject an IMAP client based on CID 251 information during or after the authentication process/handler. In 252 the interest of limiting the amount of information being revealed, the 253 rejection message SHOULD be as generic as possible and SHOULD NOT 254 reveal any information on the heuristics. 256 Even if the client identity type and/or client identity token are not 257 recognized, supported or permitted by the server and/or the owner the 258 authentication credentials, the presented information may still be 259 useful for analysis. 261 5.2. Utility of CID 263 Regardless of how much it is frowned upon, common authorization 264 information like the username and password pair are reused across 265 multiple web services. When this authorization is compromised on a 266 single web service, malicious actors usually also gain access to 267 other web services. Based on this information alone, the utility of 268 CID as an additional layer of authentication that is only available 269 across an encrypted channel becomes more apparent. 271 The utility of CID may be seen by considering the following: 273 1. An IMAP client may utilize the same IMAP server with multiple 274 different authorized identities, so an identity that persists 275 across authorized identities is lacking. 277 2. An authorized identity may make use of multiple discrete devices 278 over different IMAP sessions, so an identity persisting on one 279 device is lacking. 281 3. Existing identity information available from the connection such 282 as network address or IP changes frequently as devices are 283 becoming more mobile in nature. 285 4. Individual IMAP services have no method to determine if devices 286 types should be permitted e.g. private IMAP services that do not 287 persist across different connections. 289 5. There is no method for legacy authentication methods to associate 290 a given set of authentication tokens to an individual and or that 291 individuals registered devices. 293 5.3. Use Cases of CID 295 With CID the IMAP server has additional information it may use in its 296 interactions with the client. It may: 298 1. Restrict use of an authorization tokens to a set of client 299 identities, thereby offering an added level of security. For 300 example the use of an authorization token may only be accompanied 301 by a specified set of CID tokens and/or types. 303 2. Identify that the same CID token is used to access multiple 304 authorized identities, and restrict access to the IMAP service. 305 For example a malicious client that has attempted to gain access 306 using multiple authorization tokens may be identified through its 307 unusual behavior. 309 3. Retain knowledge of CID tokens previously presented with specific 310 authorization credentials, and if the token has not been 311 previously seen, restrict access to the IMAP service. 313 4. Require that the IMAP client present a token such as a license key 314 established outside of the IMAP session in order to make use of 315 any authorized identity. 317 5. Apply different security policies to clients that provide a CID 318 token versus those which do not. For example, provide clients 319 providing such an identity with additional trust. 321 5.4. Other IMAP Client Identifiers 323 The [IMAP] protocol and its extensions describe methods whereby an 324 IMAP client may provide identity information to an IMAP server. Some 325 of these identitiers are listed for contrast: 327 1. The client connection provides a source IP address associated 328 with the IMAP session. This may be accompanied by a PTR record 329 and/or GeoIP information. 331 2. The AUTHENTICATE and LOGIN command allows the client to present 332 a user and/or password/authentication mechanism for an IMAP 333 session. 335 5.5. Future Considerations 337 In the future there may be a demand for being able to provide 338 multiple CID commands with different cid types. 340 6. Client Identity Types 342 This document does not specify any CID identity type that MUST be 343 supported. Some examples of identity type are UUID, LICENSE, 344 DEVICE_ID, MAC and COOKIE. To start with certain types such as UUID 345 and LICENSE SHOULD be supported. It is intended that any CID type be 346 accepted but in the future standards on types may be set but a IMAP 347 server SHOULD NOT reject an unidentified CID type, except for 348 specific policy use cases. 350 It is envisioned that in the future it will be useful to propose 351 identity types to support. 353 1. UUID 355 UUID is a common practice to represent either a individual user, 356 hardware device or software installation associated with a 357 specific individual. The support of UUID enables existing UUID 358 implementations to be used to semi-uniquely identify a device 359 associated with an individual. 361 2. LICENSE 363 An IMAP client may find it useful to identify the license key of 364 software it is using. Such licenses are typically crafted such 365 that they are unique and useful to identify a software 366 installation. 368 3. DEVICE_ID 370 Many hardware devices are designed to be used by a single 371 individual and already have an associated hardware device id. 373 4. MAC 375 The MAC address is not always available or consistent. However, 376 for certain use cases the MAC may be the only information 377 available to specify a specific device. 379 5. COOKIE 381 While not guranteed to be consistent many web applications are 382 designed to access IMAP directly and may need to have a 383 semi-unique identifier available as part of the web based 384 transaction. 386 This document recommends that an IMAP server handle any given client 387 identity type from a CID command in one or more of the following 388 manners. 390 1. Handled but treat as not presented 391 2. Store in session but treat as not presented (useful for debugging) 392 3. System log 393 4. User log 394 5. Use for authentication 395 6. Use for alert when authentication fails 396 7. Use for alert when authentication succeeds 397 8. Unused 399 7. Examples 401 7.1. UUID as Client Identity 403 C: [connection established over a plaintext connection] 404 C: a001 CAPABILITY 405 S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI LOGINDISABLED 406 S: a001 OK CAPABILITY completed 407 C: a002 STARTTLS 408 S: a002 OK STARTLS completed 409 410 C: a003 CAPABILITY 411 S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN CID 412 S: a003 OK CAPABILITY completed 413 C: a004 CID UUID 23bf83be-aad7-46aa-9e0f-39191ccf402f 414 S: a004 OK CID completed 415 C: a005 LOGIN joe password 416 S: a005 OK LOGIN completed 418 7.2. Malformed CID Command 420 C: [connection established over a plaintext connection] 421 C: a001 CAPABILITY 422 S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI LOGINDISABLED 423 S: a001 OK CAPABILITY completed 424 C: a002 STARTTLS 425 S: a002 OK STARTLS completed 426 427 C: a003 CAPABILITY 428 S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN CID 429 S: a003 OK CAPABILITY completed 430 C: a004 CID UUID 431 S: a004 BAD Error in IMAP command received by server 432 The IMAP server rejects the CID command as it is not well formed due 433 to there being only a single parameter provided. 435 7.3. Client Identity without TLS/SSL Session 437 C: [connection established over a plaintext connection] 438 C: a001 CAPABILITY 439 S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI LOGINDISABLED 440 S: a001 OK CAPABILITY completed 441 C: a002 CID UUID 23bf83be-aad7-46aa-9e0f-39191ccf402f 442 S: a002 BAD Unknown IMAP command received by server 444 The IMAP server rejects use of the CID command as the CID capability 445 had not been advertised because no encryption was negotiated between 446 the IMAP server and IMAP client. 448 7.4. Client Identity Leading to Rejection 450 C: [connection established over a plaintext connection] 451 C: a001 CAPABILITY 452 S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI LOGINDISABLED 453 S: a001 OK CAPABILITY completed 454 C: a002 STARTTLS 455 S: a002 OK STARTLS completed 456 457 C: a003 CAPABILITY 458 S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN CID 459 S: a003 OK CAPABILITY completed 460 C: a004 CID UUID 23bf83be-aad7-46aa-9e0f-39191ccf402f 461 S: a004 OK CID completed 462 C: a005 LOGIN joe password 463 S: a005 BAD Failed to authenticate 465 The IMAP server rejects use of the system during the LOGIN command 466 after deciding that the provided client identity does not establish 467 sufficient privileges. Note that the error message that's returned 468 to the client is very generic and does not reveal any information 469 about CID and/or the existence of 'joe' and/or the validity of the 470 password. 472 8. Security Considerations 474 As this extension provides an additional means of communicating 475 information from a client to a server it is clear there is additional 476 information divulged to the server. This may have privacy 477 considerations depending on the client identity type or its contents. 478 For example, it may reveal a MAC address of the device used to 479 communicate with a server that would not previously have been 480 revealed. While it has been useful to use identifier such as email 481 address for authentication it is easy for these authetication tokens 482 to be shared and/or reused and/or be publically available for other 483 purposes. An IMAP server and or its operators SHOULD not share 484 any CID information presented with a third party as it may represent 485 or be linked to an individual and SHOULD never be shared in 486 association with authentication tokens. 488 As well, while this service extension requires that the identity 489 information only be transmitted over an encrypted channel to reduce 490 the risk of eavesdropping, it does not specify any policies or 491 practices required in the establishment of such a channel, and so it 492 is the responsibility of the client and the server to determine that 493 the communication medium meets their requirements. 495 9. IANA Considerations 497 The IANA is requested to add CID to the "IMAP 4 Capabilities" 498 registry, http://www.iana.org/assignments/imap4-capabilities. 500 10. References 502 10.1. Normative References 504 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for 505 Syntax Specifications: ABNF", RFC 2234, 506 November 1997. 508 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 509 4rev1", RFC 3501, March 2003. 511 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 512 Requirement Levels", BCP 14, RFC 2119, DOI 513 10.17487/RFC2119, March 1997, . 516 [SASL] Myers, J., "Simple Authentication and Security 517 Layer (SASL)", RFC 2222, October 1997. 519 [TLS] Dierks, T. and C. Allen, "The TLS Protocol 520 Version 1.0", RFC 2246, January 1999. 522 Contributors 524 Michael Peddemors 525 LinuxMagic 527 Authors' Addresses 529 Deion Yu 530 LinuxMagic 531 #405 - 860 Homer St. 532 Vancouver, British Columbia 533 CA V6B 2W5 535 EMail: deiony@linuxmagic.com