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.