Subject: [imapext] IMAP UNAUTHENTICATE (was Re: RFC 3501 - IMAP CREATE)

From: Alexey Melnikov <[email-masked]>
Date: Sat, 02 Nov 2013 15:00:35 -0700

Hi Chris,

On 22/10/2013 21:54, Chris Newman wrote:
> --On October 21, 2013 23:14:00 +0300 Timo Sirainen <[email-masked]> wrote:
>> 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:
>>> <http://www.ietf.org/id/draft-newman-imap-unauth-00.txt>
>> ...
>> 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.
Indeed. I like your draft, as it spells out pretty much everything.
>> 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.
>
> 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?
I nearly implemented this a couple of years ago. I might revisit this.

One comment about the draft: I am not sure about SASL security layer 
termination on UNAUTHENTICATE, but this is a minor point, considering 
that they are not used very often.
> 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?
This might be a good idea.

  [...]
> --On October 21, 2013 16:29:25 -0400 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.
>
> 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.
I don't like it either.
>> 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.
>
> 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.