rfc9698v2.txt | rfc9698.txt | |||
---|---|---|---|---|
skipping to change at line 157 ¶ | skipping to change at line 157 ¶ | |||
server are preceded by S:. Each example starts with the IMAP banner | server are preceded by S:. Each example starts with the IMAP banner | |||
issued by the server on connection, and generally abbreviates the | issued by the server on connection, and generally abbreviates the | |||
capability lists to what's required by the example itself. | capability lists to what's required by the example itself. | |||
Real connections use longer capability lists, much longer | Real connections use longer capability lists, much longer | |||
AUTHENTICATE arguments and of course use TLS. However, these | AUTHENTICATE arguments and of course use TLS. However, these | |||
examples focus on JMAPACCESS. | examples focus on JMAPACCESS. | |||
Example 1: | Example 1: | |||
A client connects, sees that SASL OAUTH [RFC7628] is available, and | A client connects, sees that SASL OAuth [RFC7628] is available, and | |||
authenticates in that way. | authenticates in that way. | |||
S: * OK [CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR] example1 | S: * OK [CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR] example1 | |||
C: 1 AUTHENTICATE OAUTHBEARER bixhPXVzZ...QEB | C: 1 AUTHENTICATE OAUTHBEARER bixhPXVzZ...QEB | |||
The server processes the command successfully. It knows that the | The server processes the command successfully. It knows that the | |||
client used Oauth, and that it and its JMAP alter ego use the same | client used OAuth, and that it and its JMAP alter ego use the same | |||
Oauth backend subsystem. Because of that it infers that the (next) | OAuth backend subsystem. Because of that it infers that the (next) | |||
access token is just as usable via JMAP as via IMAP. It includes a | access token is just as usable via JMAP as via IMAP. It includes a | |||
JMAPACCESS capability in its reply (again, real capability lists are | JMAPACCESS capability in its reply (again, real capability lists are | |||
much longer): | much longer): | |||
S: 1 OK [CAPABILITY IMAP4rev1 JMAPACCESS] done | S: 1 OK [CAPABILITY IMAP4rev1 JMAPACCESS] done | |||
C: 1b GETJMAPACCESS | C: 1b GETJMAPACCESS | |||
S: * JMAPACCESS "https://example.com/jmap" | S: * JMAPACCESS "https://example.com/jmap" | |||
S: 1b OK done | S: 1b OK done | |||
SASL OAUTH is specified by [RFC7628], and the argument in this | SASL OAuth is specified by [RFC7628], and the argument in this | |||
example is abbreviated from the more realistic length used in RFC | example is abbreviated from the more realistic length used in RFC | |||
7628. | 7628. | |||
Example 2: | Example 2: | |||
A client connects, sees no SASL method it recognizes, and issues a | A client connects, sees no SASL method it recognizes, and issues a | |||
LOGIN command. | LOGIN command. | |||
S: * OK [CAPABILITY IMAP4rev2] example2 | S: * OK [CAPABILITY IMAP4rev2] example2 | |||
C: 2 LOGIN "arnt" "trondheim" | C: 2 LOGIN "arnt" "trondheim" | |||
skipping to change at line 239 ¶ | skipping to change at line 239 ¶ | |||
Access Protocol (IMAP) Capabilities Registry" and listed this | Access Protocol (IMAP) Capabilities Registry" and listed this | |||
document as the reference. | document as the reference. | |||
7. Security Considerations | 7. Security Considerations | |||
JMAPACCESS reveals to authenticated IMAP clients that they would be | JMAPACCESS reveals to authenticated IMAP clients that they would be | |||
able to authenticate via JMAP using the same credentials and that the | able to authenticate via JMAP using the same credentials and that the | |||
object IDs match. | object IDs match. | |||
One does not normally reveal anything at all about authentication. | One does not normally reveal anything at all about authentication. | |||
However, in this case, the following occurs: | However, if the client is an attacker, then the attacker is known to | |||
have valid credentials, and Section 2.2 of [RFC8620] tells the | ||||
* information is revealed to an authenticated client, | attacker how to find the revealed URL without the help of this | |||
extension. Therefore, it is believed that this document does not | ||||
* the revealed URL can usually be found via JMAP autodiscovery, and | benefit an attacker noticeably, and its value for migration far | |||
outweighs its risk. | ||||
* an attacker would only need to try the credentials it has with an | ||||
autodiscovered JMAP URL (a matter of a second or two). | ||||
Therefore, it is believed that this document does not benefit an | ||||
attacker noticeably, and its value for migration far outweighs its | ||||
risk. | ||||
8. References | 8. References | |||
8.1. Normative References | 8.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
End of changes. 4 change blocks. | ||||
16 lines changed or deleted | 10 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |