Re: POP handling commands given in wrong state
Paul Smith <[email protected]> Tue, 26 Jul 2011 10:51:12 +0100
| Newsgroups | gmane.ietf.pop3ext |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--------------010506080401080605030006
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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.
--------------010506080401080605030006
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 p6Q9xtIn090664
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Ty=
pe">
</head>
<body bgcolor=3D"#ffffff" text=3D"#000000">
On 26/07/2011 10:22, Mykyta Yevstifeyev wrote:
<blockquote cite=3D"mid:[email protected]" type=3D"cite">26.=
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 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.=C2=A0 I and Alexey Melnikov are currently working o=
n
the POP-over-TLS specification
(<a class=3D"moz-txt-link-freetext" href=3D"https://datatracker.iet=
f.org/doc/draft-melnikov-pop3-over-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 U=
SER
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 have 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>
<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, 4=
4,
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>
<br>
<br>
<br></body>
</html>
--------------010506080401080605030006--