Subject: Re: [imapext] RFC 3501 - IMAP CREATE

From: Chris Newman <[email-masked]>
Date: Mon, 21 Oct 2013 13:02:48 -0700

I just submitted a draft describing the mechanism we've used for this 
scenario:

  <http://www.ietf.org/id/draft-newman-imap-unauth-00.txt>

The basic approach for the service acting on behalf of multiple users is to 
use SASL PLAIN to authenticate as the target user (authorization identity) 
with administrative credentials (authentication identity). The service can 
then issue standard IMAP commands as that user, and then UNAUTHENTICATE to 
reuse the connection.

The problem with authenticating as the admin and using namespace tricks is 
then the admin has no access to per-user information such as per-user \seen 
flags or annotations. So it doesn't work as a general solution.

		- Chris

--On September 10, 2013 21:10:42 +0800 Nigar Sultana 
<[email-masked]> wrote:

> Dear Alexey and Dave,
>
> In my previous mail might be i have not given the complete scenario.
> thanks for the response.
>
> Following are the elements that connect to IMAP server. "3rd party
> application" and "end user through mobile" 
>
> The scenarios IMAP server should support is: 
> 1. 3rd party application can store messages on IMAP server on behalf of
> end user, in end user mailbox (it should be in user's default folder). 
> example: end user has done messaging through mobile and those messages
> 3rd party application should store in user mailbox. Each message sent in
> a particular session should be a folder. End user here - User-A and the
> hierarchy of storage structure should be: 
> User-A->defaultFolder->session1->Msg1......Msgn
> User-A->defaultFolder->session2->Msg1.......Msgn
> Here session1 and session2 is folder. Msg1 to Msgn are messages
>
>
> 2. End user through mobile can access to mailbox and sync those message
> in case of multi-device. Additional functionality can be end users can
> also create user-folders and copy the messages from default-folders
>
>
> Now to achieve scenario#1: 3rd party application should first create the
> folder in end user's mailbox and then do an APPEND to store the messages
> in users mailbox (example is given above). The IMAP server what we are
> planning to design will not explicitly create end user folder, instead
> will have the mapping to link to user's default folder mailbox. So when
> the 3rd party application will use CREATE command (as per RFC 3501) then
> IMAP Server should do the parsing, if parsing is introduced then the
> process becomes heavy, this is what the opinion our team has. So is there
> any easy step which can be used to simplify the processing on IMAP
> server???. If we use the NAMESPACE does it simplify???
>
> spec wise if we go then the command will be:
> CREATE /User-A/defaultFolder/session1
> APPEND mailbox {length} message
>
>
> Is there any other method where we can split the mailbox path into
> "UserId + mailbox path" like: so that the process need not do parsing and
> hence the process will not become heavy: CREATE User-A
> /defauleFolder/session1
> APPEND User-A mailbox 
>
> So our team were of opinion to introduce IMAP extension to CREATE and
> APPEND. for this response i got from Alexe is not a good idea
>
> Can we solve this with the use of NAMESPACE? 
>
> Regards
> Nigar S 
>
>
> ________________________________
>  From: Alexey Melnikov <[email-masked]>
> To: Nigar Sultana <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Sent: Tuesday, 10 September 2013 3:50 PM
> Subject: Re: [imapext] RFC 3501 - IMAP CREATE
>
>
>
> On 10/09/2013 09:58, Nigar Sultana wrote:
>
> Hello All,
> Hi,
>
> We have to design IMAP server which allows a third party application to
> store the messages on behalf of end user. 
>>
>>
>> If we use "CREATE" command as per spec (RFC 3501) then IMAP server
>> processing becomes heavy because it should parse the path and then store
>> the messages in user's mailbox and we should also have the parsing logic
>> to distinguish whether the connection is from third party or end user.
> I am not entirely sure what you are trying to do, but I think
> http://www.rfc-editor.org/rfc/rfc2342.txt (IMAP NAMESPACE) should solve
> your problem.
>
>
> Is there an "extension CREATE" commands where the third party can
> indicate the "end user information" and "mail box path" in separate
> arguments
>> Example: CREATE [email-masked] INBOX/TemporaryFolder
> Using a namespace prefix, this can become something like this (you
>     can pick a different prefix):
> CREATE "Other Users/[email-masked]/INBOX/TemporaryFolder"
>
>
> As an alternate option can we implement IMAP extension commands prefixed
> with "X" Probably not a good idea.
>
> Best Regards,
> Alexey

---

From: Timo Sirainen <[email-masked]>
Date: Mon, 21 Oct 2013 23:14:00 +0300

On 21.10.2013, at 23.02, Chris Newman <[email-masked]> wrote:

> I just submitted a draft describing the mechanism we've used for this scenario:
> 
> The basic approach for the service acting on behalf of multiple users is to use SASL PLAIN to authenticate as the target user (authorization identity) with administrative credentials (authentication identity). The service can then issue standard IMAP commands as that user, and then UNAUTHENTICATE to reuse the connection.
> 
> The problem with authenticating as the admin and using namespace tricks is then the admin has no access to per-user information such as per-user \seen flags or annotations. So it doesn't work as a general solution.

Seems a bit scary extension to me. I'm going to try to avoid implementing it, although I guess there could be a time when someone really really wants it. But perhaps at that point it would be better to use something else entirely than IMAP.

> For efficiency reasons, it is
>    desirable for these clients to reuse the same connection,
>    particularly if SSL has been negotiated.

I've understood TLS session reuse would make this much faster? I haven't bothered to implement it so far yet though.

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 21 Oct 2013 16:29:25 -0400

Hi Timo,

--On October 21, 2013 at 11:14:00 PM +0300 Timo Sirainen <[email-masked]> wrote:

>> The problem with authenticating as the admin and using namespace tricks
>> is then the admin has no access to per-user information such as per-user
>> \seen flags or annotations. So it doesn't work as a general solution.
>
> Seems a bit scary extension to me. I'm going to try to avoid implementing
> it, although I guess there could be a time when someone really really
> wants it. But perhaps at that point it would be better to use something
> else entirely than IMAP.

Would it be reasonable to require the authentication after an 
UNAUTHENTICATE to use the same "authentication identifier" as was used in 
the original authentication? i.e. it is OK to change the authorization 
identity within the same connected IMAP session, but it is not OK to change 
the authentication identity? I think that covers the main use case whilst 
adding a little more security.

Also, I would imagine servers would have a config option to only enable 
UNAUTHENTICATE once authentication has been done, and the authenticated 
user is a known "trusted" user (i.e., one of the admin accounts). Certainly 
allowing UNAUTHENTICATE for "arbitrary" users would be scarier.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 21 Oct 2013 16:29:25 -0400

Hi Timo,

-- 
Cyrus Daboo

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 22 Oct 2013 01:18:51 +0300

On 21.10.2013, at 23.29, Cyrus Daboo <[email-masked]> wrote:

> Would it be reasonable to require the authentication after an UNAUTHENTICATE to use the same "authentication identifier" as was used in the original authentication? i.e. it is OK to change the authorization identity within the same connected IMAP session, but it is not OK to change the authentication identity? I think that covers the main use case whilst adding a little more security.

Hmm. That would definitely help. Most normal users could then log in back only as themselves. Maybe even disable that command entirely unless auth and authz IDs differ.

> Also, I would imagine servers would have a config option to only enable UNAUTHENTICATE once authentication has been done, and the authenticated user is a known "trusted" user (i.e., one of the admin accounts). Certainly allowing UNAUTHENTICATE for "arbitrary" users would be scarier.

Yeah. Still, it's not something I'm looking forward to implementing. Dovecot's security model makes it slightly difficult to implement for some configurations (switching between different UNIX UIDs - possible of course, but not nice).

---

From: Brandon Long <[email-masked]>
Date: Mon, 21 Oct 2013 15:46:12 -0700

You're saying that parsing /user/[email-masked]/inbox is more expensive than
parsing [email-masked] inbox?

That makes no sense.

Brandon
On Sep 10, 2013 6:10 AM, "Nigar Sultana" <[email-masked]> wrote:

> example: end user has done messaging through mobile and those messages 3rd
> party application should store in user mailbox. Each message sent in a
> particular session should be a folder. End user here - User-A and the
> 2. End user through mobile can access to mailbox and sync those message in
> case of multi-device. Additional functionality can be end users can also
> create user-folders and copy the messages from default-folders
>
>
> folder in end user's mailbox and then do an APPEND to store the messages in
> users mailbox (example is given above). The IMAP server what we are
> planning to design will not explicitly create end user folder, instead will
> have the mapping to link to user's default folder mailbox. So when the 3rd
> party application will use CREATE command (as per RFC 3501) then IMAP
> Server should do the parsing, if parsing is introduced then the process
> becomes heavy, this is what the opinion our team has. So is there any easy
> step which can be used to simplify the processing on IMAP server???. If we
> use the NAMESPACE does it simplify???
>
> Is there any other method where we can split the mailbox path into "UserId
> + mailbox path" like: so that the process need not do parsing and hence the
> process will not become heavy:
> CREATE User-A /defauleFolder/session1
> APPEND User-A mailbox
>
>   ------------------------------
>  *From:* Alexey Melnikov <[email-masked]>
> *To:* Nigar Sultana <[email-masked]>
> *Cc:* "[email-masked]" <[email-masked]>
> *Sent:* Tuesday, 10 September 2013 3:50 PM
> *Subject:* Re: [imapext] RFC 3501 - IMAP CREATE
>
> the messages in user's mailbox and we should also have the parsing logic to
> distinguish whether the connection is from third party or end user.
>
>
> Using a namespace prefix, this can become something like this (you can
> pick a different prefix):
> with "X"
> Probably not a good idea.
>
> Best Regards,
> Alexey
>
>
>
>
> _______________________________________________
> imapext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/imapext
>
>

---

From: Brandon Long <[email-masked]>
Date: Mon, 21 Oct 2013 16:02:54 -0700

I find it hard to believe that connection reuse here has that much of an
advantage as to be worth the implementation challenge for many
environments.  Certainly, there is high overhead in setting up an imap
connection beyond connect, but most of those things are also reset in this
proposal (see for ex the connection resume proposal a while back).

As we run in the proxy model outlined in the doc, handling this would be
challenging and require oob data on internal connection close.

I would also expect this to impact the throughput of the system as the
third party queues updates to reuse connections instead of just applying
them in parallel.

Brandon
On Oct 21, 2013 1:03 PM, "Chris Newman" <[email-masked]> wrote:

>  <http://www.ietf.org/id/draft-**newman-imap-unauth-00.txt<http://www.ietf.org/id/draft-newman-imap-unauth-00.txt>
> >
>
> The basic approach for the service acting on behalf of multiple users is
> to use SASL PLAIN to authenticate as the target user (authorization
> identity) with administrative credentials (authentication identity). The
> service can then issue standard IMAP commands as that user, and then
> UNAUTHENTICATE to reuse the connection.
>
> --On September 10, 2013 21:10:42 +0800 Nigar Sultana <
> [email-masked]> wrote:
>
>  Dear Alexey and Dave,
>>
>> User-A->defaultFolder->**session1->Msg1......Msgn
>> User-A->defaultFolder->**session2->Msg1.......Msgn
>> ______________________________**__
>> http://www.rfc-editor.org/rfc/**rfc2342.txt<http://www.rfc-editor.org/rfc/rfc2342.txt>(IMAP NAMESPACE) should solve
>> your problem.
>>
>>
>> CREATE "Other Users/[email-masked]/INBOX/**TemporaryFolder<http://[email-masked]/INBOX/TemporaryFolder>
>> "
>>
>>
> ______________________________**_________________
> imapext mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/imapext<https://www.ietf.org/mailman/listinfo/imapext>
>

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 22 Oct 2013 08:58:02 +0200

JFYI, consider it a digression,

I know someone else who does the same thing and uses Oauth. The IMAP
server supports an Oauth SASL mechanism, the user blesses the agent,
and the agent logs in with Oauth credentials.

Arnt

---

From: Chris Newman <[email-masked]>
Date: Tue, 22 Oct 2013 13:54:05 -0700

scenario:
>...
> Seems a bit scary extension to me.

LDAP has UNBIND in the base specification. I think UNAUTHENTICATE is only 
'scary' because I bothered to think through the security implications and 
write them down.

> I'm going to try to avoid implementing

I'm proposing this as an extension that's useful for the 
server-acting-on-behalf-of scenario. I don't think every IMAP server should 
implement it; only those that need it. Of course if my server is the only 
implementation then there's no point going standards track. Is anyone else 
interested in implementing this?

If you're interested in traffic isolation, I've been contemplating the idea 
of running IMAP on two ports with different behaviors -- an end-user port 
and an admin port. If I do that, in addition to having UNAUTHENTICATE only 
on the admin port, I'd make SASL-admin-proxy authentication only work on 
the admin imap port. If the admin imap port is blocked at the firewall, 
that's better security then doing everything on 143/993. I'm thinking of 
mentioning this as a mitigation in the security considerations. Any 
thoughts on whether it would be helpful to register a well-known port for 
admin imap?

> I've understood TLS session reuse would make this much faster? I haven't
> bothered to implement it so far yet though.

Does it help if it isn't implemented? ;-) TLS session reuse still requires 
multiple round-trips for TCP setup and a round trip for TLS setup. And the 
code is far more complex than unauthenticate in many cases. Plus the 
requirement we get from these peer servers is always "we need a way to 
reuse open connections", not "we need a relatively efficient TLS session 
reuse mechanism". Implementers like the model with which they're familiar.

--On October 21, 2013 16:29:25 -0400 Cyrus Daboo <[email-masked]> wrote:
> identity within the same connected IMAP session, but it is not OK to
> change the authentication identity? I think that covers the main use case
> whilst adding a little more security.

That makes the security model more complex and increases the size of the 
security sensitive code (thus increasing the attack surface). I'd then have 
to save the identity information between authentication session contexts, 
provide a way to pass in previous-identity information, and provide 
behavior variations based on previous-identity information. It adds some 
new rather complex test cases. I'm not a fan of this idea.

> user is a known "trusted" user (i.e., one of the admin accounts).
> Certainly allowing UNAUTHENTICATE for "arbitrary" users would be scarier.

This is an excellent idea. The code to do this is all post-authentication 
so there's no impact to the primary attack surface. I'll add it to the next 
version of the specification.

--On October 22, 2013 1:18:51 +0300 Timo Sirainen <[email-masked]> wrote:
> Yeah. Still, it's not something I'm looking forward to implementing.
> Dovecot's security model makes it slightly difficult to implement for
> some configurations (switching between different UNIX UIDs - possible of
> course, but not nice).

I wouldn't recommend implementing UNAUTHENTICATE in a server with the 
different UNIX UID security model. It's a classic performance-vs-security 
tradeoff, and if you implemented the different UNIX UID model, you're 
already on the security side of that tradeoff and I doubt the value of 
unauthenticate would be worth the cost in that case. I'll note that a smart 
proxy could implement UNAUTHENTICATE even if the back-end server does not 
so that may be one way to get some of the benefits without impacting the 
back-end security model.

> proposal (see for ex the connection resume proposal a while back).

For our backend IMAP server, the implementation was almost trivial as it 
involved splitting the IMAP context datastructure cleanup code already used 
by LOGOUT into two parts -- an unauthenticate part and a logout part. Then 
walk through and zero out most of the other datastructure fields in the 
unauthenticate routine. So this was a very good cost/benefit for us.

> challenging and require oob data on internal connection close.

We presently use the same proxy model, but I think this is one of the 
lesser problems with that model and think moving to a full smart proxy is 
the right way to address this. The proxy problem can be avoided if the peer 
servers that use unauthenticate bypass the proxy and connect directly to 
the user's mailHost.

> third party queues updates to reuse connections instead of just applying

I expect they use the standard connection-pool model. If a re-usable 
connection is idle in the pool, then use it, if not then create a new 
connection if below the max pool connection limit. Our embedded LDAP client 
does this and it works great as long as you don't over-design it.

		- Chris