AUTH=PLAIN support

AUTH=PLAIN support

[Lars Magne Ingebrigtsen]

If the IMAP server says that is supports AUTH=PLAIN, then nnimap will
now use AUTHENTICATE PLAIN instead of LOGIN.  Let me know whether this
leads to any problems.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: AUTH=PLAIN support

[Tibor Simko]

On Sat, 30 Oct 2010, Lars Magne Ingebrigtsen wrote:
> If the IMAP server says that is supports AUTH=PLAIN, then nnimap will
> now use AUTHENTICATE PLAIN instead of LOGIN.  Let me know whether this
> leads to any problems.

Yes, commit a8b95f9df4992048eb90a5e4a84d7bc81bdfc282 leads to troubles
on MS Exchange 2010 for me:

--8<---------------cut here---------------start------------->8---
Warning: Opening nnimap server on imap.foo.com...failed: BAD Command
Argument Error. 12; Denied server nnimap+imap.foo.com; Opening nnimap
server on imap.foo.com...failed: BAD Command Argument Error. 12

2 BAD Command Argument Error. 12

Process *nnimap* killed

21:19:12 1 CAPABILITY
21:19:16 2 AUTHENTICATE PLAIN xxxxxxxxxxxxxxxxxxxxxxxx
--8<---------------cut here---------------end--------------->8---

Best regards
-- 
Tibor Simko

Re: AUTH=PLAIN support

[Lars Magne Ingebrigtsen]

Tibor Simko <tibor.simko@cern.ch> writes:

> Yes, commit a8b95f9df4992048eb90a5e4a84d7bc81bdfc282 leads to troubles
> on MS Exchange 2010 for me:
> Warning: Opening nnimap server on imap.foo.com...failed: BAD Command
> Argument Error. 12; Denied server nnimap+imap.foo.com; Opening nnimap
> server on imap.foo.com...failed: BAD Command Argument Error. 12

Darn.

If you go to the "*nnimap <server> ...*" buffer and eval

nnimap-object

what does it say?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: AUTH=PLAIN support

[Tibor Simko]

On Sat, 30 Oct 2010, Lars Magne Ingebrigtsen wrote:
> nnimap-object
>
> what does it say?

I'm now on gnus eca0ea5785cbc60125202c7e5ddd2b614e64c5bc (=last good
version for me), and nnimap-object typically looks like:

--8<---------------cut here---------------start------------->8---
[cl-struct-nnimap "mail.zyxxy.xyzzy" #<process *nnimap*> nil
                  ("IMAP4" "IMAP4REV1" "AUTH=PLAIN" "CHILDREN" "IDLE" "NAMESPACE" "LITERAL+")
                  (t
                   ("OK"
                    ("READ-WRITE")
                    "SELECT" "completed.")
                   ("572" "EXISTS")
                   ("0" "RECENT")
                   ("FLAGS"
                    ("\\Seen" "\\Answered" "\\Flagged" "\\Deleted" "\\Draft" "$MDNSent"))
                   ("OK"
                    ("PERMANENTFLAGS" "(\\Seen" "\\Answered" "\\Flagged" "\\Deleted" "\\Draft" "$MDNSent)")
                    "Permanent" "flags")
                   ("OK"
                    ("UNSEEN" "571")
                    "Is" "the" "first" "unseen" "message")
                   ("OK"
                    ("UIDVALIDITY" "1109")
                    "UIDVALIDITY" "value")
                   ("OK"
                    ("UIDNEXT" "6676")
                    "The" "next" "unique" "identifier" "value"))
                  nil "imap.foo.com"
                  (19660 30995 114637)
                  "* OK The Microsoft Exchange IMAP4 service is ready.^M"]
--8<---------------cut here---------------end--------------->8---

BTW, if you are looking at IMAP capabilities, I noticed a difference in
that Exchange 2010 returns solely AUTH=PLAIN even when one authenticates
via SSL, while Exchange 2007 returned also AUTH=NTLM AUTH=GSSAPI for
authenticated users (and AUTH=PLAIN for anonymous connections).  See the
sample CAPABILITY outputs I posted previously:
<http://article.gmane.org/gmane.emacs.gnus.general/72654>

Best regards
-- 
Tibor Simko

Re: AUTH=PLAIN support

[Lars Magne Ingebrigtsen]

Tibor Simko <tibor.simko@cern.ch> writes:

>                   ("IMAP4" "IMAP4REV1" "AUTH=PLAIN" "CHILDREN" "IDLE" "NAMESPA

[...]

>                   "* OK The Microsoft Exchange IMAP4 service is ready.^M"]

Ok...  then we have one server type that says "AUTH=PLAIN", but doesn't
accept "AUTHENTICATE PLAIN" anyway (Exchange 2010), and we have another
user with a server that says "AUTH=PLAIN" (Zimbra) that doesn't accept
anything but "AUTHENTICATE PLAIN" ("LOGIN" doesn't work).

Does anybody know what the deal is here?  I don't really understand what
the purpose of "AUTHENTICATE PLAIN" is anyway -- it's just a
base64-encoded version of what "LOGIN" sends, so it seems totally
nonsensical.  But it'd be nice if nnimap could do the right thing here
automatically.

So does anybody know what combinations of capabilities should trigger
"AUTHENTICATE PLAIN" that works across the board?

> BTW, if you are looking at IMAP capabilities, I noticed a difference in
> that Exchange 2010 returns solely AUTH=PLAIN even when one authenticates
> via SSL, while Exchange 2007 returned also AUTH=NTLM AUTH=GSSAPI for
> authenticated users (and AUTH=PLAIN for anonymous connections).

You don't authenticate via SSL, do you?  That's just a transport, not an
authentication mechanism?  (If I have my terminologies right.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: AUTH=PLAIN support

[Tibor Simko]

On Sat, 30 Oct 2010, Lars Magne Ingebrigtsen wrote:
> You don't authenticate via SSL, do you?  That's just a transport, not
> an authentication mechanism?  (If I have my terminologies right.)

Yeah, sorry if my wording was too lousy, I meant when one connects to
secure IMAP port 993 via SSL and asks for CAPABILITY without issuing
LOGIN command first (or after issuing LOGIN command).  Exchange 2007
responds differently WRT AUTH, unlike Exchange 2010.

Best regards
-- 
Tibor Simko

Re: AUTH=PLAIN support

[James Cloos]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

LMI> Ok...  then we have one server type that says "AUTH=PLAIN", but doesn't
LMI> accept "AUTHENTICATE PLAIN" anyway (Exchange 2010), and we have another
LMI> user with a server that says "AUTH=PLAIN" (Zimbra) that doesn't accept
LMI> anything but "AUTHENTICATE PLAIN" ("LOGIN" doesn't work).

If clients MUST use AUTHENTICATE, then the server MUST report LOGINDISABLED
in its capabilities.

It seems that the idea was to elimitate the LOGIN command on STARTTLS-capable
servers, but they still needed a plain-text passwd option.  And so created
AUTH=PLAIN to cover that requirement.

The IMAP-TLS RFC (2505) does say that AUTH=PLAIN should never be used on
an unencrypted socket.  (It was necessary because systems which use
/etc/passwd cannot authenticate unless the plain text passwd is available
server-side.)

Or at least that is what I divine from the RFCs. ☺

LMI> So does anybody know what combinations of capabilities should trigger
LMI> "AUTHENTICATE PLAIN" that works across the board?

Probably 'AUTH=PLAIN LOGINDISABLED'.

LMI> You don't authenticate via SSL, do you?  That's just a transport,
LMI> not an authentication mechanism?  (If I have my terminologies right.)

If the server and client support TLS client certs, all of AAA can happen
at that layer.  Once such a TLS session is up, then the IMAP level would
be PREAUTH.

If the session uses port 993 w/ a client cert, then the intial IMAP
greeting would be PREAUTH.

If the session uses STARTTLS, then the first prompt after TLS starts
would be PREAUTH.

In practice, though, I'm not aware of any clients or servers which
support using TLS client certs to pre-authenticate the IMAP session.

But the above is how it is supposed to work, and tls aaa would be the
most secure way to use tls with imap.

(I would note that the certs do not have to be x509.  There are options
to use openpgp keys as either server or client certs in tls, and there is
also a standard for using plain text passwds at the tls layer.)

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: AUTH=PLAIN support

[Lars Magne Ingebrigtsen]

James Cloos <cloos@jhcloos.com> writes:

> If clients MUST use AUTHENTICATE, then the server MUST report LOGINDISABLED
> in its capabilities.

Ah, right.  I've now added this to the nnimap login sequence.

> It seems that the idea was to elimitate the LOGIN command on STARTTLS-capable
> servers, but they still needed a plain-text passwd option.  And so created
> AUTH=PLAIN to cover that requirement.

It seems kinda weird, though.  AUTHENTICATE PLAIN is just basically a
base64-encoded version of LOGIN, so I'm not quite understanding what the
point is...

> If the server and client support TLS client certs, all of AAA can happen
> at that layer.  Once such a TLS session is up, then the IMAP level would
> be PREAUTH.

Ah, right.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: AUTH=PLAIN support

[James Cloos]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

LMI> It seems kinda weird, though.  AUTHENTICATE PLAIN is just basically a
LMI> base64-encoded version of LOGIN, so I'm not quite understanding what the
LMI> point is...

I'm sure the discourse went something like:

TLSsupporter> kill off LOGIN! kill off LOGIN! kill off LOGIN!

StatusQuo> But we need to auth against out /etc/shadow, and that
StatusQuo> requires the user send their secret to the server

and AUTH=PLAIN was the compromize.

And the TLS guys should prefer TLS client cert aaa anyway.

On the plus side, it does allow the separation of authentication and
authorization realms, so that, eg, the each support tech at example.com
could log in to the support@example.com account as themselves.  That
would allow the audit logs to show exactly who did what.

But, yes, otherwise it is just /different/ than LOGIN, not better.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: AUTH=PLAIN support

[Russ Allbery]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> James Cloos <cloos@jhcloos.com> writes:

>> It seems that the idea was to elimitate the LOGIN command on
>> STARTTLS-capable servers, but they still needed a plain-text passwd
>> option.  And so created AUTH=PLAIN to cover that requirement.

> It seems kinda weird, though.  AUTHENTICATE PLAIN is just basically a
> base64-encoded version of LOGIN, so I'm not quite understanding what the
> point is...

Passwords with trailing or embedded whitespace were causing all sorts of
problems with LOGIN.  I suspect PLAIN may have more formalization around
character set issues, too.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: AUTH=PLAIN support

[Lars Magne Ingebrigtsen]

Russ Allbery <rra@stanford.edu> writes:

> Passwords with trailing or embedded whitespace were causing all sorts of
> problems with LOGIN.  I suspect PLAIN may have more formalization around
> character set issues, too.

Ah, right.  That makes sense...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: AUTH=PLAIN support

[Tibor Simko]

On Sun, 31 Oct 2010, Lars Magne Ingebrigtsen wrote:
> James Cloos <cloos@jhcloos.com> writes:
>
>> If clients MUST use AUTHENTICATE, then the server MUST report LOGINDISABLED
>> in its capabilities.
>
> Ah, right.  I've now added this to the nnimap login sequence.

Thanks.

Best regards
-- 
Tibor Simko