Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-multimailbox-search-03: (with DISCUSS)

From: Alexey Melnikov <[email-masked]>
Date: Tue, 5 Aug 2014 23:54:07 +0100

Hi Kathleen,

> On 5 Aug 2014, at 22:59, "Kathleen Moriarty" <[email-masked]> wrote:
> 
> The draft is well written and this should be easy to clear, but I thought
> it was important to discuss to see if a change might be needed.
> 
> In the security considerations section, the following sentence says,
> "Mailboxes matching the source options for which the logged-in user
>   lacks sufficient rights MUST be ignored by the ESEARCH command
>   processing (see the paragraph about this in Section 2.2). "
> 
> It is good that access is not permitted, but shouldn't this be logged as
> a possible access attempt violation?

There was no intent to prevent logging, but the general approach of access control to mailboxes in IMAP is "treat mailboxes you don't have access to as non existent". So logging all mailboxes that the user has no access too is not necessarily productive and might generate lots of noise.

The point of the sentence was to remind implementors that access control permissions are still to be checked.

Best Regards,
Alexey

---

From: Barry Leiba <[email-masked]>
Date: Wed, 6 Aug 2014 09:33:22 -0400

What Alexey said.

To add to that:
1. Subtree searches and the like are quite likely to match mailboxes that
the user does not have access to, and logging such things would not be
useful.

2. In general, IMAP says nothing at all about logging.  It defines the
protocol.  Logging (along with what to log) is an implementation choice.
 This document shouldn't be saying any more about it than RFC 3501, or
other IMAP specs.

Barry

On Tuesday, August 5, 2014, Alexey Melnikov <[email-masked]
<javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:

> There was no intent to prevent logging, but the general approach of access
> control to mailboxes in IMAP is "treat mailboxes you don't have access to
> as non existent". So logging all mailboxes that the user has no access too
> is not necessarily productive and might generate lots of noise.
>

---

From: "Kathleen Moriarty" <[email-masked]>
Date: Tue, 05 Aug 2014 14:59:00 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-appsawg-multimailbox-search-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-multimailbox-search/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

---

From: Pete Resnick <[email-masked]>
Date: Wed, 6 Aug 2014 14:41:25 -0500

On 8/6/14 1:51 PM, Kathleen Moriarty wrote:

> The part I am having a little trouble with is the server side since a 
> new capability to search multiple accounts is enabled through this draft.

No, that's not true, or at least misstated: There is nothing you can 
search with this mechanism that you can't search by multiple 
SELECT/SEARCH pairs.

> In Barry's response, I didn't think #1 was possible as I thought from 
> reading the draft that read access was required for the user to search 
> any subtree.  Why would this allow searches outside of the user's 
> access rights?  I must have missed something and would appreciate an 
> explanation of why this would be allowed.

    If the server supports the Access Control List (ACL) [RFC4314]
    extension, then the logged-in user is required to have the "r" right
    for each mailbox she wants to search.  In addition, any mailboxes
    that are not explicitly named (accessed through "personal" or
    "subtree", for example) are required to have the "l" right.

You could have "l" access to the parent and "r" access to the child.

> Implementations/deployments could wind up with access permission 
> issues that enable access to an account in which a user should not 
> have access.  I've seen this happen in other applications and it's not 
> pretty when one user can see another users data (or one company can 
> see data about another company).  You could get into privacy concerns 
> very quickly since we are talking about email or at the service 
> provider level corporate data leakage.  Being able to catch 
> configuration mistakes through log analysis can be very helpful 
> (seeing failed access attempts).  The other issue could be where an 
> attacker tries to get access outside of their normal set of accounts, 
> exploiting this new feature and possible implementation or 
> provisioning flaws (again, failed access attempt logs are helpful).

On this, I agree with Barry's point #2: This is an implementation detail 
and is not part of the protocol. I could implement logging by logging 
errors for SELECT, or ESEARCH, or any other IMAP command that impinges 
on ACLs. Or I could log all SELECTs and ESEARCHs (successful and 
unsuccessful) and that would give me a much better log analysis of when 
users have improper access to certain parts of the tree. I don't think 
this needs to be pointed out in this protocol document.

> Alexey's explanation was helpful, could something along those lines be 
> added?

I think 4314 already has a good discussion of this. Do you think 
something more is needed?

> How about adding a recommendation for developers to implement logging 
> of failed access attempts and the implementer can decide whether or 
> not to enable it or to use it when debugging/testing to ensure access 
> is limited as expected?

Again, I'm not convinced this belongs in a protocol document. I can see 
loads of interesting reasons to implement all different sorts of logging 
facilities, some for security, some for all sorts of other purposes. But 
that seems to me solely a local implementation issue, not an issue for 
the protocol.

pr

