Re: POP handling commands given in wrong state

This is a multi-part message in MIME format.
--------------040709010300010303090803
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

26.07.2011 12:51, Paul Smith wrote:
> On 26/07/2011 10:22, Mykyta Yevstifeyev wrote:
>> 26.07.2011 11:12, Paul Smith wrote:
>>> On 26/07/2011 05:59, Mykyta Yevstifeyev wrote:
>>>
>>> [ . .  .]
>>>
>>> If the state was server defined, so that it may change on the 
>>> server's decision, rather than by purely bad coding in the client, 
>>> then yes, an extended response code may be useful, but when it is 
>>> only bad coding in the client which can make it happen - no.
>> Paul,
>>
>> [Adding Alexey Melnikov to CC list; see below.]
>>
>> I meant just the situation like this.  Eg., when one is using 
>> POP3-over-TLS whereas TLS connection is established before POP 
>> transaction starts, TLS negotiation may be used instead USER-PASS or 
>> AUTH authentication, entering the server into the TRANSACTION state; 
>> on the other hand, the server may require authentication under TLS 
>> layer, entering AUTHORIZATION state after establishing TLS 
>> connection.  I and Alexey Melnikov are currently working on the 
>> POP-over-TLS specification 
>> (https://datatracker.ietf.org/doc/draft-melnikov-pop3-over-tls/) and 
>> the problem is that the client don't know what state is the server in 
>> after TLS negotiation.  If the client tries giving USER and received 
>> -ERR, it may mean that the user name is unknown or that the user is 
>> authenticated already, and the client can't know for sure what does 
>> it mean.  Don't you have other idea of indicating the state?
>
> Hmm. I'd say that was a problem with the POP3 over TLS idea
>
> It seems wrong to have to try to do something, and see if you get an 
> error to see what you should do next. I know ESMTP does it, and the 
> POP3 'CAPA' do it, but that's because those things were added as a 
> hindsight after the base spec had been deployed. For a new standard to 
> need it just feels wrong.
>
> Personally, I'd expect authentication to always be required, even if 
> it's redundant. It just seems too much of a change from the base POP3 
> spec to skip the authorization stage.
>
> So, you could have the TLS session established which establishes the 
> user's identity, and then do
> USER anything
> +OK
> PASS anything
> +OK
>
> or you could use the USER/PASS as a part of two factor authentication 
> (the certificate is something you have, the username/password is 
> something you know)
>
> Going straight from session establishment into transaction state seems 
> wrong to me, given the base POP3 spec which POP3-over-TLS is building on.
The matter is that many POP servers support authentication using X.509 
certificate which was supplied during TLS negotiation and do not require 
further authentication.  In such case issuing USER will lead to -ERR, as 
the server is already in TRANSACTION then.  Other servers implement 
POP-over-TLS so that further authentication is also required (eg. Gmail, 
which I personally am using).
>
>
> BTW - why are you looking at POP3-over-TLS? Isn't this idea obsolete - 
> isn't the 'STLS' command (RFC 2595) the way we should be doing things 
> now? I thought the POP3S way was deprecated.
>
> Note that the RFC 2595 says:
> "The STLS command is only permitted in AUTHORIZATION state and the 
> server remains in AUTHORIZATION state, even if client credentials are 
> supplied during the TLS negotiation." so with STLS you have to 
> authenticate (not sure why it's called 'authorization' state when it's 
> really 'authentication' state, but that's not relevant) even if the 
> TLS has already supplied the user details.
Yes, RFC 2595 discouraged use of POP-over-TLS.  However, it is now used 
even wider than STLS, which led to effort to document this mode.  See 
above for note on why authorization might not be necessary after TLS 
negotiation.

Mykyta
>
>
>


--------------040709010300010303090803
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by hoffman.proper.com id p6QDICpi001539

<html>
  <head>
    <meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Ty=
pe">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    26.07.2011 12:51, Paul Smith wrote:
    <blockquote cite=3D"mid:[email protected]" type=3D"cite">
      <meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-=
Type">
      On 26/07/2011 10:22, Mykyta Yevstifeyev wrote:
      <blockquote cite=3D"mid:[email protected]" type=3D"cite">2=
6.07.2011

        11:12, Paul Smith wrote: <br>
        <blockquote type=3D"cite">On 26/07/2011 05:59, Mykyta Yevstifeyev
          wrote: <br>
          <br>
          [ . .=C2=A0 .] <br>
          <br>
          If the state was server defined, so that it may change on the
          server's decision, rather than by purely bad coding in the
          client, then yes, an extended response code may be useful, but
          when it is only bad coding in the client which can make it
          happen - no. <br>
        </blockquote>
        Paul, <br>
        <br>
        [Adding Alexey Melnikov to CC list; see below.] <br>
        <br>
        I meant just the situation like this.=C2=A0 Eg., when one is usin=
g
        POP3-over-TLS whereas TLS connection is established before POP
        transaction starts, TLS negotiation may be used instead
        USER-PASS or AUTH authentication, entering the server into the
        TRANSACTION state; on the other hand, the server may require
        authentication under TLS layer, entering AUTHORIZATION state
        after establishing TLS connection.=C2=A0 I and Alexey Melnikov ar=
e
        currently working on the POP-over-TLS specification (<a
          moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext"
          href=3D"https://datatracker.ietf.org/doc/draft-melnikov-pop3-ov=
er-tls/">https://datatracker.ietf.org/doc/draft-melnikov-pop3-over-tls/</=
a>)
        and the problem is that the client don't know what state is the
        server in after TLS negotiation.=C2=A0 If the client tries giving
        USER and received -ERR, it may mean that the user name is
        unknown or that the user is authenticated already, and the
        client can't know for sure what does it mean.=C2=A0 Don't you hav=
e
        other idea of indicating the state? <br>
      </blockquote>
      <br>
      Hmm. I'd say that was a problem with the POP3 over TLS idea<br>
      <br>
      It seems wrong to have to try to do something, and see if you get
      an error to see what you should do next. I know ESMTP does it, and
      the POP3 'CAPA' do it, but that's because those things were added
      as a hindsight after the base spec had been deployed. For a new
      standard to need it just feels wrong.<br>
      <br>
      Personally, I'd expect authentication to always be required, even
      if it's redundant. It just seems too much of a change from the
      base POP3 spec to skip the authorization stage. <br>
      <br>
      So, you could have the TLS session established which establishes
      the user's identity, and then do<br>
      USER anything<br>
      +OK<br>
      PASS anything<br>
      +OK<br>
      <br>
      or you could use the USER/PASS as a part of two factor
      authentication (the certificate is something you have, the
      username/password is something you know)<br>
      <br>
      Going straight from session establishment into transaction state
      seems wrong to me, given the base POP3 spec which POP3-over-TLS is
      building on.<br>
    </blockquote>
    The matter is that many POP servers support authentication using
    X.509 certificate which was supplied during TLS negotiation and do
    not require further authentication.=C2=A0 In such case issuing USER w=
ill
    lead to -ERR, as the server is already in TRANSACTION then.=C2=A0 Oth=
er
    servers implement POP-over-TLS so that further authentication is
    also required (eg. Gmail, which I personally am using).<br>
    <blockquote cite=3D"mid:[email protected]" type=3D"cite"> <=
br>
      <br>
      BTW - why are you looking at POP3-over-TLS? Isn't this idea
      obsolete - isn't the 'STLS' command (RFC 2595) the way we should
      be doing things now? I thought the POP3S way was deprecated.<br>
      <br>
      Note that the RFC 2595 says:<br>
      "The STLS command is only permitted in AUTHORIZATION state and the
      server remains in AUTHORIZATION state, even if client credentials
      are supplied during the TLS negotiation." so with STLS you have to
      authenticate (not sure why it's called 'authorization' state when
      it's really 'authentication' state<span class=3D"Apple-style-span"
        style=3D"border-collapse: separate; color: rgb(0, 0, 0);
        font-family: 'Times New Roman'; font-style: normal;
        font-variant: normal; font-weight: normal; letter-spacing:
        normal; line-height: normal; orphans: 2; text-indent: 0px;
        text-transform: none; white-space: normal; widows: 2;
        word-spacing: 0px; font-size: medium;"><span
          class=3D"Apple-style-span" style=3D"color: rgb(46, 44, 44);
          font-family: Georgia,'Times New Roman',Times,serif; font-size:
          15px; line-height: 22px;"></span></span>, but that's not
      relevant) even if the TLS has already supplied the user details.<br=
>
    </blockquote>
    Yes, RFC 2595 discouraged use of POP-over-TLS.=C2=A0 However, it is n=
ow
    used even wider than STLS, which led to effort to document this
    mode.=C2=A0 See above for note on why authorization might not be
    necessary after TLS negotiation.<br>
    <br>
    Mykyta<br>
    <blockquote cite=3D"mid:[email protected]" type=3D"cite"> <=
br>
      <br>
      <br>
    </blockquote>
    <br>
  </body>
</html>

--------------040709010300010303090803--