re: IESG review of draft-crispin-imapv-16.txt

> On Wed, 29 May 2002 [EMAIL PROTECTED] wrote: > > You're missing one from the list: SSL and LOGIN (or PLAIN). This likely would > > be acceptable. I believe the IESG could be convinced this is the way to go. > > Perhaps this would be more acceptable as a mandatory to implement: It certainly > > a

re: IESG review of draft-crispin-imapv-16.txt

On Wed, 29 May 2002, Mark Crispin wrote: > OK, this is helpful and may be the breakthrough that was needed. > > How about the following: > [big snip...] > > This matches current reality. I don't see SRP discussed anywhere. I feel more comfortable with it than CRAM-MD5 because of the issue of sto

Re: IESG review of draft-crispin-imapv-16.txt

On Wed, 29 May 2002, Lawrence Greenfield wrote: > Our local site policy doesn't offer DIGEST-MD5---but > that isn't what we're talking about. The point seems to be interoperability between compliant implementations. A client which only implements DIGEST-MD5 is not able to talk to your server. I

Re: IESG review of draft-crispin-imapv-16.txt

Date: Wed, 29 May 2002 20:13:24 -0700 (Pacific Daylight Time) From: Mark Crispin <[EMAIL PROTECTED]> On Wed, 29 May 2002, Lawrence Greenfield wrote: > Servers: Cyrus. iPlanet and/or Netscape has demonstrated it---I don't > know if the latest shipping version has it. The serv

Re: IESG review of draft-crispin-imapv-16.txt

On Wed, 29 May 2002, Lawrence Greenfield wrote: > Servers: Cyrus. iPlanet and/or Netscape has demonstrated it---I don't > know if the latest shipping version has it. The server at imap.andrew.cmu.edu only offers KERBEROS_V4 and GSSAPI. -- Mark -- http://staff.washington.edu/mrc Science does

Re: IESG review of draft-crispin-imapv-16.txt

Date: Wed, 29 May 2002 19:43:38 -0700 (Pacific Daylight Time) From: Mark Crispin <[EMAIL PROTECTED]> [...] > (2) Require implementation of DIGEST-MD5. > This is not as widely deployed AFAIK it is completely undeployed in the IMAP world. I took a look at DIGEST-MD5 and was horri

re: IESG review of draft-crispin-imapv-16.txt

On Wed, 29 May 2002, Chris Newman wrote: > I believe there are two viable choices for mandatory to implement: > > (1) Require implementation of STARTTLS (making the most common RSA+RC4 > cipher suite mandatory would be most realistic) and use it with the LOGIN > command (or PLAIN SASL if you wish)

re: IESG review of draft-crispin-imapv-16.txt

begin quotation by Mark Crispin on 2002/5/29 13:19 -0700: > On Wed, 29 May 2002 12:35:17 -0700 (PDT), [EMAIL PROTECTED] wrote: >> A specific protocol is another matter. The IESG's belief is that specific >> protocols need to have one or more mandatory to implement SASL >> mechanisms. Mandatory to

re: IESG review of draft-crispin-imapv-16.txt

On Wed, 29 May 2002 [EMAIL PROTECTED] wrote: > You're missing one from the list: SSL and LOGIN (or PLAIN). This likely would > be acceptable. I believe the IESG could be convinced this is the way to go. > Perhaps this would be more acceptable as a mandatory to implement: It certainly > avoids all

re: IESG review of draft-crispin-imapv-16.txt

> On Wed, 29 May 2002 12:35:17 -0700 (PDT), [EMAIL PROTECTED] wrote: > > A specific protocol is another matter. The IESG's belief is that specific > > protocols need to have one or more mandatory to implement SASL mechanisms. > > Mandatory to implement doesn't mean mandatory to use. Just because y

re: IESG review of draft-crispin-imapv-16.txt

> On Wed, 29 May 2002 00:34:21 -0700 (PDT), [EMAIL PROTECTED] wrote: > > The IESG has reviewed draft-crispin-imapv-16.txt and has found a number > > of issues that need to be addressed before the document can be approved > > as a proposed standard: > > (1) The AUTHENTICATE command -- which is re

re: imap buffer overflow issue - is this solved?

On Wed, 29 May 2002 14:25:21 -0700, Auteria Wally Winzer Jr. wrote: > I received a security notice regarding UW-imap buffer overflow. Is this > fixed with the latest version 2001a? The only recent one that I am aware about was fixed over a year ago (hence is fixed in 2001a). That problem is of

re: IESG review of draft-crispin-imapv-16.txt

| > The rationale here as I understand it is that this makes it easier during | > standards advancement to figure out what the real dependencies are. But | > regardless of whether or not you believe this is useful or strance or | > whatever, having such a split is a recent requirement imposed by t

imap buffer overflow issue - is this solved?