> On Wed, Aug 6, 2014 at 9:33 AM, Barry Leiba <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     What Alexey said.
>
>     To add to that:
>     1. Subtree searches and the like are quite likely to match
>     mailboxes that the user does not have access to, and logging such
>     things would not be useful.
>
>     2. In general, IMAP says nothing at all about logging.  It defines
>     the protocol.  Logging (along with what to log) is an
>     implementation choice.  This document shouldn't be saying any more
>     about it than RFC 3501, or other IMAP specs.
>
>     Barry
>
>
>     On Tuesday, August 5, 2014, Alexey Melnikov
>     <[email-masked]> wrote:
>
>         Hi Kathleen,
>
>         > On 5 Aug 2014, at 22:59, "Kathleen Moriarty"
>         <[email-masked]> wrote:
>         >
>         There was no intent to prevent logging, but the general
>         approach of access control to mailboxes in IMAP is "treat
>         mailboxes you don't have access to as non existent". So
>         logging all mailboxes that the user has no access too is not
>         necessarily productive and might generate lots of noise.
>
>         The point of the sentence was to remind implementors that
>         access control permissions are still to be checked.
>
>         Best Regards,
>         Alexey
>
>
>
>
>
> -- 
>
> Best regards,
> Kathleen

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Pete Resnick <[email-masked]>
Date: Wed, 6 Aug 2014 15:41:09 -0500

On 8/6/14 3:01 PM, Kathleen Moriarty wrote:
> OK, I'll remove the discuss and appreciate the discussion/explanation.

Thanks Kathleen. If you do find something that is not clear from 4314 
that we need to say in here, we can always take a look back before final 
publication.

pr

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 6 Aug 2014 14:51:00 -0400

Thanks for the quick responses!

On the client side, I agree with the approach taken in that they should not
be notified if a mailbox exists.  That will prevent reconnaissance.  The
part I am having a little trouble with is the server side since a new
capability to search multiple accounts is enabled through this draft.

In Barry's response, I didn't think #1 was possible as I thought from
reading the draft that read access was required for the user to search any
subtree.  Why would this allow searches outside of the user's access
rights?  I must have missed something and would appreciate an explanation
of why this would be allowed.

It's probably obvious why I would ask about logging, but in case it is not
clear, here are the scenarios I am thinking about:

Implementations/deployments could wind up with access permission issues
that enable access to an account in which a user should not have access.
 I've seen this happen in other applications and it's not pretty when one
user can see another users data (or one company can see data about another
company).  You could get into privacy concerns very quickly since we are
talking about email or at the service provider level corporate data
leakage.  Being able to catch configuration mistakes through log analysis
can be very helpful (seeing failed access attempts).  The other issue could
be where an attacker tries to get access outside of their normal set of
accounts, exploiting this new feature and possible implementation or
provisioning flaws (again, failed access attempt logs are helpful).

Alexey's explanation was helpful, could something along those lines be
added?   From your responses, the search seems to go across a range of
accounts whether or not there is read access.  Where are the access
controls checked and is it before the search is performed or after results
are determined?  I had assumed it was prior to the search, but am not sure
from your responses.

How about adding a recommendation for developers to implement logging of
failed access attempts and the implementer can decide whether or not to
enable it or to use it when debugging/testing to ensure access is limited
as expected?

Thanks for your help understanding this new feature better. I'd just like
to make sure we are not missing an access control issue.

On Wed, Aug 6, 2014 at 9:33 AM, Barry Leiba <[email-masked]> wrote:

> On Tuesday, August 5, 2014, Alexey Melnikov <[email-masked]>
> wrote:
>
>> Hi Kathleen,
>>
>> There was no intent to prevent logging, but the general approach of
>> access control to mailboxes in IMAP is "treat mailboxes you don't have
>> access to as non existent". So logging all mailboxes that the user has no
>> access too is not necessarily productive and might generate lots of noise.
>>

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 6 Aug 2014 16:01:46 -0400

Thanks, Pete, Barry & Alexey.

I chatted with Barry and went back through the draft again...

On Wed, Aug 6, 2014 at 3:41 PM, Pete Resnick <[email-masked]>
wrote:

> search with this mechanism that you can't search by multiple SELECT/SEARCH
> pairs.
>
> OK, that's helpful, thank you.  I wasn't sure if this was clear enough
(access controls managed on the server side) and the last paragraph of 2.2
covers it.

> OK, thanks.

> errors for SELECT, or ESEARCH, or any other IMAP command that impinges on
> ACLs. Or I could log all SELECTs and ESEARCHs (successful and unsuccessful)
> and that would give me a much better log analysis of when users have
> improper access to certain parts of the tree. I don't think this needs to
> be pointed out in this protocol document.
>

OK, I wanted to check as it was a gap that popped out at me from
operational and incident response experience.  I'd try to exploit it ;-)

> I think 4314 already has a good discussion of this. Do you think something
> more is needed?
>

I looked through some of the RFC, but not all and this should be good.
 I'll try to get through the rest, but have a bunch more reading to get
through for tomorrow still :-)

> that seems to me solely a local implementation issue, not an issue for the
> protocol.
>

Thanks,
Kathleen

> Pete Resnick <http://www.qualcomm.com/~presnick/> <http://www.qualcomm.com/~presnick/>

-- 

Best regards,
Kathleen