Re: POP handling commands given in wrong state

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

26.07.2011 16:32, Paul Smith wrote:
> On 26/07/2011 14:19, Mykyta Yevstifeyev wrote:
>>> 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.
>
> Hmm, I think if you are talking about existing implementations using a 
> deprecated system, then trying to alter the behaviour of them is 
> unlikely to achieve anything...
I wouldn't say it is deprecated; POP-over-TLS is used even more often 
that STLS, as I've already mentioned.  We're trying to give it the 
official documentation and set the standard behavior of the server/client.
>
> Personally, I'd say that a POP3 server that skips the authorization 
> state because of the certificate is not standards compliant, because 
> there is no standard which allows that behaviour.
>
> RFC 1939 section 3 says "Once the TCP connection has been opened and 
> the POP3 server has sent the greeting, the session enters the 
> AUTHORIZATION state. In this state, the client must identify itself to 
> the POP3 server."
In our case the AUTHORIZATION is safely replaced by TLS negotiation.  It 
also happens directly after TCP connection, but skipping the greeting, 
which is replaced by TLS ServerHello message.
>
> Potentially, the client could identify itself using the certificate - 
> HOWEVER, this has to happen *after the POP3 server has sent the 
> greeting* for it to be standards compliant, so it can't be done using 
> the certificate with POP3-over-TLS (it could have been, using the STLS 
> extension, except that specifically excludes that option)
This assumes use of STLS, which performs TLS negotiation during POP3 
session.  POP-over-TLS deliberately makes use of TLS before POP session.
>
> So, any server which does not enter AUTHORIZATION state after the 
> connection has been opened and the POP3 server has sent the greeting 
> is NOT RFC 1939 compliant.
See above.  Server greeting = ServerHello TLS message; authentication = 
TLS negotiation.
>
> If you are wanting to change the behaviour of existing POP3-over-TLS 
> server implementations so they send a POP3 extended response, then you 
> should rather change their behaviour so they are compliant to the 
> existing RFC 1939 instead...
They can't be anyway as some required steps of RFC 1939 are replaced by 
TLS steps.  This results in a modified protocol.
>
> If you are just wanting to document existing behaviour, then this 
> doesn't matter, as neither the extended response nor standard 
> compliant behaviour is possible.
But if we try to unify all existing behavior, this will be great, won't it?

Mykyta Yevstifeyev
>
> IMHO
>
>
>


--------------030708020903000000070100
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 p6R4uOOQ046031

<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 16:32, 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 14:19, Mykyta Yevstifeyev wrote:
      <blockquote cite=3D"mid:[email protected]" type=3D"cite">
        <blockquote cite=3D"mid:[email protected]" type=3D"cite=
">
          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 will lead to -ERR, as the server is already in TRANSACTION
        then.=C2=A0 Other servers implement POP-over-TLS so that further
        authentication is also required (eg. Gmail, which I personally
        am using).<br>
        <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<s=
pan
            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,'Time=
s
              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
        now used even wider than STLS, which led to effort to document
        this mode.=C2=A0 See above for note on why authorization might no=
t be
        necessary after TLS negotiation.<br>
      </blockquote>
      <br>
      Hmm, I think if you are talking about existing implementations
      using a deprecated system, then trying to alter the behaviour of
      them is unlikely to achieve anything...<br>
    </blockquote>
    I wouldn't say it is deprecated; POP-over-TLS is used even more
    often that STLS, as I've already mentioned.=C2=A0 We're trying to giv=
e it
    the official documentation and set the standard behavior of the
    server/client.<br>
    <blockquote cite=3D"mid:[email protected]" type=3D"cite"> <=
br>
      Personally, I'd say that a POP3 server that skips the
      authorization state because of the certificate is not standards
      compliant, because there is no standard which allows that
      behaviour.<br>
      <br>
      RFC 1939 section 3 says "Once the TCP connection has been opened
      and the POP3 server has sent the greeting, the session enters the
      AUTHORIZATION state. In this state, the client must identify
      itself to the POP3 server.<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><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>"<br>
    </blockquote>
    In our case the AUTHORIZATION is safely replaced by TLS
    negotiation.=C2=A0 It also happens directly after TCP connection, but
    skipping the greeting, which is replaced by TLS ServerHello message.<=
br>
    <blockquote cite=3D"mid:[email protected]" type=3D"cite"> <=
br>
      Potentially, the client could identify itself using the
      certificate - HOWEVER, this has to happen *after the POP3 server
      has sent the greeting* for it to be standards compliant, so it
      can't be done using the certificate with POP3-over-TLS (it could
      have been, using the STLS extension, except that specifically
      excludes that option)<br>
    </blockquote>
    This assumes use of STLS, which performs TLS negotiation during POP3
    session.=C2=A0 POP-over-TLS deliberately makes use of TLS before POP
    session.<br>
    <blockquote cite=3D"mid:[email protected]" type=3D"cite"> <=
br>
      So, any server which does not enter AUTHORIZATION state after the
      connection has been opened and the POP3 server has sent the
      greeting is NOT RFC 1939 compliant. <br>
    </blockquote>
    See above.=C2=A0 Server greeting =3D ServerHello TLS message;
    authentication =3D TLS negotiation.<br>
    <blockquote cite=3D"mid:[email protected]" type=3D"cite"> <=
br>
      If you are wanting to change the behaviour of existing
      POP3-over-TLS server implementations so they send a POP3 extended
      response, then you should rather change their behaviour so they
      are compliant to the existing RFC 1939 instead...<br>
    </blockquote>
    They can't be anyway as some required steps of RFC 1939 are replaced
    by TLS steps.=C2=A0 This results in a modified protocol.<br>
    <blockquote cite=3D"mid:[email protected]" type=3D"cite"> <=
br>
      If you are just wanting to document existing behaviour, then this
      doesn't matter, as neither the extended response nor standard
      compliant behaviour is possible.<br>
    </blockquote>
    But if we try to unify all existing behavior, this will be great,
    won't it?<br>
    <br>
    Mykyta Yevstifeyev<br>
    <blockquote cite=3D"mid:[email protected]" type=3D"cite"> <=
br>
      IMHO<br>
      <br>
      <br>
      <br>
    </blockquote>
    <br>
  </body>
</html>

--------------030708020903000000070100--