Re: [Last-Call] [Extra] [art] Artart last call review of draft-ietf-extra-jmapaccess-04

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> On Aug 18, 2023, at 1:56 AM, Arnt Gulbrandsen <arnt@xxxxxxxxxxxxxxxxxxx> wrote:
>
> Barry Leiba writes:
>> No, it applies to success for IMAP but corresponding failure for JMAP.
>> The point is not to reveal more than necessary about the JMAP
>> authentication process, to avoid giving information that would help
>> break into JMAP.
>
> Right.
>
> Our general rule is to avoid giving information to unauthenticated clients, because they may want to use the information for breaking into something. We don't know who the user behind an unauthenticated client is, and therefore have to assume the worst.
>
> However, in this case we're giving information to an authenticated client, acting on behalf of a bona-fide user of the service. We know that because the IMAP authentication succeeded. Since we know that it's a bona-fide user, we don't have to assume anything.

The IMAP authentication succeeded using a less secure mechanism than would be accepted for JMAP; it would've been a failure had the MUA attempted to authenticate with the JMAP server with the same authentication mechanism. Therefore, from the perspective of the JMAP server, the client should be treated as unauthenticated.

- Phillip
>
> Arnt
>
> _______________________________________________
> Extra mailing list
> Extra@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/extra

<<attachment: smime.p7s>>

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux