MBOX-Line: From slusarz at curecanti.org  Tue Mar 18 14:25:49 2014
To: imap-protocol@u.washington.edu
From: Michael M Slusarz <slusarz@curecanti.org>
Date: Fri Jun  8 12:34:52 2018
Subject: [Imap-protocol] STARTTLS after PREAUTH
In-Reply-To: <059bac1f-35eb-4f87-bd5e-e986dfb46b83@flaska.net>
References: <20140318141305.Horde.iyy0UP8Ostx9TojRZiFyjw1@bigworm.curecanti.org>
	<059bac1f-35eb-4f87-bd5e-e986dfb46b83@flaska.net>
Message-ID: <20140318152549.Horde.0C2tXb4vwx_29xt0ZbwdEQ4@bigworm.curecanti.org>

Quoting Jan Kundr?t <jkt@flaska.net>:

> On Tuesday, 18 March 2014 21:13:05 CEST, Michael M Slusarz wrote:
>> In other words: was STARTTLS solely designed to protect  
>> authentication credentials (security) and not message data (privacy)?
>
> Not at all. Once issued, STARTTLS protects everything, i.e. both  
> your credentials and transfers of all messages.

Except as defined in base spec, STARTTLS is defined as "you are  
allowed to protect privacy ONLY if you protect authentication".  In  
the absence of a need to protect authentication, you can't protect  
privacy.

>> I guess the workaround for a situation where you *could*  
>> preauthenticate based on connection factors/details, but still need  
>> message privacy, is to require some sort of dummy authentication  
>> (after initializing TLS layer).  Feels pretty hackish though.
>
> That's what you could get with AUTH EXTERNAL.

Not a part of the base IMAP spec, which is what I was talking about.

> Also, nothing prevents a server from going directly to PREAUTH if  
> the whole connection is using SSL/TLS ("port 993") with client  
> certificates.

STARTTLS deprecated the use of port 993, which isn't an official IMAP  
port FWIW.  It hasn't really happened, but still is good to avoid and  
end users appreciate it when they don't have to have any knowledge of  
port number.

I wish this did work with the STARTTLS command (i.e. PREAUTH response  
after STARTTLS in the above situation).  Unfortunately that isn't part  
of the spec either.

> I'm a bit confused by your message. How do you want to authenticate  
> your user? Specifically, what's the use case where you can safely  
> verify the user's identity, but cannot guarantee confidentiality of  
> the connection stream?

Simple real-world example would be a machine on an internal network  
that is guaranteed to belong to a certain user.

I don't really care one way or another - mainly wanted to verify to  
myself that I wasn't missing a valid use-case.

michael


