Mykyta Yevstifeyev | 26 Jul 06:59 2011
Picon

POP handling commands given in wrong state


Hello,

Post Office Protocol (POP) currently has no means of explicit indicating 
that the command is given in the wrong state.

>     A server MUST respond to a command issued when the
>     session is in an incorrect state by responding with a negative status
>     indicator.

doesn't give enough information to the client.  The -ERR response 
indicating wrong state may override -ERR response given with its natural 
meaning.  I propose to define the new POP extension response code (RFC 
2449), WRONG-STATE, to indicate this.  Eg.:

> C: <connects to the server>
> S: +OK server ready
> C: STAT
> S: -ERR [WRONG-STATE] Not in TRANSACTION state yet

Any thoughts?

Mykyta Yevstifeyev

Paul Smith | 26 Jul 10:12 2011
Picon

Re: POP handling commands given in wrong state


On 26/07/2011 05:59, Mykyta Yevstifeyev wrote:
>
> Hello,
>
> Post Office Protocol (POP) currently has no means of explicit 
> indicating that the command is given in the wrong state.
>
>>     A server MUST respond to a command issued when the
>>     session is in an incorrect state by responding with a negative 
>> status
>>     indicator.
>
> doesn't give enough information to the client.  The -ERR response 
> indicating wrong state may override -ERR response given with its 
> natural meaning.  I propose to define the new POP extension response 
> code (RFC 2449), WRONG-STATE, to indicate this.  Eg.:
>
>> C: <connects to the server>
>> S: +OK server ready
>> C: STAT
>> S: -ERR [WRONG-STATE] Not in TRANSACTION state yet
>
> Any thoughts?
I wouldn't have thought it would matter

AIUI the extension response codes are so that the client can understand 
it enough to tell the user what the error means (eg mailbox in use, 
rather than invalid password, during the login phase, so don't bother 
asking for the correct password)
(Continue reading)

Mykyta Yevstifeyev | 26 Jul 11:22 2011
Picon

Re: POP handling commands given in wrong state


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?

<thinking>The user agent may allow the user to choose the authentication 
way for POP-over-TLS transaction.  Eg., Thunderbird allows me to set 
(Continue reading)

Paul Smith | 26 Jul 11:51 2011
Picon

Re: POP handling commands given in wrong state

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.


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.



Mykyta Yevstifeyev | 26 Jul 15:19 2011
Picon

Re: POP handling commands given in wrong state

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




Randall Gellens | 26 Jul 15:17 2011

Re: POP handling commands given in wrong state


At 12:22 PM +0300 7/26/11, Mykyta Yevstifeyev wrote:

>  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?

Per RFC 4206, the server should issue the AUTH-RESP-CODE capability 
tag, indicating "that the server includes the AUTH response code with 
any authentication error caused by a problem with the user's 
credentials" and then in the case you cite, don't issue the AUTH 
response code in an -ERR response to USER.

By issuing the AUTH response code and then not including the AUTH 
response code, that indicates that the error has nothing to do with 
the user's credentials.

I agree that you would have to infer that the user is already 
authenticated, which isn't as nice as having an explicit response 
code.  I'm not sure if it's worth adding the explicit tag or not, but 
don't have an objection to it.

--

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Think twice before speaking, but don't say "think think click click".

Paul Smith | 26 Jul 15:32 2011
Picon

Re: POP handling commands given in wrong state

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...

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."

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)

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.

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...

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.

IMHO



Paul Smith | 26 Jul 15:35 2011
Picon

Re: POP handling commands given in wrong state

On 26/07/2011 14:17, Randall Gellens wrote:

Per RFC 4206, the server should issue the AUTH-RESP-CODE capability tag, indicating "that the server includes the AUTH response code with any authentication error caused by a problem with the user's credentials" and then in the case you cite, don't issue the AUTH response code in an -ERR response to USER.

Hmm - maybe you have the wrong RFC number there - or I'm missing something in our implementation because our mail server doesn't do anything about "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)"... :)



Randall Gellens | 26 Jul 16:30 2011

Re: POP handling commands given in wrong state


At 2:35 PM +0100 7/26/11, Paul Smith wrote:

>  On 26/07/2011 14:17, Randall Gellens wrote:
>
>>
>>  Per RFC 4206, the server should issue the AUTH-RESP-CODE 
>> capability tag, indicating "that the server includes the AUTH 
>> response code with any authentication error caused by a problem 
>> with the user's credentials" and then in the case you cite, don't 
>> issue the AUTH response code in an -ERR response to USER.
>>
>
>  Hmm - maybe you have the wrong RFC number there - or I'm missing 
> something in our implementation because our mail server doesn't do 
> anything about "Label Switched Paths (LSP) Hierarchy with 
> Generalized Multi-Protocol Label Switching (GMPLS) Traffic 
> Engineering (TE)"... :)

Sorry about that, slip of the fingers.  It's RFC 3206 (not 4206).

--

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
See, in my line of work, you got to keep repeating things over and
over and over again for the truth to sink in, to kind of catapult
the propaganda.
        --U.S. President George W. Bush in New York, May 24, 2005

Randall Gellens | 26 Jul 16:35 2011

Re: POP handling commands given in wrong state


At 6:17 AM -0700 7/26/11, Randall Gellens wrote:

>  Per RFC 3206, the server should issue the AUTH-RESP-CODE capability 
> tag, indicating "that the server includes the AUTH response code 
> with any authentication error caused by a problem with the user's 
> credentials" and then in the case you cite, don't issue the AUTH 
> response code in an -ERR response to USER.
>
>  By issuing the AUTH response code and then not including the AUTH 
> response code, that indicates that the error has nothing to do with 
> the user's credentials.

Just to be clear, if the server issued AUTH-RESP-CODE, then the 
result to USER can be interpreted:
	+OK:			Accepted, proceed to PASS
	-ERR [AUTH]:		Failed, problem with user credentials (not 
likely with USER anyway)
	-ERR [SYS/TEMP]:	Failed due to temporary system problem, try again later
	-ERR [SYS/PERM]:	Failed due to permanent system problem, 
advise user to call for help
	-ERR:				No problem w/ credentials nor system, if you 
used TLS w/ cert, maybe authenticated already

--

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Too often, we see a failure to distinguish sufficiently clearly
between the intrinsic problems of computer science and the
difficulties resulting from the shortcomings of our various
educational systems.                       --Edsger W. Dijkstra


Gmane