I received a security notice regarding UW-imap buffer overflow.  Is this fixed with the latest version 2001a?   Wally Winzer Jr.

re: IESG review of draft-crispin-imapv-16.txt

On Wed, 29 May 2002 12:35:17 -0700 (PDT), [EMAIL PROTECTED] wrote: > A specific protocol is another matter. The IESG's belief is that specific > protocols need to have one or more mandatory to implement SASL mechanisms. > Mandatory to implement doesn't mean mandatory to use. Just because you have

Re: IESG review of draft-crispin-imapv-16.txt

| In any case, such discussions belong in a document describing security | techniques and tradeoffs. It does not belong in the IMAP document or any | other document describing an orthogonal protocol. You have my vote here (-: ` Bill ` / Bill Yeager Chief Technology Officer Project JXTA [EMA

RE: IESG review of draft-crispin-imapv-16.txt

How do I get myself off of this list? -- Jessica L. Blank, Systems Administrator & Programmer www.starchefs.com 9 East 19th St., 9th Floor / New York, NY 10003 [EMAIL PROTECTED] - (212) 477-9399 x116 Help Wanted. Help Found. www.helpwante

Re: IESG review of draft-crispin-imapv-16.txt

On Wed, 29 May 2002 10:12:30 -0700 (PDT), [EMAIL PROTECTED] wrote: > Probably not, and an acceptable answer to this point may be to toss this > over to the upcomding revision of the SASL specification. (Note that I said > "might be".) My answer is to toss this over to another document, to be dete

re: IESG review of draft-crispin-imapv-16.txt

On Wed, 29 May 2002 00:34:21 -0700 (PDT), [EMAIL PROTECTED] wrote: > The IESG has reviewed draft-crispin-imapv-16.txt and has found a number > of issues that need to be addressed before the document can be approved > as a proposed standard: > > (1) The AUTHENTICATE command -- which is recommended

UNSUBSCRIBE IMAP

UNSUBSCRIBE IMAP -- Jessica L. Blank, Systems Administrator & Programmer   www.starchefs.com 9 East 19th St., 9th Floor  /  New York, NY 10003 [EMAIL PROTECTED] - (212) 477-9399 x116   Help Wanted. Help Found. www.helpwantedhelpfound.com, a division of StarChefs  

Re: IESG review of draft-crispin-imapv-16.txt

> [EMAIL PROTECTED] > > (6) For sections-- > > > > > 6.2.1. AUTHENTICATE Command > > > > and > > > > > 6.2.2. LOGIN Command > > > > some discussion of methods to limit the number of auth/login attempts > > allowed and/or other mechanisms to discourage name/password > > hacking (e.g. exponent

Re: IESG review of draft-crispin-imapv-16.txt

Arnt Gulbrandsen wrote: > [EMAIL PROTECTED] > > (6) For sections-- > > > > > 6.2.1. AUTHENTICATE Command > > > > and > > > > > 6.2.2. LOGIN Command > > > > some discussion of methods to limit the number of auth/login attempts > > allowed and/or other mechanisms to discourage name/password >

Re: IESG review of draft-crispin-imapv-16.txt

On Wed, 29 May 2002, Barry Leiba wrote: >> IMO, it does no harm to recommend mechanisms in the RFC for dropping the >> connection after N failed login attempts. >No, I'm with Arnt on this one, fully. It's beyond the scope of IMAP to >define login security, and any protocol that has authenticatio

Re: IESG review of draft-crispin-imapv-16.txt

> IMO, it does no harm to recommend mechanisms in the RFC for dropping the > connection after N failed login attempts. No, I'm with Arnt on this one, fully. It's beyond the scope of IMAP to define login security, and any protocol that has authentication (and there are many) has to deal with thi

Re: IESG review of draft-crispin-imapv-16.txt

On Wed, 29 May 2002, Arnt Gulbrandsen wrote: >[EMAIL PROTECTED] >> (6) For sections-- >> >> > 6.2.1. AUTHENTICATE Command >> >> and >> >> > 6.2.2. LOGIN Command >> >> some discussion of methods to limit the number of auth/login attempts >> allowed and/or other mechanisms to discourage nam

Re: IESG review of draft-crispin-imapv-16.txt

[EMAIL PROTECTED] > (6) For sections-- > > > 6.2.1. AUTHENTICATE Command > > and > > > 6.2.2. LOGIN Command > > some discussion of methods to limit the number of auth/login attempts > allowed and/or other mechanisms to discourage name/password > hacking (e.g. exponentially delay the serv

IESG review of draft-crispin-imapv-16.txt

The IESG has reviewed draft-crispin-imapv-16.txt and has found a number of issues that need to be addressed before the document can be approved as a proposed standard: (1) The AUTHENTICATE command -- which is recommended -- may fail in practice because no mandatory-to-implement SASL mechanism