Re: [Imap-protocol] STARTTLS after PREAUTH
Michael M Slusarz <[email protected]>
| Newsgroups | gmane.mail.imap.general |
|---|---|
| Message-ID | <20140318152549.Horde.0C2tXb4vwx_29xt0ZbwdEQ4@bigworm.curecanti.org> |
Quoting Jan Kundrát <[email protected]>: > 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 _______________________________________________ Imap-protocol mailing list [email protected] http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol