Subject: re: Further IESG feedback on draft-crispin-imapv-17.txt
From: [email-masked]
To: Mark Crispin <[email-masked]>
Cc: [email-masked], IMAP Mailing List <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked]
Date: Fri, 20 Sep 2002 14:30:19 -0700 (PDT)
List-Id: <ietf-imapext.imc.org>

> OK, here is what I have for draft 18, based upon all the comments which I have
> read.  Please try to give me feedback on whether or not this is will be
> acceptable to the IESG as soon as possible.  I'd like to send draft 18 by the
> end of the day today and hopefully not need a draft 19.

FYI, I just forwarded this to the IESG list.

				Ned

Date: Fri, 20 Sep 2002 14:29:23 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: RE: Further IESG feedback on draft-crispin-imapv-17.txt
To: [email-masked]
cc: Larry Osterman <[email-masked]>, [email-masked], IMAP Mailing List <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Fri, 20 Sep 2002 14:20:58 -0700 (PDT), [email-masked] wrote:
> > Other than that nit, I personally like the wording.
> Good.

Do *you* like the wording?  I hate to assume that "silence == yes" and would
prefer a definite "yes".

Date: Fri, 20 Sep 2002 14:20:58 -0700 (PDT)
From: [email-masked]
Subject: RE: Further IESG feedback on draft-crispin-imapv-17.txt
To: Larry Osterman <[email-masked]>
Cc: Mark Crispin <[email-masked]>, [email-masked], IMAP Mailing List <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> What's the standards track status on IMAP-TLS?

RFC 2595 is currently a proposed standard.

>  Won't citing it as a
> reference tie the base standard to a subsidiary standard?

I'm not sure what you mean by "subsidiary". If you mean does it create a
normative reference to RFC 2595 and from there to TLS and so on, the answer is
yes it does. Such references are to be expected and certainly aren't a problem
per se.

Normative references do become an issue should a specification want to advance
to draft. In this case we'd have to advance both the base IMAP specification
and RFC 2595 at the same time. And that cannot happen until TLS itself
advances. But again, this is an expected and normal part of the standards
process.

> Other than that nit, I personally like the wording.

Good.

				Ned

Content-Class: urn:content-classes:message
Subject: RE: Further IESG feedback on draft-crispin-imapv-17.txt
Date: Fri, 20 Sep 2002 13:59:01 -0700
From: "Larry Osterman" <[email-masked]>
To: "Mark Crispin" <[email-masked]>, <[email-masked]>
Cc: "IMAP Mailing List" <[email-masked]>, "IMAP Extensions WG" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

What's the standards track status on IMAP-TLS?  Won't citing it as a
reference tie the base standard to a subsidiary standard?  Other than
that nit, I personally like the wording.

Larry Osterman 

-----Original Message-----
From: Mark Crispin [mailto:[email-masked]] 
Sent: Friday, September 20, 2002 1:18 PM
To: [email-masked]
Cc: IMAP Mailing List; IMAP Extensions WG; [email-masked];
[email-masked]; [email-masked]
Subject: re: Further IESG feedback on draft-crispin-imapv-17.txt

OK, here is what I have for draft 18, based upon all the comments which
I have read.  Please try to give me feedback on whether or not this is
will be acceptable to the IESG as soon as possible.  I'd like to send
draft 18 by the end of the day today and hopefully not need a draft 19.

In AUTHENTICATE command, change:

           Note: a server implementation SHOULD NOT permit any
           plaintext password mechanisms unless the STARTTLS
           command described in [IMAP-TLS] has been negotiated.
           Client and server implementations SHOULD implement
           additional SASL mechanisms which do not use plaintext
           passwords, such the GSSAPI mechanism described in [SASL]
           and/or the [DIGEST-MD5] mechanism.

to:

           Note: a server implementation MUST implement a
           configuration in which it does NOT permit any plaintext
           password mechanisms, unless either the STARTTLS command
           described in [IMAP-TLS] has been negotiated or some other
           mechanism that protects the session from password
           snooping has been provided.  Server sites SHOULD NOT use
           any configuration which permits a plaintext password
           mechanism without such a protection mechanism against
           password snooping.  Client and server implementations
           SHOULD implement additional SASL mechanisms which do not
           use plaintext passwords, such the GSSAPI mechanism
           described in [SASL] and/or the [DIGEST-MD5] mechanism.

In LOGIN command, add:

        A server implementation MUST implement a configuration in
        which it advertises the LOGINDISABLED capability described
        in [IMAP-TLS] and does NOT permit the LOGIN command, unless
        either the STARTTLS command described in [IMAP-TLS] has
        been negotiated or some other mechanism that protects the
        session from password snooping has been provided.  Server
        sites SHOULD NOT use any configuration which permits the
        LOGIN command without such a protection mechanism against
        password snooping.  A client implementation MUST NOT send a
        LOGIN command if the LOGINDISABLED capability is
        advertised.

In Security Considerations, add:

   A server implementation MUST implement a configuration in which, at
   the time of authentication, requires that:
      (1) The STARTTLS command command described in [IMAP-TLS] has been
      negotiated.
   OR
      (2) Some other mechanism that protects the session from password
      snooping has been provided.
   OR
      (3) The following measures are in place:
         (a) The LOGINDISABLED capability as described in [IMAP-TLS] is
         advertised, and [SASL] mechanisms (such as PLAIN) which use
         plaintext passwords are NOT advertised in the CAPABILITY list.
      AND
         (b) The LOGIN command returns an error even if the password is
         correct.
      AND
         (c) The AUTHENTICATE command returns an error with all [SASL]
         mechanisms which use plaintext passwords, even if the password
         is correct.

Date: Fri, 20 Sep 2002 13:18:29 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: Further IESG feedback on draft-crispin-imapv-17.txt
To: [email-masked]
cc: IMAP Mailing List <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

OK, here is what I have for draft 18, based upon all the comments which I have
read.  Please try to give me feedback on whether or not this is will be
acceptable to the IESG as soon as possible.  I'd like to send draft 18 by the
end of the day today and hopefully not need a draft 19.

In AUTHENTICATE command, change:

           Note: a server implementation SHOULD NOT permit any
           plaintext password mechanisms unless the STARTTLS
           command described in [IMAP-TLS] has been negotiated.
           Client and server implementations SHOULD implement
           additional SASL mechanisms which do not use plaintext
           passwords, such the GSSAPI mechanism described in [SASL]
           and/or the [DIGEST-MD5] mechanism.

to:

           Note: a server implementation MUST implement a
           configuration in which it does NOT permit any plaintext
           password mechanisms, unless either the STARTTLS command
           described in [IMAP-TLS] has been negotiated or some other
           mechanism that protects the session from password
           snooping has been provided.  Server sites SHOULD NOT use
           any configuration which permits a plaintext password
           mechanism without such a protection mechanism against
           password snooping.  Client and server implementations
           SHOULD implement additional SASL mechanisms which do not
           use plaintext passwords, such the GSSAPI mechanism
           described in [SASL] and/or the [DIGEST-MD5] mechanism.

In LOGIN command, add:

        A server implementation MUST implement a configuration in
        which it advertises the LOGINDISABLED capability described
        in [IMAP-TLS] and does NOT permit the LOGIN command, unless
        either the STARTTLS command described in [IMAP-TLS] has
        been negotiated or some other mechanism that protects the
        session from password snooping has been provided.  Server
        sites SHOULD NOT use any configuration which permits the
        LOGIN command without such a protection mechanism against
        password snooping.  A client implementation MUST NOT send a
        LOGIN command if the LOGINDISABLED capability is
        advertised.

In Security Considerations, add:

   A server implementation MUST implement a configuration in which, at
   the time of authentication, requires that:
      (1) The STARTTLS command command described in [IMAP-TLS] has been
      negotiated.
   OR
      (2) Some other mechanism that protects the session from password
      snooping has been provided.
   OR
      (3) The following measures are in place:
         (a) The LOGINDISABLED capability as described in [IMAP-TLS] is
         advertised, and [SASL] mechanisms (such as PLAIN) which use
         plaintext passwords are NOT advertised in the CAPABILITY list.
      AND
         (b) The LOGIN command returns an error even if the password is
         correct.
      AND
         (c) The AUTHENTICATE command returns an error with all [SASL]
         mechanisms which use plaintext passwords, even if the password
         is correct.

Date: Fri, 20 Sep 2002 12:12:33 -0700 (PDT)
From: [email-masked]
Subject: Re: Further IESG feedback on draft-crispin-imapv-17.txt
To: Mark Crispin <[email-masked]>
Cc: "Jeffrey I. Schiller" <[email-masked]>, Larry Osterman <[email-masked]>, [email-masked], IMAP Mailing Liste <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked]
Sender: [email-masked]

> On Fri, 20 Sep 2002 13:28:08 -0400, Jeffrey I. Schiller wrote:
> > I can live with Mark's proposed paragraph.

> I think that's the only way out of this problem.

> As far as I can tell, the most that a server can do to address Cyrus' concern
> is to add LOGINDISABLED (described in RFC 2595), and remove plaintext SASL
> mechanisms (specifically PLAIN and LOGIN), from the CAPABILITY list.  Beyond
> that, we can not do anything more.

> If this is to be done, then it's more than just changing that paragraph in the
> AUTHENTICATE command.

> Let me issue a new draft with all this in mind.

Sounds like the right way to move forward to me.

				Ned

Date: Fri, 20 Sep 2002 11:34:25 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: Further IESG feedback on draft-crispin-imapv-17.txt
To: "Jeffrey I. Schiller" <[email-masked]>
cc: Larry Osterman <[email-masked]>, [email-masked], IMAP Mailing Liste <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 20 Sep 2002 13:28:08 -0400, Jeffrey I. Schiller wrote:
> I can live with Mark's proposed paragraph.

I think that's the only way out of this problem.

As far as I can tell, the most that a server can do to address Cyrus' concern
is to add LOGINDISABLED (described in RFC 2595), and remove plaintext SASL
mechanisms (specifically PLAIN and LOGIN), from the CAPABILITY list.  Beyond
that, we can not do anything more.

If this is to be done, then it's more than just changing that paragraph in the
AUTHENTICATE command.

Let me issue a new draft with all this in mind.

Date: Fri, 20 Sep 2002 11:29:07 -0700 (PDT)
From: [email-masked]
Subject: Re: Further IESG feedback on draft-crispin-imapv-17.txt
To: "Jeffrey I. Schiller" <[email-masked]>
Cc: Larry Osterman <[email-masked]>, [email-masked], IMAP Mailing Liste <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked]
Sender: [email-masked]

> So what is the lesser of two evils.

> 1)It is possible, and in fact done universally, the implement an IETF
>    Standard that sends passwords in the clear, even though we say that we
>    want secure protocols in the IETF and it has been at least three years
>    since we declared that the IETF would not standardize things with
>    plain text passwords...

> 2)We render all existing implementations non-conformant.

> An alternative that we discussed on the call which I don't believe Ned
> described was to reword the paragraph so that it was a MUST NOT unless
> the implementation or its user knew that the underlying transport was
> providing security (aka running IMAP over an SSH tunnel).

That suggestion was incorporated into the alternate wording I proposed.

				Ned

Date: Fri, 20 Sep 2002 13:33:29 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Steve Hole <[email-masked]>
cc: [email-masked], IMAP Mailing List <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Further IESG feedback on draft-crispin-imapv-17.txt
Sender: [email-masked]

Hi Mark,

--On Friday, September 20, 2002 9:22 AM -0700 Mark Crispin 
<[email-masked]> wrote:

|> I don't think there is
|> any practical way of forcing an IMAP server to turn off LOGIN in any kind
|> of open environment (University for example).
|
| Interestingly, it's easier for universities to turn off LOGIN (we have!)
| than it is for enterprises.  It just means that many clients don't work
| with our servers.  Of course, *our* preferred client works just fine...

Turning off LOGIN on the server won't stop clients that expect it to be 
present from sending the LOGIN command when SSL is not being used, thus 
exposing the plain text password. The bottom line is you cannot stop 
clients from sending LOGIN and exposing plain text passwords. The current 
draft does state clients SHOULD NOT use LOGIN except as a last restort and 
that is something that needs to be encouraged.

Also, the current (and proposed) wordings for the AUTHENTICATE command only 
suggest that the server should (must) not allow plain text passwords 
without SSL. I think the burden for that check should also lie with the 
client to prevent clients being tricked into sending plain text passwords 
over an insecure link, and I would like to see the wording changed to 
include clients doing this check.

-- 
Cyrus Daboo

Date: Fri, 20 Sep 2002 13:28:08 -0400
From: "Jeffrey I. Schiller" <[email-masked]>
Organization: Massachusetts Institute of Technology
To: Mark Crispin <[email-masked]>
CC: Larry Osterman <[email-masked]>, [email-masked], IMAP Mailing Liste <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked]
Subject: Re: Further IESG feedback on draft-crispin-imapv-17.txt
Sender: [email-masked]

I can live with Mark's proposed paragraph.

			-Jeff

Mark Crispin wrote:
> I share Larry's concern.
> 
> We agree with the IESG that this requirement should be "mandatory to
> implement".  What makes it untenable for us is the implication that an
> implementation which does not enforce "mandatory to deploy" is non-compliant.
> 
> Server implementors are not in a position to enforce "mandatory to deploy",
> and there are legitimate reasons why a site may choose to deploy unprotected
> plaintext authentication.
> 
> Note the following text in RFC 2595:
>    [...]  The PLAIN SASL mechanism
>    MUST NOT be advertised or used unless a strong encryption layer (such
>    as the provided by TLS) is active or backwards compatibility dictates
>    otherwise.
> 
> IESG approved this as standards-track for a new protocol (the PLAIN SASL
> mechanism) which did not have any standards-track legacy to consider.  IMAP,
> on the other hand, has a standards-track legacy and furthermore a production
> installed base dating from 1985.
> 
> This is, to put it mildly, inconsistent.
> 
> Is the following compromise be acceptable to the IESG?
> 
> Note: a server implementation MUST implement a configuration in which
>       it does NOT permit any plaintext password mechanisms unless the
>       STARTTLS command described in [IMAP-TLS] has been negotiated or
>       some other mechanism that protects the session from password
>       snooping has been provided.  Server sites SHOULD NOT use any
>       configuration which permits a plaintext password mechanism without
>       a protection mechanism against password snooping.  Client and
>       server implementations SHOULD implement additional SASL mechanisms
>       which do not use plaintext passwords, such the GSSAPI mechanism
>       described in [SASL] and/or the [DIGEST-MD5] mechanism.
> 
> This clearly puts the vendor off the hook if it has implemented the correct
> mode, even if the site chooses to use the incorrect mode.
> 

Date: Fri, 20 Sep 2002 13:22:25 -0400
From: "Jeffrey I. Schiller" <[email-masked]>
Organization: Massachusetts Institute of Technology
To: Larry Osterman <[email-masked]>
CC: [email-masked], IMAP Mailing Liste <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked]
Subject: Re: Further IESG feedback on draft-crispin-imapv-17.txt
Sender: [email-masked]

So what is the lesser of two evils.

1)It is possible, and in fact done universally, the implement an IETF
   Standard that sends passwords in the clear, even though we say that we
   want secure protocols in the IETF and it has been at least three years
   since we declared that the IETF would not standardize things with
   plain text passwords...

2)We render all existing implementations non-conformant.

An alternative that we discussed on the call which I don't believe Ned 
described was to reword the paragraph so that it was a MUST NOT unless 
the implementation or its user knew that the underlying transport was 
providing security (aka running IMAP over an SSH tunnel).

			-Jeff

Larry Osterman wrote:
> If you make this change, you instantly render the vast majority of the
> installed base of IMAP servers non compliant (read: ALL).
> 
> And I think that would be a bad thing.
> 
> The reason for the SHOULD NOT was that it allowed existing
> implementations enough weasel room to say they were compliant as long as
> they allowed a configuration option to disallow plaintext
> authentication, but the implementation could leave the plaintext
> mechanism in the server (either enabled or disabled by default, at the
> vendors desire).
> 
> If you make it a MUST NOT, then this implies that the plaintext
> mechanism must be REMOVED except under the cover of an alternative
> encryption mechanism.  And that breaks interoperability with the
> majority of servers and clients that exist in the wild, which is a less
> than optimal solution.
> 
> 
> 
> Larry Osterman 
> 
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, September 19, 2002 10:34 AM
> To: IMAP Mailing Liste; IMAP Extensions WG
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Further IESG feedback on draft-crispin-imapv-17.txt
> 
> 
> 
> The IESG had this on the agenda today. The various document nits seem to
> have been satisfactorily addressed. The IESG is also happy with the
> general way the big item in the previous feedback -- mandatory to
> implement security -- has been dealt with.
> 
> One concern remains, however. The following note appears in 6.2.1:
> 
> Note: a server implementation SHOULD NOT permit any
>       plaintext password mechanisms unless the STARTTLS
>       command described in [IMAP-TLS] has been negotiated.
>       Client and server implementations SHOULD implement
>       additional SASL mechanisms which do not use plaintext
>       passwords, such the GSSAPI mechanism described in [SASL]
>       and/or the [DIGEST-MD5] mechanism.
> 
> The IESG would like to push back even harder on the use of plain text
> passwords, and would like to see this changed to read:
> 
> Note: a server implementation MUST NOT permit any
>       plaintext password mechanisms unless the STARTTLS
>       command described in [IMAP-TLS] has been negotiated or some 
>       other mechanism that protects the session from password
>       snooping has been provided. Client and server implementations
>       SHOULD implement additional SASL mechanisms which do not use
>       plaintext passwords, such the GSSAPI mechanism described in
>       [SASL] and/or the [DIGEST-MD5] mechanism.
> 
> The reason the IESG would like to see this change made  should be
> obvious, but in case it is not: The IESG wants to mandate the use of
> mechanisms that insure password snooping isn't possible but recognizes
> that there are many ways to do this besides TLS: SSH, VPNs, physical
> network security, etc.
> 
> How do people feel about making this change?
> 
> 				Ned
> 

Date: Fri, 20 Sep 2002 09:22:18 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: Further IESG feedback on draft-crispin-imapv-17.txt
To: Steve Hole <[email-masked]>
cc: [email-masked], IMAP Mailing List <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Fri, 20 Sep 2002 08:58:29 -0700, Steve Hole wrote:
> I don't think there is
> any practical way of forcing an IMAP server to turn off LOGIN in any kind
> of open environment (University for example).

Interestingly, it's easier for universities to turn off LOGIN (we have!) than
it is for enterprises.  It just means that many clients don't work with our
servers.  Of course, *our* preferred client works just fine...

We do allow LOGIN if SSL or TLS is in effect.  Allowing LOGIN in SSL is
important, since otherwise you break Outlook and Netscape (neither of which
can do Kerberos or TLS).

From: Steve Hole <[email-masked]>
Date: Fri, 20 Sep 2002 08:58:29 -0700
To: [email-masked]
Subject: Re: Further IESG feedback on draft-crispin-imapv-17.txt
Cc: IMAP Mailing Liste <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Thu, 19 Sep 2002 10:34:10 -0700 (PDT) [email-masked] wrote:

> The IESG would like to push back even harder on the use of plain text
> passwords, and would like to see this changed to read:
> 
> Note: a server implementation MUST NOT permit any
>       plaintext password mechanisms unless the STARTTLS
>       command described in [IMAP-TLS] has been negotiated or some 
>       other mechanism that protects the session from password
>       snooping has been provided. Client and server implementations
>       SHOULD implement additional SASL mechanisms which do not use
>       plaintext passwords, such the GSSAPI mechanism described in
>       [SASL] and/or the [DIGEST-MD5] mechanism.
> 
> The reason the IESG would like to see this change made  should be obvious, but
> in case it is not: The IESG wants to mandate the use of mechanisms that insure
> password snooping isn't possible but recognizes that there are many ways to do
> this besides TLS: SSH, VPNs, physical network security, etc.
> 
> How do people feel about making this change?

Well, I think that it is a good idea in theory, but simply not practical 
at this point in time.   By making this change you will force all 
existing implementations into instant non-compliance, which means that 
they will simply continue to reference rfc2060 rather than the new RFC.

It's a difficult thing isn't it.   The problem is the weight of the 
formerly mandatory to implement LOGIN command and the pervasive use of 
LOGIN in all products.  As is usually the case, the servers aren't the 
problem here, it is the deployed base of clients.   I don't think there is
any practical way of forcing an IMAP server to turn off LOGIN in any kind 
of open environment (University for example).  The best servers will be 
able to do is to provide an "enforce no clear passwords" configuration 
switch that they can enable in the presence of a known set of compliant 
clients (closed enterprise).   The SHOULD wording supports that kind of 
evolutionary deployment model.

I would stay with the SHOULD wording for now.

Cheers.
---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Thu, 19 Sep 2002 17:08:58 -0700
From: Chris Newman <[email-masked]>
Subject: Re: Further IESG feedback on draft-crispin-imapv-17.txt
To: [email-masked], IMAP Mailing Liste <[email-masked]>, IMAP Extensions WG <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

I am absolutely opposed to the change the IESG has proposed because it will 
result in inadequate real-world security for the IMAP protocol.

RFC 2060 currently requires no security for IMAP.  So the unencrypted 
plaintext password mechanism is the only one that all IMAP products 
implement.  Customers purchasing IMAP software require interoperability and 
thus require support for unencrypted plaintext passwords.  The only upside 
is that SSL/TLS has deployed quite well.

The "SHOULD NOT" language greatly improves the situation because many 
vendors will comply with the spec and advertise that fact, and thus it will 
create market pressure for IMAP vendors to implement STARTTLS.

The "MUST NOT" language is not nearly as effective.  Because vendors can 
not comply with the new spec and meet customer requirements, they will 
ignore the spec and simply claim compliance with RFC 2060.  As a result, 
there will be no new market pressure to improve the status quo.

Therefore, the current "SHOULD NOT" language will provide better real-world 
security than the proposed "MUST NOT" language.

Mark's proposed compromise language is also acceptable and better than the 
current language.

                - Chris

begin  quotation by [email-masked] on 2002/9/19 10:34 -0700:

>
> The IESG had this on the agenda today. The various document nits seem to
> have been satisfactorily addressed. The IESG is also happy with the
> general way the big item in the previous feedback -- mandatory to
> implement security -- has been dealt with.
>
> One concern remains, however. The following note appears in 6.2.1:
>
> Note: a server implementation SHOULD NOT permit any
>       plaintext password mechanisms unless the STARTTLS
>       command described in [IMAP-TLS] has been negotiated.
>       Client and server implementations SHOULD implement
>       additional SASL mechanisms which do not use plaintext
>       passwords, such the GSSAPI mechanism described in [SASL]
>       and/or the [DIGEST-MD5] mechanism.
>
> The IESG would like to push back even harder on the use of plain text
> passwords, and would like to see this changed to read:
>
> Note: a server implementation MUST NOT permit any
>       plaintext password mechanisms unless the STARTTLS
>       command described in [IMAP-TLS] has been negotiated or some
>       other mechanism that protects the session from password
>       snooping has been provided. Client and server implementations
>       SHOULD implement additional SASL mechanisms which do not use
>       plaintext passwords, such the GSSAPI mechanism described in
>       [SASL] and/or the [DIGEST-MD5] mechanism.
>
> The reason the IESG would like to see this change made  should be
> obvious, but in case it is not: The IESG wants to mandate the use of
> mechanisms that insure password snooping isn't possible but recognizes
> that there are many ways to do this besides TLS: SSH, VPNs, physical
> network security, etc.
>
> How do people feel about making this change?
>
> 				Ned
>

Date: Thu, 19 Sep 2002 11:43:11 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: RE: Further IESG feedback on draft-crispin-imapv-17.txt
To: Larry Osterman <[email-masked]>
cc: [email-masked], IMAP Mailing Liste <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

I share Larry's concern.

We agree with the IESG that this requirement should be "mandatory to
implement".  What makes it untenable for us is the implication that an
implementation which does not enforce "mandatory to deploy" is non-compliant.

Server implementors are not in a position to enforce "mandatory to deploy",
and there are legitimate reasons why a site may choose to deploy unprotected
plaintext authentication.

Note the following text in RFC 2595:
   [...]  The PLAIN SASL mechanism
   MUST NOT be advertised or used unless a strong encryption layer (such
   as the provided by TLS) is active or backwards compatibility dictates
   otherwise.

IESG approved this as standards-track for a new protocol (the PLAIN SASL
mechanism) which did not have any standards-track legacy to consider.  IMAP,
on the other hand, has a standards-track legacy and furthermore a production
installed base dating from 1985.

This is, to put it mildly, inconsistent.

Is the following compromise be acceptable to the IESG?

Note: a server implementation MUST implement a configuration in which
      it does NOT permit any plaintext password mechanisms unless the
      STARTTLS command described in [IMAP-TLS] has been negotiated or
      some other mechanism that protects the session from password
      snooping has been provided.  Server sites SHOULD NOT use any
      configuration which permits a plaintext password mechanism without
      a protection mechanism against password snooping.  Client and
      server implementations SHOULD implement additional SASL mechanisms
      which do not use plaintext passwords, such the GSSAPI mechanism
      described in [SASL] and/or the [DIGEST-MD5] mechanism.

This clearly puts the vendor off the hook if it has implemented the correct
mode, even if the site chooses to use the incorrect mode.

Content-Class: urn:content-classes:message
Subject: RE: Further IESG feedback on draft-crispin-imapv-17.txt
Date: Thu, 19 Sep 2002 11:12:45 -0700
From: "Larry Osterman" <[email-masked]>
To: <[email-masked]>, "IMAP Mailing Liste" <[email-masked]>, "IMAP Extensions WG" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

If you make this change, you instantly render the vast majority of the
installed base of IMAP servers non compliant (read: ALL).

And I think that would be a bad thing.

The reason for the SHOULD NOT was that it allowed existing
implementations enough weasel room to say they were compliant as long as
they allowed a configuration option to disallow plaintext
authentication, but the implementation could leave the plaintext
mechanism in the server (either enabled or disabled by default, at the
vendors desire).

If you make it a MUST NOT, then this implies that the plaintext
mechanism must be REMOVED except under the cover of an alternative
encryption mechanism.  And that breaks interoperability with the
majority of servers and clients that exist in the wild, which is a less
than optimal solution.

Larry Osterman 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, September 19, 2002 10:34 AM
To: IMAP Mailing Liste; IMAP Extensions WG
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Further IESG feedback on draft-crispin-imapv-17.txt

The IESG had this on the agenda today. The various document nits seem to
have been satisfactorily addressed. The IESG is also happy with the
general way the big item in the previous feedback -- mandatory to
implement security -- has been dealt with.

One concern remains, however. The following note appears in 6.2.1:

Note: a server implementation SHOULD NOT permit any
      plaintext password mechanisms unless the STARTTLS
      command described in [IMAP-TLS] has been negotiated.
      Client and server implementations SHOULD implement
      additional SASL mechanisms which do not use plaintext
      passwords, such the GSSAPI mechanism described in [SASL]
      and/or the [DIGEST-MD5] mechanism.

The IESG would like to push back even harder on the use of plain text
passwords, and would like to see this changed to read:

Note: a server implementation MUST NOT permit any
      plaintext password mechanisms unless the STARTTLS
      command described in [IMAP-TLS] has been negotiated or some 
      other mechanism that protects the session from password
      snooping has been provided. Client and server implementations
      SHOULD implement additional SASL mechanisms which do not use
      plaintext passwords, such the GSSAPI mechanism described in
      [SASL] and/or the [DIGEST-MD5] mechanism.

The reason the IESG would like to see this change made  should be
obvious, but in case it is not: The IESG wants to mandate the use of
mechanisms that insure password snooping isn't possible but recognizes
that there are many ways to do this besides TLS: SSH, VPNs, physical
network security, etc.

How do people feel about making this change?

				Ned

Date: Thu, 19 Sep 2002 10:34:10 -0700 (PDT)
From: [email-masked]
Subject: Further IESG feedback on draft-crispin-imapv-17.txt
To: IMAP Mailing Liste <[email-masked]>, IMAP Extensions WG <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

The IESG had this on the agenda today. The various document nits seem to have
been satisfactorily addressed. The IESG is also happy with the general way the
big item in the previous feedback -- mandatory to implement security -- has
been dealt with.

One concern remains, however. The following note appears in 6.2.1:

Note: a server implementation SHOULD NOT permit any
      plaintext password mechanisms unless the STARTTLS
      command described in [IMAP-TLS] has been negotiated.
      Client and server implementations SHOULD implement
      additional SASL mechanisms which do not use plaintext
      passwords, such the GSSAPI mechanism described in [SASL]
      and/or the [DIGEST-MD5] mechanism.

The IESG would like to push back even harder on the use of plain text
passwords, and would like to see this changed to read:

Note: a server implementation MUST NOT permit any
      plaintext password mechanisms unless the STARTTLS
      command described in [IMAP-TLS] has been negotiated or some 
      other mechanism that protects the session from password
      snooping has been provided. Client and server implementations
      SHOULD implement additional SASL mechanisms which do not use
      plaintext passwords, such the GSSAPI mechanism described in
      [SASL] and/or the [DIGEST-MD5] mechanism.

The reason the IESG would like to see this change made  should be obvious, but
in case it is not: The IESG wants to mandate the use of mechanisms that insure
password snooping isn't possible but recognizes that there are many ways to do
this besides TLS: SSH, VPNs, physical network security, etc.

How do people feel about making this change?

				Ned

Date: Tue, 10 Sep 2002 15:17:10 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: IMAP Extensions WG <[email-masked]>
Subject: IMAPEXT meeting in Atlanta?
Sender: [email-masked]

What people think about having a meeting in Atlanta?
Topics to discuss:
 ACL2 (I will do a revision before the meeting)
 Message and mailbox annotations
 LISTEXT (Barry, where is a new revision? ;-))

If people have interest (I know, this is outside of the Charter):
 VPIM related IMAP stuff;
 QUOTA2 (my new draft with Dave Cridland);
 "Disconnected mail clients" document.

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

Date: Wed, 04 Sep 2002 22:25:37 -0400
From: Tony Hansen <[email-masked]>
To: Chris Newman <[email-masked]>
CC: vpim <[email-masked]>, imapext <[email-masked]>
Subject: Re: non-standard ProxyAuth extension?
Sender: [email-masked]

Don't worry -- I never wanted to implement it. But I've been putting 
together a list of arguments to use to convince others to not bother 
implementing it.

	Tony

Chris Newman wrote:
> 
> I concur 100% with Mark's opinion.  Use RFC 2595's PLAIN mechanism 
> instead, which is more widely implemented.
> 
>                - Chris
> 
> begin  quotation by Mark Crispin on 2002/9/4 11:05 -0700:
> 
>> The inferences that can be drawn from my comment may be the closest to an
>> answer that there is.  ProxyAuth was suggested by Netscape 5 years ago.
>> It was soundly denounced at the time as a flawed (security issues,
>> filesystem dependencies) and unnecessary (SASL provides a superior
>> mechanism that is multiprotocol as well) idea.  As far as I can tell, the
>> document never went beyond draft 00.
>>
>> It can be inferred that only Netscape ever implemented it (assuming that
>> they did, and that it is still in the Netscape server).  Since there is
>> no reason to implement it, it can be inferred that there will be no new
>> implementations.
>>
>> That, in turn, leads to the inference that it is not "common"; or at
>> least no more "common" than the Netscape server.
>>
>> I've been contacted by VPIM folks from time to time about deploying my
>> server with VPIM clients.  Given that the UW server does not implement
>> ProxyAuth, I infer that the VPIM community does not depend upon it.  This
>> inference is strengthed by the fact that ProxyAuth is *not* one of the
>> things which the VPIM community has asked the IMAP community to work on.
>>
>> Given the architectural flaws (including security design flaws) in
>> ProxyAuth, this all should be quite enough to declare ProxyAuth to be
>> dead, and not to be used or implemented.
>>
>> On Wed, 04 Sep 2002 13:27:03 -0400, Tony Hansen wrote:
>>
>>> Mark, I don't disagree. However, I still need my questions answered.
>>> Mark Crispin wrote:
>>> > I don't see any reason to implement ProxyAuth now that we have a
>>> > superior mechanism in SASL.
>>
>>
> 
> 

Date: Wed, 04 Sep 2002 13:04:02 -0700
From: Chris Newman <[email-masked]>
Subject: Re: non-standard ProxyAuth extension?
To: Tony Hansen <[email-masked]>
Cc: vpim <[email-masked]>, imapext <[email-masked]>
Sender: [email-masked]

I concur 100% with Mark's opinion.  Use RFC 2595's PLAIN mechanism instead, 
which is more widely implemented.

                - Chris

begin  quotation by Mark Crispin on 2002/9/4 11:05 -0700:
> The inferences that can be drawn from my comment may be the closest to an
> answer that there is.  ProxyAuth was suggested by Netscape 5 years ago.
> It was soundly denounced at the time as a flawed (security issues,
> filesystem dependencies) and unnecessary (SASL provides a superior
> mechanism that is multiprotocol as well) idea.  As far as I can tell, the
> document never went beyond draft 00.
>
> It can be inferred that only Netscape ever implemented it (assuming that
> they did, and that it is still in the Netscape server).  Since there is
> no reason to implement it, it can be inferred that there will be no new
> implementations.
>
> That, in turn, leads to the inference that it is not "common"; or at
> least no more "common" than the Netscape server.
>
> I've been contacted by VPIM folks from time to time about deploying my
> server with VPIM clients.  Given that the UW server does not implement
> ProxyAuth, I infer that the VPIM community does not depend upon it.  This
> inference is strengthed by the fact that ProxyAuth is *not* one of the
> things which the VPIM community has asked the IMAP community to work on.
>
> Given the architectural flaws (including security design flaws) in
> ProxyAuth, this all should be quite enough to declare ProxyAuth to be
> dead, and not to be used or implemented.
>
> On Wed, 04 Sep 2002 13:27:03 -0400, Tony Hansen wrote:
>> Mark, I don't disagree. However, I still need my questions answered.
>> Mark Crispin wrote:
>> > I don't see any reason to implement ProxyAuth now that we have a
>> > superior mechanism in SASL.
>

Date: Wed, 04 Sep 2002 15:33:59 -0400
From: Tony Hansen <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: vpim <[email-masked]>, imapext <[email-masked]>
Subject: Re: non-standard ProxyAuth extension?
Sender: [email-masked]

Thanks Mark!

	Tony

Mark Crispin wrote:
> The inferences that can be drawn from my comment may be the closest to an
> answer that there is.  ProxyAuth was suggested by Netscape 5 years ago.  It
> was soundly denounced at the time as a flawed (security issues, filesystem
> dependencies) and unnecessary (SASL provides a superior mechanism that is
> multiprotocol as well) idea.  As far as I can tell, the document never went
> beyond draft 00.
> 
> It can be inferred that only Netscape ever implemented it (assuming that they
> did, and that it is still in the Netscape server).  Since there is no reason
> to implement it, it can be inferred that there will be no new implementations.
> 
> That, in turn, leads to the inference that it is not "common"; or at least no
> more "common" than the Netscape server.
> 
> I've been contacted by VPIM folks from time to time about deploying my server
> with VPIM clients.  Given that the UW server does not implement ProxyAuth, I
> infer that the VPIM community does not depend upon it.  This inference is
> strengthed by the fact that ProxyAuth is *not* one of the things which the
> VPIM community has asked the IMAP community to work on.
> 
> Given the architectural flaws (including security design flaws) in ProxyAuth,
> this all should be quite enough to declare ProxyAuth to be dead, and not to be
> used or implemented.
> 
> On Wed, 04 Sep 2002 13:27:03 -0400, Tony Hansen wrote:
> 
>>Mark, I don't disagree. However, I still need my questions answered.
>>Mark Crispin wrote:
>>
>>>I don't see any reason to implement ProxyAuth now that we have a superior
>>>mechanism in SASL.
>>
> 

Date: Wed, 4 Sep 2002 11:05:58 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: non-standard ProxyAuth extension?
To: Tony Hansen <[email-masked]>
cc: vpim <[email-masked]>, imapext <[email-masked]>
Sender: [email-masked]

The inferences that can be drawn from my comment may be the closest to an
answer that there is.  ProxyAuth was suggested by Netscape 5 years ago.  It
was soundly denounced at the time as a flawed (security issues, filesystem
dependencies) and unnecessary (SASL provides a superior mechanism that is
multiprotocol as well) idea.  As far as I can tell, the document never went
beyond draft 00.

It can be inferred that only Netscape ever implemented it (assuming that they
did, and that it is still in the Netscape server).  Since there is no reason
to implement it, it can be inferred that there will be no new implementations.

That, in turn, leads to the inference that it is not "common"; or at least no
more "common" than the Netscape server.

I've been contacted by VPIM folks from time to time about deploying my server
with VPIM clients.  Given that the UW server does not implement ProxyAuth, I
infer that the VPIM community does not depend upon it.  This inference is
strengthed by the fact that ProxyAuth is *not* one of the things which the
VPIM community has asked the IMAP community to work on.

Given the architectural flaws (including security design flaws) in ProxyAuth,
this all should be quite enough to declare ProxyAuth to be dead, and not to be
used or implemented.

On Wed, 04 Sep 2002 13:27:03 -0400, Tony Hansen wrote:
> Mark, I don't disagree. However, I still need my questions answered.
> Mark Crispin wrote:
> > I don't see any reason to implement ProxyAuth now that we have a superior
> > mechanism in SASL.

Date: Wed, 04 Sep 2002 13:27:03 -0400
From: Tony Hansen <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: [email-masked], vpim <[email-masked]>, imapext <[email-masked]>
Subject: Re: non-standard ProxyAuth extension?
Sender: [email-masked]

Mark, I don't disagree. However, I still need my questions answered.

	Tony

Mark Crispin wrote:
> I don't see any reason to implement ProxyAuth now that we have a superior
> mechanism in SASL.
> 

Date: Wed, 4 Sep 2002 09:58:55 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: non-standard ProxyAuth extension?
To: Tony Hansen <[email-masked]>
cc: [email-masked], vpim <[email-masked]>, imapext <[email-masked]>
Sender: [email-masked]

I don't see any reason to implement ProxyAuth now that we have a superior
mechanism in SASL.

Date: Wed, 04 Sep 2002 12:54:41 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked], vpim <[email-masked]>, imapext <[email-masked]>
Subject: non-standard ProxyAuth extension?
Sender: [email-masked]

I just ran across a reference to a non-standard extension to imap called 
ProxyAuth. It is supposedly commonly provided by imap servers used for 
voice messaging. The spec I got was that you would first do a Login 
using an administrative ID:

	Login admin-id admin-password

You'd then use the ProxyAuth command to switch to a given user:

	ProxyAuth username

Logically, it's comparable to the SASL concept of having a separate 
authenticator id (the admin-id) from the authorization id (the username).

Is this really a common extension? Is there a writeup anywhere for it?

	Tony Hansen
	[email-masked]

Date: Fri, 20 Sep 2002 14:30:19 -0700 (PDT)
From: [email-masked]
Subject: re: Further IESG feedback on draft-crispin-imapv-17.txt
To: Mark Crispin <[email-masked]>
Cc: [email-masked], IMAP Mailing List <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> OK, here is what I have for draft 18, based upon all the comments which I have
> read.  Please try to give me feedback on whether or not this is will be
> acceptable to the IESG as soon as possible.  I'd like to send draft 18 by the
> end of the day today and hopefully not need a draft 19.

FYI, I just forwarded this to the IESG list.

				Ned

Date: Fri, 20 Sep 2002 14:29:23 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: RE: Further IESG feedback on draft-crispin-imapv-17.txt
To: [email-masked]
cc: Larry Osterman <[email-masked]>, [email-masked], IMAP Mailing List <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Fri, 20 Sep 2002 14:20:58 -0700 (PDT), [email-masked] wrote:
> > Other than that nit, I personally like the wording.
> Good.

Do *you* like the wording?  I hate to assume that "silence == yes" and would
prefer a definite "yes".

Date: Fri, 20 Sep 2002 14:20:58 -0700 (PDT)
From: [email-masked]
Subject: RE: Further IESG feedback on draft-crispin-imapv-17.txt
To: Larry Osterman <[email-masked]>
Cc: Mark Crispin <[email-masked]>, [email-masked], IMAP Mailing List <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> What's the standards track status on IMAP-TLS?

RFC 2595 is currently a proposed standard.

>  Won't citing it as a
> reference tie the base standard to a subsidiary standard?

I'm not sure what you mean by "subsidiary". If you mean does it create a
normative reference to RFC 2595 and from there to TLS and so on, the answer is
yes it does. Such references are to be expected and certainly aren't a problem
per se.

Normative references do become an issue should a specification want to advance
to draft. In this case we'd have to advance both the base IMAP specification
and RFC 2595 at the same time. And that cannot happen until TLS itself
advances. But again, this is an expected and normal part of the standards
process.

> Other than that nit, I personally like the wording.

Good.

				Ned

Content-Class: urn:content-classes:message
Subject: RE: Further IESG feedback on draft-crispin-imapv-17.txt
Date: Fri, 20 Sep 2002 13:59:01 -0700
From: "Larry Osterman" <[email-masked]>
To: "Mark Crispin" <[email-masked]>, <[email-masked]>
Cc: "IMAP Mailing List" <[email-masked]>, "IMAP Extensions WG" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

What's the standards track status on IMAP-TLS?  Won't citing it as a
reference tie the base standard to a subsidiary standard?  Other than
that nit, I personally like the wording.

Larry Osterman 

-----Original Message-----
From: Mark Crispin [mailto:[email-masked]] 
Sent: Friday, September 20, 2002 1:18 PM
To: [email-masked]
Cc: IMAP Mailing List; IMAP Extensions WG; [email-masked];
[email-masked]; [email-masked]
Subject: re: Further IESG feedback on draft-crispin-imapv-17.txt

OK, here is what I have for draft 18, based upon all the comments which
I have read.  Please try to give me feedback on whether or not this is
will be acceptable to the IESG as soon as possible.  I'd like to send
draft 18 by the end of the day today and hopefully not need a draft 19.

In AUTHENTICATE command, change:

           Note: a server implementation SHOULD NOT permit any
           plaintext password mechanisms unless the STARTTLS
           command described in [IMAP-TLS] has been negotiated.
           Client and server implementations SHOULD implement
           additional SASL mechanisms which do not use plaintext
           passwords, such the GSSAPI mechanism described in [SASL]
           and/or the [DIGEST-MD5] mechanism.

to:

           Note: a server implementation MUST implement a
           configuration in which it does NOT permit any plaintext
           password mechanisms, unless either the STARTTLS command
           described in [IMAP-TLS] has been negotiated or some other
           mechanism that protects the session from password
           snooping has been provided.  Server sites SHOULD NOT use
           any configuration which permits a plaintext password
           mechanism without such a protection mechanism against
           password snooping.  Client and server implementations
           SHOULD implement additional SASL mechanisms which do not
           use plaintext passwords, such the GSSAPI mechanism
           described in [SASL] and/or the [DIGEST-MD5] mechanism.

In LOGIN command, add:

        A server implementation MUST implement a configuration in
        which it advertises the LOGINDISABLED capability described
        in [IMAP-TLS] and does NOT permit the LOGIN command, unless
        either the STARTTLS command described in [IMAP-TLS] has
        been negotiated or some other mechanism that protects the
        session from password snooping has been provided.  Server
        sites SHOULD NOT use any configuration which permits the
        LOGIN command without such a protection mechanism against
        password snooping.  A client implementation MUST NOT send a
        LOGIN command if the LOGINDISABLED capability is
        advertised.

In Security Considerations, add:

   A server implementation MUST implement a configuration in which, at
   the time of authentication, requires that:
      (1) The STARTTLS command command described in [IMAP-TLS] has been
      negotiated.
   OR
      (2) Some other mechanism that protects the session from password
      snooping has been provided.
   OR
      (3) The following measures are in place:
         (a) The LOGINDISABLED capability as described in [IMAP-TLS] is
         advertised, and [SASL] mechanisms (such as PLAIN) which use
         plaintext passwords are NOT advertised in the CAPABILITY list.
      AND
         (b) The LOGIN command returns an error even if the password is
         correct.
      AND
         (c) The AUTHENTICATE command returns an error with all [SASL]
         mechanisms which use plaintext passwords, even if the password
         is correct.

Date: Fri, 20 Sep 2002 13:18:29 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: Further IESG feedback on draft-crispin-imapv-17.txt
To: [email-masked]
cc: IMAP Mailing List <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

OK, here is what I have for draft 18, based upon all the comments which I have
read.  Please try to give me feedback on whether or not this is will be
acceptable to the IESG as soon as possible.  I'd like to send draft 18 by the
end of the day today and hopefully not need a draft 19.

In AUTHENTICATE command, change:

           Note: a server implementation SHOULD NOT permit any
           plaintext password mechanisms unless the STARTTLS
           command described in [IMAP-TLS] has been negotiated.
           Client and server implementations SHOULD implement
           additional SASL mechanisms which do not use plaintext
           passwords, such the GSSAPI mechanism described in [SASL]
           and/or the [DIGEST-MD5] mechanism.

to:

           Note: a server implementation MUST implement a
           configuration in which it does NOT permit any plaintext
           password mechanisms, unless either the STARTTLS command
           described in [IMAP-TLS] has been negotiated or some other
           mechanism that protects the session from password
           snooping has been provided.  Server sites SHOULD NOT use
           any configuration which permits a plaintext password
           mechanism without such a protection mechanism against
           password snooping.  Client and server implementations
           SHOULD implement additional SASL mechanisms which do not
           use plaintext passwords, such the GSSAPI mechanism
           described in [SASL] and/or the [DIGEST-MD5] mechanism.

In LOGIN command, add:

        A server implementation MUST implement a configuration in
        which it advertises the LOGINDISABLED capability described
        in [IMAP-TLS] and does NOT permit the LOGIN command, unless
        either the STARTTLS command described in [IMAP-TLS] has
        been negotiated or some other mechanism that protects the
        session from password snooping has been provided.  Server
        sites SHOULD NOT use any configuration which permits the
        LOGIN command without such a protection mechanism against
        password snooping.  A client implementation MUST NOT send a
        LOGIN command if the LOGINDISABLED capability is
        advertised.

In Security Considerations, add:

   A server implementation MUST implement a configuration in which, at
   the time of authentication, requires that:
      (1) The STARTTLS command command described in [IMAP-TLS] has been
      negotiated.
   OR
      (2) Some other mechanism that protects the session from password
      snooping has been provided.
   OR
      (3) The following measures are in place:
         (a) The LOGINDISABLED capability as described in [IMAP-TLS] is
         advertised, and [SASL] mechanisms (such as PLAIN) which use
         plaintext passwords are NOT advertised in the CAPABILITY list.
      AND
         (b) The LOGIN command returns an error even if the password is
         correct.
      AND
         (c) The AUTHENTICATE command returns an error with all [SASL]
         mechanisms which use plaintext passwords, even if the password
         is correct.

Date: Fri, 20 Sep 2002 12:12:33 -0700 (PDT)
From: [email-masked]
Subject: Re: Further IESG feedback on draft-crispin-imapv-17.txt
To: Mark Crispin <[email-masked]>
Cc: "Jeffrey I. Schiller" <[email-masked]>, Larry Osterman <[email-masked]>, [email-masked], IMAP Mailing Liste <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked]
Sender: [email-masked]

> On Fri, 20 Sep 2002 13:28:08 -0400, Jeffrey I. Schiller wrote:
> > I can live with Mark's proposed paragraph.

> I think that's the only way out of this problem.

> As far as I can tell, the most that a server can do to address Cyrus' concern
> is to add LOGINDISABLED (described in RFC 2595), and remove plaintext SASL
> mechanisms (specifically PLAIN and LOGIN), from the CAPABILITY list.  Beyond
> that, we can not do anything more.

> If this is to be done, then it's more than just changing that paragraph in the
> AUTHENTICATE command.

> Let me issue a new draft with all this in mind.

Sounds like the right way to move forward to me.

				Ned

Date: Fri, 20 Sep 2002 11:34:25 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: Further IESG feedback on draft-crispin-imapv-17.txt
To: "Jeffrey I. Schiller" <[email-masked]>
cc: Larry Osterman <[email-masked]>, [email-masked], IMAP Mailing Liste <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 20 Sep 2002 13:28:08 -0400, Jeffrey I. Schiller wrote:
> I can live with Mark's proposed paragraph.

I think that's the only way out of this problem.

As far as I can tell, the most that a server can do to address Cyrus' concern
is to add LOGINDISABLED (described in RFC 2595), and remove plaintext SASL
mechanisms (specifically PLAIN and LOGIN), from the CAPABILITY list.  Beyond
that, we can not do anything more.

If this is to be done, then it's more than just changing that paragraph in the
AUTHENTICATE command.

Let me issue a new draft with all this in mind.

Date: Fri, 20 Sep 2002 11:29:07 -0700 (PDT)
From: [email-masked]
Subject: Re: Further IESG feedback on draft-crispin-imapv-17.txt
To: "Jeffrey I. Schiller" <[email-masked]>
Cc: Larry Osterman <[email-masked]>, [email-masked], IMAP Mailing Liste <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked]
Sender: [email-masked]

> So what is the lesser of two evils.

> 1)It is possible, and in fact done universally, the implement an IETF
>    Standard that sends passwords in the clear, even though we say that we
>    want secure protocols in the IETF and it has been at least three years
>    since we declared that the IETF would not standardize things with
>    plain text passwords...

> 2)We render all existing implementations non-conformant.

> An alternative that we discussed on the call which I don't believe Ned
> described was to reword the paragraph so that it was a MUST NOT unless
> the implementation or its user knew that the underlying transport was
> providing security (aka running IMAP over an SSH tunnel).

That suggestion was incorporated into the alternate wording I proposed.

				Ned

Date: Fri, 20 Sep 2002 13:33:29 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Steve Hole <[email-masked]>
cc: [email-masked], IMAP Mailing List <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Further IESG feedback on draft-crispin-imapv-17.txt
Sender: [email-masked]

Hi Mark,

--On Friday, September 20, 2002 9:22 AM -0700 Mark Crispin 
<[email-masked]> wrote:

|> I don't think there is
|> any practical way of forcing an IMAP server to turn off LOGIN in any kind
|> of open environment (University for example).
|
| Interestingly, it's easier for universities to turn off LOGIN (we have!)
| than it is for enterprises.  It just means that many clients don't work
| with our servers.  Of course, *our* preferred client works just fine...

Turning off LOGIN on the server won't stop clients that expect it to be 
present from sending the LOGIN command when SSL is not being used, thus 
exposing the plain text password. The bottom line is you cannot stop 
clients from sending LOGIN and exposing plain text passwords. The current 
draft does state clients SHOULD NOT use LOGIN except as a last restort and 
that is something that needs to be encouraged.

Also, the current (and proposed) wordings for the AUTHENTICATE command only 
suggest that the server should (must) not allow plain text passwords 
without SSL. I think the burden for that check should also lie with the 
client to prevent clients being tricked into sending plain text passwords 
over an insecure link, and I would like to see the wording changed to 
include clients doing this check.

-- 
Cyrus Daboo

Date: Fri, 20 Sep 2002 13:28:08 -0400
From: "Jeffrey I. Schiller" <[email-masked]>
Organization: Massachusetts Institute of Technology
To: Mark Crispin <[email-masked]>
CC: Larry Osterman <[email-masked]>, [email-masked], IMAP Mailing Liste <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked]
Subject: Re: Further IESG feedback on draft-crispin-imapv-17.txt
Sender: [email-masked]

I can live with Mark's proposed paragraph.

			-Jeff

Mark Crispin wrote:
> I share Larry's concern.
> 
> We agree with the IESG that this requirement should be "mandatory to
> implement".  What makes it untenable for us is the implication that an
> implementation which does not enforce "mandatory to deploy" is non-compliant.
> 
> Server implementors are not in a position to enforce "mandatory to deploy",
> and there are legitimate reasons why a site may choose to deploy unprotected
> plaintext authentication.
> 
> Note the following text in RFC 2595:
>    [...]  The PLAIN SASL mechanism
>    MUST NOT be advertised or used unless a strong encryption layer (such
>    as the provided by TLS) is active or backwards compatibility dictates
>    otherwise.
> 
> IESG approved this as standards-track for a new protocol (the PLAIN SASL
> mechanism) which did not have any standards-track legacy to consider.  IMAP,
> on the other hand, has a standards-track legacy and furthermore a production
> installed base dating from 1985.
> 
> This is, to put it mildly, inconsistent.
> 
> Is the following compromise be acceptable to the IESG?
> 
> Note: a server implementation MUST implement a configuration in which
>       it does NOT permit any plaintext password mechanisms unless the
>       STARTTLS command described in [IMAP-TLS] has been negotiated or
>       some other mechanism that protects the session from password
>       snooping has been provided.  Server sites SHOULD NOT use any
>       configuration which permits a plaintext password mechanism without
>       a protection mechanism against password snooping.  Client and
>       server implementations SHOULD implement additional SASL mechanisms
>       which do not use plaintext passwords, such the GSSAPI mechanism
>       described in [SASL] and/or the [DIGEST-MD5] mechanism.
> 
> This clearly puts the vendor off the hook if it has implemented the correct
> mode, even if the site chooses to use the incorrect mode.
> 

Date: Fri, 20 Sep 2002 13:22:25 -0400
From: "Jeffrey I. Schiller" <[email-masked]>
Organization: Massachusetts Institute of Technology
To: Larry Osterman <[email-masked]>
CC: [email-masked], IMAP Mailing Liste <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked]
Subject: Re: Further IESG feedback on draft-crispin-imapv-17.txt
Sender: [email-masked]

So what is the lesser of two evils.

1)It is possible, and in fact done universally, the implement an IETF
   Standard that sends passwords in the clear, even though we say that we
   want secure protocols in the IETF and it has been at least three years
   since we declared that the IETF would not standardize things with
   plain text passwords...

2)We render all existing implementations non-conformant.

An alternative that we discussed on the call which I don't believe Ned 
described was to reword the paragraph so that it was a MUST NOT unless 
the implementation or its user knew that the underlying transport was 
providing security (aka running IMAP over an SSH tunnel).

			-Jeff

Larry Osterman wrote:
> If you make this change, you instantly render the vast majority of the
> installed base of IMAP servers non compliant (read: ALL).
> 
> And I think that would be a bad thing.
> 
> The reason for the SHOULD NOT was that it allowed existing
> implementations enough weasel room to say they were compliant as long as
> they allowed a configuration option to disallow plaintext
> authentication, but the implementation could leave the plaintext
> mechanism in the server (either enabled or disabled by default, at the
> vendors desire).
> 
> If you make it a MUST NOT, then this implies that the plaintext
> mechanism must be REMOVED except under the cover of an alternative
> encryption mechanism.  And that breaks interoperability with the
> majority of servers and clients that exist in the wild, which is a less
> than optimal solution.
> 
> 
> 
> Larry Osterman 
> 
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, September 19, 2002 10:34 AM
> To: IMAP Mailing Liste; IMAP Extensions WG
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Further IESG feedback on draft-crispin-imapv-17.txt
> 
> 
> 
> The IESG had this on the agenda today. The various document nits seem to
> have been satisfactorily addressed. The IESG is also happy with the
> general way the big item in the previous feedback -- mandatory to
> implement security -- has been dealt with.
> 
> One concern remains, however. The following note appears in 6.2.1:
> 
> Note: a server implementation SHOULD NOT permit any
>       plaintext password mechanisms unless the STARTTLS
>       command described in [IMAP-TLS] has been negotiated.
>       Client and server implementations SHOULD implement
>       additional SASL mechanisms which do not use plaintext
>       passwords, such the GSSAPI mechanism described in [SASL]
>       and/or the [DIGEST-MD5] mechanism.
> 
> The IESG would like to push back even harder on the use of plain text
> passwords, and would like to see this changed to read:
> 
> Note: a server implementation MUST NOT permit any
>       plaintext password mechanisms unless the STARTTLS
>       command described in [IMAP-TLS] has been negotiated or some 
>       other mechanism that protects the session from password
>       snooping has been provided. Client and server implementations
>       SHOULD implement additional SASL mechanisms which do not use
>       plaintext passwords, such the GSSAPI mechanism described in
>       [SASL] and/or the [DIGEST-MD5] mechanism.
> 
> The reason the IESG would like to see this change made  should be
> obvious, but in case it is not: The IESG wants to mandate the use of
> mechanisms that insure password snooping isn't possible but recognizes
> that there are many ways to do this besides TLS: SSH, VPNs, physical
> network security, etc.
> 
> How do people feel about making this change?
> 
> 				Ned
> 

Date: Fri, 20 Sep 2002 09:22:18 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: Further IESG feedback on draft-crispin-imapv-17.txt
To: Steve Hole <[email-masked]>
cc: [email-masked], IMAP Mailing List <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Fri, 20 Sep 2002 08:58:29 -0700, Steve Hole wrote:
> I don't think there is
> any practical way of forcing an IMAP server to turn off LOGIN in any kind
> of open environment (University for example).

Interestingly, it's easier for universities to turn off LOGIN (we have!) than
it is for enterprises.  It just means that many clients don't work with our
servers.  Of course, *our* preferred client works just fine...

We do allow LOGIN if SSL or TLS is in effect.  Allowing LOGIN in SSL is
important, since otherwise you break Outlook and Netscape (neither of which
can do Kerberos or TLS).

From: Steve Hole <[email-masked]>
Date: Fri, 20 Sep 2002 08:58:29 -0700
To: [email-masked]
Subject: Re: Further IESG feedback on draft-crispin-imapv-17.txt
Cc: IMAP Mailing Liste <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Thu, 19 Sep 2002 10:34:10 -0700 (PDT) [email-masked] wrote:

> The IESG would like to push back even harder on the use of plain text
> passwords, and would like to see this changed to read:
> 
> Note: a server implementation MUST NOT permit any
>       plaintext password mechanisms unless the STARTTLS
>       command described in [IMAP-TLS] has been negotiated or some 
>       other mechanism that protects the session from password
>       snooping has been provided. Client and server implementations
>       SHOULD implement additional SASL mechanisms which do not use
>       plaintext passwords, such the GSSAPI mechanism described in
>       [SASL] and/or the [DIGEST-MD5] mechanism.
> 
> The reason the IESG would like to see this change made  should be obvious, but
> in case it is not: The IESG wants to mandate the use of mechanisms that insure
> password snooping isn't possible but recognizes that there are many ways to do
> this besides TLS: SSH, VPNs, physical network security, etc.
> 
> How do people feel about making this change?

Well, I think that it is a good idea in theory, but simply not practical 
at this point in time.   By making this change you will force all 
existing implementations into instant non-compliance, which means that 
they will simply continue to reference rfc2060 rather than the new RFC.

It's a difficult thing isn't it.   The problem is the weight of the 
formerly mandatory to implement LOGIN command and the pervasive use of 
LOGIN in all products.  As is usually the case, the servers aren't the 
problem here, it is the deployed base of clients.   I don't think there is
any practical way of forcing an IMAP server to turn off LOGIN in any kind 
of open environment (University for example).  The best servers will be 
able to do is to provide an "enforce no clear passwords" configuration 
switch that they can enable in the presence of a known set of compliant 
clients (closed enterprise).   The SHOULD wording supports that kind of 
evolutionary deployment model.

I would stay with the SHOULD wording for now.

Cheers.
---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Thu, 19 Sep 2002 17:08:58 -0700
From: Chris Newman <[email-masked]>
Subject: Re: Further IESG feedback on draft-crispin-imapv-17.txt
To: [email-masked], IMAP Mailing Liste <[email-masked]>, IMAP Extensions WG <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

I am absolutely opposed to the change the IESG has proposed because it will 
result in inadequate real-world security for the IMAP protocol.

RFC 2060 currently requires no security for IMAP.  So the unencrypted 
plaintext password mechanism is the only one that all IMAP products 
implement.  Customers purchasing IMAP software require interoperability and 
thus require support for unencrypted plaintext passwords.  The only upside 
is that SSL/TLS has deployed quite well.

The "SHOULD NOT" language greatly improves the situation because many 
vendors will comply with the spec and advertise that fact, and thus it will 
create market pressure for IMAP vendors to implement STARTTLS.

The "MUST NOT" language is not nearly as effective.  Because vendors can 
not comply with the new spec and meet customer requirements, they will 
ignore the spec and simply claim compliance with RFC 2060.  As a result, 
there will be no new market pressure to improve the status quo.

Therefore, the current "SHOULD NOT" language will provide better real-world 
security than the proposed "MUST NOT" language.

Mark's proposed compromise language is also acceptable and better than the 
current language.

                - Chris

begin  quotation by [email-masked] on 2002/9/19 10:34 -0700:

>
> The IESG had this on the agenda today. The various document nits seem to
> have been satisfactorily addressed. The IESG is also happy with the
> general way the big item in the previous feedback -- mandatory to
> implement security -- has been dealt with.
>
> One concern remains, however. The following note appears in 6.2.1:
>
> Note: a server implementation SHOULD NOT permit any
>       plaintext password mechanisms unless the STARTTLS
>       command described in [IMAP-TLS] has been negotiated.
>       Client and server implementations SHOULD implement
>       additional SASL mechanisms which do not use plaintext
>       passwords, such the GSSAPI mechanism described in [SASL]
>       and/or the [DIGEST-MD5] mechanism.
>
> The IESG would like to push back even harder on the use of plain text
> passwords, and would like to see this changed to read:
>
> Note: a server implementation MUST NOT permit any
>       plaintext password mechanisms unless the STARTTLS
>       command described in [IMAP-TLS] has been negotiated or some
>       other mechanism that protects the session from password
>       snooping has been provided. Client and server implementations
>       SHOULD implement additional SASL mechanisms which do not use
>       plaintext passwords, such the GSSAPI mechanism described in
>       [SASL] and/or the [DIGEST-MD5] mechanism.
>
> The reason the IESG would like to see this change made  should be
> obvious, but in case it is not: The IESG wants to mandate the use of
> mechanisms that insure password snooping isn't possible but recognizes
> that there are many ways to do this besides TLS: SSH, VPNs, physical
> network security, etc.
>
> How do people feel about making this change?
>
> 				Ned
>

Date: Thu, 19 Sep 2002 11:43:11 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: RE: Further IESG feedback on draft-crispin-imapv-17.txt
To: Larry Osterman <[email-masked]>
cc: [email-masked], IMAP Mailing Liste <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

I share Larry's concern.

We agree with the IESG that this requirement should be "mandatory to
implement".  What makes it untenable for us is the implication that an
implementation which does not enforce "mandatory to deploy" is non-compliant.

Server implementors are not in a position to enforce "mandatory to deploy",
and there are legitimate reasons why a site may choose to deploy unprotected
plaintext authentication.

Note the following text in RFC 2595:
   [...]  The PLAIN SASL mechanism
   MUST NOT be advertised or used unless a strong encryption layer (such
   as the provided by TLS) is active or backwards compatibility dictates
   otherwise.

IESG approved this as standards-track for a new protocol (the PLAIN SASL
mechanism) which did not have any standards-track legacy to consider.  IMAP,
on the other hand, has a standards-track legacy and furthermore a production
installed base dating from 1985.

This is, to put it mildly, inconsistent.

Is the following compromise be acceptable to the IESG?

Note: a server implementation MUST implement a configuration in which
      it does NOT permit any plaintext password mechanisms unless the
      STARTTLS command described in [IMAP-TLS] has been negotiated or
      some other mechanism that protects the session from password
      snooping has been provided.  Server sites SHOULD NOT use any
      configuration which permits a plaintext password mechanism without
      a protection mechanism against password snooping.  Client and
      server implementations SHOULD implement additional SASL mechanisms
      which do not use plaintext passwords, such the GSSAPI mechanism
      described in [SASL] and/or the [DIGEST-MD5] mechanism.

This clearly puts the vendor off the hook if it has implemented the correct
mode, even if the site chooses to use the incorrect mode.

Content-Class: urn:content-classes:message
Subject: RE: Further IESG feedback on draft-crispin-imapv-17.txt
Date: Thu, 19 Sep 2002 11:12:45 -0700
From: "Larry Osterman" <[email-masked]>
To: <[email-masked]>, "IMAP Mailing Liste" <[email-masked]>, "IMAP Extensions WG" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

If you make this change, you instantly render the vast majority of the
installed base of IMAP servers non compliant (read: ALL).

And I think that would be a bad thing.

The reason for the SHOULD NOT was that it allowed existing
implementations enough weasel room to say they were compliant as long as
they allowed a configuration option to disallow plaintext
authentication, but the implementation could leave the plaintext
mechanism in the server (either enabled or disabled by default, at the
vendors desire).

If you make it a MUST NOT, then this implies that the plaintext
mechanism must be REMOVED except under the cover of an alternative
encryption mechanism.  And that breaks interoperability with the
majority of servers and clients that exist in the wild, which is a less
than optimal solution.

Larry Osterman 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, September 19, 2002 10:34 AM
To: IMAP Mailing Liste; IMAP Extensions WG
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Further IESG feedback on draft-crispin-imapv-17.txt

The IESG had this on the agenda today. The various document nits seem to
have been satisfactorily addressed. The IESG is also happy with the
general way the big item in the previous feedback -- mandatory to
implement security -- has been dealt with.

One concern remains, however. The following note appears in 6.2.1:

Note: a server implementation SHOULD NOT permit any
      plaintext password mechanisms unless the STARTTLS
      command described in [IMAP-TLS] has been negotiated.
      Client and server implementations SHOULD implement
      additional SASL mechanisms which do not use plaintext
      passwords, such the GSSAPI mechanism described in [SASL]
      and/or the [DIGEST-MD5] mechanism.

The IESG would like to push back even harder on the use of plain text
passwords, and would like to see this changed to read:

Note: a server implementation MUST NOT permit any
      plaintext password mechanisms unless the STARTTLS
      command described in [IMAP-TLS] has been negotiated or some 
      other mechanism that protects the session from password
      snooping has been provided. Client and server implementations
      SHOULD implement additional SASL mechanisms which do not use
      plaintext passwords, such the GSSAPI mechanism described in
      [SASL] and/or the [DIGEST-MD5] mechanism.

The reason the IESG would like to see this change made  should be
obvious, but in case it is not: The IESG wants to mandate the use of
mechanisms that insure password snooping isn't possible but recognizes
that there are many ways to do this besides TLS: SSH, VPNs, physical
network security, etc.

How do people feel about making this change?

				Ned

Date: Thu, 19 Sep 2002 10:34:10 -0700 (PDT)
From: [email-masked]
Subject: Further IESG feedback on draft-crispin-imapv-17.txt
To: IMAP Mailing Liste <[email-masked]>, IMAP Extensions WG <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

The IESG had this on the agenda today. The various document nits seem to have
been satisfactorily addressed. The IESG is also happy with the general way the
big item in the previous feedback -- mandatory to implement security -- has
been dealt with.

One concern remains, however. The following note appears in 6.2.1:

Note: a server implementation SHOULD NOT permit any
      plaintext password mechanisms unless the STARTTLS
      command described in [IMAP-TLS] has been negotiated.
      Client and server implementations SHOULD implement
      additional SASL mechanisms which do not use plaintext
      passwords, such the GSSAPI mechanism described in [SASL]
      and/or the [DIGEST-MD5] mechanism.

The IESG would like to push back even harder on the use of plain text
passwords, and would like to see this changed to read:

Note: a server implementation MUST NOT permit any
      plaintext password mechanisms unless the STARTTLS
      command described in [IMAP-TLS] has been negotiated or some 
      other mechanism that protects the session from password
      snooping has been provided. Client and server implementations
      SHOULD implement additional SASL mechanisms which do not use
      plaintext passwords, such the GSSAPI mechanism described in
      [SASL] and/or the [DIGEST-MD5] mechanism.

The reason the IESG would like to see this change made  should be obvious, but
in case it is not: The IESG wants to mandate the use of mechanisms that insure
password snooping isn't possible but recognizes that there are many ways to do
this besides TLS: SSH, VPNs, physical network security, etc.

How do people feel about making this change?

				Ned

Date: Tue, 10 Sep 2002 15:17:10 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: IMAP Extensions WG <[email-masked]>
Subject: IMAPEXT meeting in Atlanta?
Sender: [email-masked]

What people think about having a meeting in Atlanta?
Topics to discuss:
 ACL2 (I will do a revision before the meeting)
 Message and mailbox annotations
 LISTEXT (Barry, where is a new revision? ;-))

If people have interest (I know, this is outside of the Charter):
 VPIM related IMAP stuff;
 QUOTA2 (my new draft with Dave Cridland);
 "Disconnected mail clients" document.

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

Date: Wed, 04 Sep 2002 22:25:37 -0400
From: Tony Hansen <[email-masked]>
To: Chris Newman <[email-masked]>
CC: vpim <[email-masked]>, imapext <[email-masked]>
Subject: Re: non-standard ProxyAuth extension?
Sender: [email-masked]

Don't worry -- I never wanted to implement it. But I've been putting 
together a list of arguments to use to convince others to not bother 
implementing it.

	Tony

Chris Newman wrote:
> 
> I concur 100% with Mark's opinion.  Use RFC 2595's PLAIN mechanism 
> instead, which is more widely implemented.
> 
>                - Chris
> 
> begin  quotation by Mark Crispin on 2002/9/4 11:05 -0700:
> 
>> The inferences that can be drawn from my comment may be the closest to an
>> answer that there is.  ProxyAuth was suggested by Netscape 5 years ago.
>> It was soundly denounced at the time as a flawed (security issues,
>> filesystem dependencies) and unnecessary (SASL provides a superior
>> mechanism that is multiprotocol as well) idea.  As far as I can tell, the
>> document never went beyond draft 00.
>>
>> It can be inferred that only Netscape ever implemented it (assuming that
>> they did, and that it is still in the Netscape server).  Since there is
>> no reason to implement it, it can be inferred that there will be no new
>> implementations.
>>
>> That, in turn, leads to the inference that it is not "common"; or at
>> least no more "common" than the Netscape server.
>>
>> I've been contacted by VPIM folks from time to time about deploying my
>> server with VPIM clients.  Given that the UW server does not implement
>> ProxyAuth, I infer that the VPIM community does not depend upon it.  This
>> inference is strengthed by the fact that ProxyAuth is *not* one of the
>> things which the VPIM community has asked the IMAP community to work on.
>>
>> Given the architectural flaws (including security design flaws) in
>> ProxyAuth, this all should be quite enough to declare ProxyAuth to be
>> dead, and not to be used or implemented.
>>
>> On Wed, 04 Sep 2002 13:27:03 -0400, Tony Hansen wrote:
>>
>>> Mark, I don't disagree. However, I still need my questions answered.
>>> Mark Crispin wrote:
>>> > I don't see any reason to implement ProxyAuth now that we have a
>>> > superior mechanism in SASL.
>>
>>
> 
> 

Date: Wed, 04 Sep 2002 13:04:02 -0700
From: Chris Newman <[email-masked]>
Subject: Re: non-standard ProxyAuth extension?
To: Tony Hansen <[email-masked]>
Cc: vpim <[email-masked]>, imapext <[email-masked]>
Sender: [email-masked]

I concur 100% with Mark's opinion.  Use RFC 2595's PLAIN mechanism instead, 
which is more widely implemented.

                - Chris

begin  quotation by Mark Crispin on 2002/9/4 11:05 -0700:
> The inferences that can be drawn from my comment may be the closest to an
> answer that there is.  ProxyAuth was suggested by Netscape 5 years ago.
> It was soundly denounced at the time as a flawed (security issues,
> filesystem dependencies) and unnecessary (SASL provides a superior
> mechanism that is multiprotocol as well) idea.  As far as I can tell, the
> document never went beyond draft 00.
>
> It can be inferred that only Netscape ever implemented it (assuming that
> they did, and that it is still in the Netscape server).  Since there is
> no reason to implement it, it can be inferred that there will be no new
> implementations.
>
> That, in turn, leads to the inference that it is not "common"; or at
> least no more "common" than the Netscape server.
>
> I've been contacted by VPIM folks from time to time about deploying my
> server with VPIM clients.  Given that the UW server does not implement
> ProxyAuth, I infer that the VPIM community does not depend upon it.  This
> inference is strengthed by the fact that ProxyAuth is *not* one of the
> things which the VPIM community has asked the IMAP community to work on.
>
> Given the architectural flaws (including security design flaws) in
> ProxyAuth, this all should be quite enough to declare ProxyAuth to be
> dead, and not to be used or implemented.
>
> On Wed, 04 Sep 2002 13:27:03 -0400, Tony Hansen wrote:
>> Mark, I don't disagree. However, I still need my questions answered.
>> Mark Crispin wrote:
>> > I don't see any reason to implement ProxyAuth now that we have a
>> > superior mechanism in SASL.
>

Date: Wed, 04 Sep 2002 15:33:59 -0400
From: Tony Hansen <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: vpim <[email-masked]>, imapext <[email-masked]>
Subject: Re: non-standard ProxyAuth extension?
Sender: [email-masked]

Thanks Mark!

	Tony

Mark Crispin wrote:
> The inferences that can be drawn from my comment may be the closest to an
> answer that there is.  ProxyAuth was suggested by Netscape 5 years ago.  It
> was soundly denounced at the time as a flawed (security issues, filesystem
> dependencies) and unnecessary (SASL provides a superior mechanism that is
> multiprotocol as well) idea.  As far as I can tell, the document never went
> beyond draft 00.
> 
> It can be inferred that only Netscape ever implemented it (assuming that they
> did, and that it is still in the Netscape server).  Since there is no reason
> to implement it, it can be inferred that there will be no new implementations.
> 
> That, in turn, leads to the inference that it is not "common"; or at least no
> more "common" than the Netscape server.
> 
> I've been contacted by VPIM folks from time to time about deploying my server
> with VPIM clients.  Given that the UW server does not implement ProxyAuth, I
> infer that the VPIM community does not depend upon it.  This inference is
> strengthed by the fact that ProxyAuth is *not* one of the things which the
> VPIM community has asked the IMAP community to work on.
> 
> Given the architectural flaws (including security design flaws) in ProxyAuth,
> this all should be quite enough to declare ProxyAuth to be dead, and not to be
> used or implemented.
> 
> On Wed, 04 Sep 2002 13:27:03 -0400, Tony Hansen wrote:
> 
>>Mark, I don't disagree. However, I still need my questions answered.
>>Mark Crispin wrote:
>>
>>>I don't see any reason to implement ProxyAuth now that we have a superior
>>>mechanism in SASL.
>>
> 

Date: Wed, 4 Sep 2002 11:05:58 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: non-standard ProxyAuth extension?
To: Tony Hansen <[email-masked]>
cc: vpim <[email-masked]>, imapext <[email-masked]>
Sender: [email-masked]

The inferences that can be drawn from my comment may be the closest to an
answer that there is.  ProxyAuth was suggested by Netscape 5 years ago.  It
was soundly denounced at the time as a flawed (security issues, filesystem
dependencies) and unnecessary (SASL provides a superior mechanism that is
multiprotocol as well) idea.  As far as I can tell, the document never went
beyond draft 00.

It can be inferred that only Netscape ever implemented it (assuming that they
did, and that it is still in the Netscape server).  Since there is no reason
to implement it, it can be inferred that there will be no new implementations.

That, in turn, leads to the inference that it is not "common"; or at least no
more "common" than the Netscape server.

I've been contacted by VPIM folks from time to time about deploying my server
with VPIM clients.  Given that the UW server does not implement ProxyAuth, I
infer that the VPIM community does not depend upon it.  This inference is
strengthed by the fact that ProxyAuth is *not* one of the things which the
VPIM community has asked the IMAP community to work on.

Given the architectural flaws (including security design flaws) in ProxyAuth,
this all should be quite enough to declare ProxyAuth to be dead, and not to be
used or implemented.

On Wed, 04 Sep 2002 13:27:03 -0400, Tony Hansen wrote:
> Mark, I don't disagree. However, I still need my questions answered.
> Mark Crispin wrote:
> > I don't see any reason to implement ProxyAuth now that we have a superior
> > mechanism in SASL.

Date: Wed, 04 Sep 2002 13:27:03 -0400
From: Tony Hansen <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: [email-masked], vpim <[email-masked]>, imapext <[email-masked]>
Subject: Re: non-standard ProxyAuth extension?
Sender: [email-masked]

Mark, I don't disagree. However, I still need my questions answered.

	Tony

Mark Crispin wrote:
> I don't see any reason to implement ProxyAuth now that we have a superior
> mechanism in SASL.
> 

Date: Wed, 4 Sep 2002 09:58:55 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: non-standard ProxyAuth extension?
To: Tony Hansen <[email-masked]>
cc: [email-masked], vpim <[email-masked]>, imapext <[email-masked]>
Sender: [email-masked]

I don't see any reason to implement ProxyAuth now that we have a superior
mechanism in SASL.

Date: Wed, 04 Sep 2002 12:54:41 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked], vpim <[email-masked]>, imapext <[email-masked]>
Subject: non-standard ProxyAuth extension?
Sender: [email-masked]

I just ran across a reference to a non-standard extension to imap called 
ProxyAuth. It is supposedly commonly provided by imap servers used for 
voice messaging. The spec I got was that you would first do a Login 
using an administrative ID:

	Login admin-id admin-password

You'd then use the ProxyAuth command to switch to a given user:

	ProxyAuth username

Logically, it's comparable to the SASL concept of having a separate 
authenticator id (the admin-id) from the authorization id (the username).

Is this really a common extension? Is there a writeup anywhere for it?

	Tony Hansen
	[email-masked]