[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cyrus-devel
Subject:    Re: [Cyrus-CVS] src/cyrus/imap by ken3
From:       Ken Murchison <ken () oceana ! com>
Date:       2003-06-24 18:00:36
[Download RAW message or body]

But, do we know that clients actually care?  Crispin has already stated 
that he suppresses the STARTTLS capability after a successful STARTTLS 
and nobody has complained.

I just posted a reply to his post asking about AUTHENTICATE.


Rob Siemborski wrote:
> On Tue, 24 Jun 2003, Lawrence Greenfield wrote:
> 
> 
>>   Are we talking about continuing to advertise AUTH or both AUTH and TLS?
>>     Crispin had a post on the imap list about not advertising TLS after it
>>   has been used, which is what got me off on this tangent.
>>
>>Defintely AUTH. I don't see any reason to advertise STARTTLS again,
>>but I don't see any reason not to, either.
> 
> 
> I suppose you can interpret this part of RFC2222bis to read that way:
> 
>    Any protocol interactions prior to authentication are performed in
>    the clear and may be modified by an active attacker.  In the case
>    where a client selects integrity protection, it is important that any
>    security-sensitive protocol negotiations be performed after
>    authentication is complete.  Protocols should be designed such that
>    negotiations performed prior to authentication should be either
>    ignored or revalidated once authentication is complete.
> 
> Though, really, any client that chooses to authenticate given a
> potentially-munged list of SASL mechanisms, really shouldn't be upset if a
> potentially stronger mechanism is suddenly available on the server.  It
> shouldn't have authenticated if it didn't think the mechanism it chose was
> secure enough.
> 
> Since IMAP really doesn't support multiple (successful) STARTTLS commands
> or multiple (successful) AUTHENTICATE commands, or a STARTTLS following an
> AUTHENTICATE command, really the server doesn't have these capabilities
> anymore, and they shouldn't be advertised.
> 
> That said, I don't think this is important enough to proactively try to
> break clients that care.
> 
> -Rob
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Rob Siemborski | Andrew Systems Group * Research Systems Programmer
> PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456
> -----BEGIN GEEK CODE BLOCK----
> Version: 3.12
> GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
> w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
> ------END GEEK CODE BLOCK-----
> 
> 


-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp



[prev in list] [next in list] [prev in thread] [next in thread]