headers
Ken Murchison | 5 Jan 2003 00:02

Re: ietf-nntp Re: WG Review: Simple Authentication and Security Layer (sasl)


"Jeffrey M. Vinocur" wrote:
> 
> On Fri, 20 Dec 2002, Rob Siemborski wrote:
> 
> > I don't think there is a very strong argument against using TLS/PLAIN
> > for this purpose (given that this WG seems to be insistent that the
> > servers receive copies of the plaintext passwords,
> 
> We're still waiting for details from SASL people about the possibility of
> down-negotiation to plaintext after authentication.  I'd say that makes a
> difference.

FYI, I spent some time hacking the TLS renegotiation after
authentication stuff into the Cyrus NNTP server and test client, and it
_is_  possible using OpenSSL.  Its pretty straight forward adding this
to the server, but the client needs to be made aware of renegotiations
(checking error code of SSL_read()) and must provide the NULL ciphers. 
Perhaps its possible to tell OpenSSL to negotiate the least
secure/fastest cipher so that even if the NULL ciphers aren't available
we can get increased performance, but I haven't looked into it.

For those that are interested, here is a protocol dump of a
STARTTLS/PLAIN session using ssldump.  The renegotiation starts right
after the return code for the AUTHINFO command (record 15).  Starting at
record 26, the rest of the session is once again in plaintext (with
MAC).

New TCP connection #1: eagle.oceana.com(56489) <->
eagle.oceana.com(9119)
(Continue reading)

Permalink | Reply | 19 comments |
headers
Jeffrey M. Vinocur | 5 Jan 2003 03:33

ietf-nntp TLS cipher renegotation to NULL cipher

There is a new issue raised below that I'd like people to discuss.

It is of particular interest to people who want TLS protection only on the
authentication step, and to client authors who may be more in touch with
their users than I am.

(Note, by the way, that I don't know all that much about TLS, so if I say 
anything that doesn't make sense, please correct me.)

On Sat, 4 Jan 2003, Ken Murchison wrote:

> FYI, I spent some time hacking the TLS renegotiation after
> authentication stuff into the Cyrus NNTP server and test client, and it
> _is_  possible using OpenSSL.  Its pretty straight forward adding this
> to the server, 

Slick.  I have no objections to seeing the DSS draft resurrected in the
future if people find that the prefer it, but I think given the above, we
don't need to block on DSS for AUTHINFO SASL to proceed.

>                but the client needs to be made aware of renegotiations
> (checking error code of SSL_read()) and must provide the NULL ciphers. 

Does anyone feel we should have verbiage discussing the possibility of
renegotiations in the STARTTLS draft?  For example, a warning to check for 
the above, or a suggestion/requirement that clients have a configuration 
option to request renegotiation to NULL.

How do people see this renegotation being used?  I'm wondering in 
particular if I need to add something else at the NNTP level; what happens
(Continue reading)

Permalink | Reply | 18 comments |
headers
Ken Murchison | 5 Jan 2003 20:24

Re: ietf-nntp TLS cipher renegotation to NULL cipher


"Jeffrey M. Vinocur" wrote:
> 
> There is a new issue raised below that I'd like people to discuss.
> 
> It is of particular interest to people who want TLS protection only on the
> authentication step, and to client authors who may be more in touch with
> their users than I am.
> 
> (Note, by the way, that I don't know all that much about TLS, so if I say
> anything that doesn't make sense, please correct me.)

Another feature of TLS that might be of interest to those with
bandwith/performance concerns, is that you can negotiate a compression
algorithm.  AFAIK, zlib compression is the only algorithm currently
documented (in an I-D) and implemented in OpenSSL.

> 
> On Sat, 4 Jan 2003, Ken Murchison wrote:
> 
> > FYI, I spent some time hacking the TLS renegotiation after
> > authentication stuff into the Cyrus NNTP server and test client, and it
> > _is_  possible using OpenSSL.  Its pretty straight forward adding this
> > to the server,
> 
> Slick.  I have no objections to seeing the DSS draft resurrected in the
> future if people find that the prefer it, but I think given the above, we
> don't need to block on DSS for AUTHINFO SASL to proceed.
> 
> >                but the client needs to be made aware of renegotiations
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jeffrey M. Vinocur | 5 Jan 2003 21:20

Re: ietf-nntp TLS cipher renegotation to NULL cipher

On Sun, 5 Jan 2003, Ken Murchison wrote:

> "Jeffrey M. Vinocur" wrote:
> > 
> 
> Another feature of TLS that might be of interest to those with
> bandwith/performance concerns, is that you can negotiate a compression
> algorithm.  AFAIK, zlib compression is the only algorithm currently
> documented (in an I-D) and implemented in OpenSSL.

Oh good, I was hoping that we could avoid doing compression (which is 
something that has come up in the past) as yet another layer.

> I don't think we need anything else at the NNTP level.  TLS has its own
> handshake protocol, so it should be used.

This is what I'm hoping.

> > if a server admin wants to allow users to protect their entire connection,
> > but wants most of them to drop to the NULL cipher after authentication?
> 
> Per RFC 2246 both the client and server can request a reneg anytime, and
> either are free to refuse to do so if they wish.  So, I think there is
> already enough controls to configure the client/server policy.

Well, in the scenario above, it doesn't seem like the client can
distinguish between the server saying "renegotiate to NULL or I'm
disconnecting you" and "I'd like NULL but you don't have to".  But I guess
this could be implemented by the server requesting NULL, the client 
complying, and then the client requesting encryption again and seeing if
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jeffrey M. Vinocur | 5 Jan 2003 21:38

ietf-nntp Multiple AUTHINFOs per session

Ken has raised the issue of whether a client should be able to AUTHINFO
multiple times in the same session.  Some observations:

- If an AUTHINFO fails, the client should be able to retry (unless the
  server has chosen to close the connection).  Agreed?

- INN at least permits clients to use AUTHINFO USER/PASS multiple times.
  Do other servers do the same?  (Of course, I suspect few if any clients
  actually attempt this functionality.  Anyone know about that?)

- For the purposes of AUTHINFO SASL, this issue is explicitly raised in
  RFC 2222 (excerpted below).  I don't think we've ever discussed this
  issue -- let me know if we have -- but certainly the easiest approach
  is to disallow it.

5.3.  Multiple authentications

   Unless otherwise stated by the protocol's profile, only one
   successful SASL negotiation may occur in a protocol session.  In this
   case, once an authentication protocol exchange has successfully
   completed, further attempts to initiate an authentication protocol
   exchange fail.

   In the case that a profile explicitly permits multiple successful
   SASL negotiations to occur, then in no case may multiple security
   layers be simultaneously in effect.  If a security layer is in effect
   and a subsequent SASL negotiation selects no security layer, the
   original security layer remains in effect.  If a security layer is in
   effect and a subsequent SASL negotiation selects a second security
   layer, then the second security layer replaces the first.
(Continue reading)

Permalink | Reply | 20 comments |
headers
Ken Murchison | 5 Jan 2003 22:02

Re: ietf-nntp TLS cipher renegotation to NULL cipher


"Jeffrey M. Vinocur" wrote:
> 
> On Sun, 5 Jan 2003, Ken Murchison wrote:
> 
> > "Jeffrey M. Vinocur" wrote:
> > > if a server admin wants to allow users to protect their entire connection,
> > > but wants most of them to drop to the NULL cipher after authentication?
> >
> > Per RFC 2246 both the client and server can request a reneg anytime, and
> > either are free to refuse to do so if they wish.  So, I think there is
> > already enough controls to configure the client/server policy.
> 
> Well, in the scenario above, it doesn't seem like the client can
> distinguish between the server saying "renegotiate to NULL or I'm
> disconnecting you" and "I'd like NULL but you don't have to".  But I guess
> this could be implemented by the server requesting NULL, the client
> complying, and then the client requesting encryption again and seeing if
> it succeeds.
> 
> Or maybe this is an absurd situation?  I'm hoping to hear back from e.g.
> Andrew about what might actually occur.

I'm not sure what type of configs you're looking for, some I'm a little
confused.  Maybe a little background on how TLS negotiation works might
help clarify (caveat: I'm not expert either).  In a normal scenario, the
client presents a list of ciphers that it is willing to use to the
server.  The server then picks one and tells the client whcih one to
use.  This is the same in a renegotiation case as well.  A client
initiated reneg looks essentially the same as a initial negotiation.  In
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ken Murchison | 5 Jan 2003 22:09

Re: ietf-nntp Multiple AUTHINFOs per session


"Jeffrey M. Vinocur" wrote:
> 
> Ken has raised the issue of whether a client should be able to AUTHINFO
> multiple times in the same session.  Some observations:
> 
> - If an AUTHINFO fails, the client should be able to retry (unless the
>   server has chosen to close the connection).  Agreed?

Yes, of course.  I should have said multiple successful authentications.

> - INN at least permits clients to use AUTHINFO USER/PASS multiple times.
>   Do other servers do the same?  (Of course, I suspect few if any clients
>   actually attempt this functionality.  Anyone know about that?)

If it turns out that no clients actually use this in practice, then I'd
say scrap it.

What is the intended use?  And what is the big deal with starting a new
session?

None of the other similar protocols (IMAP, POP3, SMTP) allow such a
thing.

> - For the purposes of AUTHINFO SASL, this issue is explicitly raised in
>   RFC 2222 (excerpted below).  I don't think we've ever discussed this
>   issue -- let me know if we have -- but certainly the easiest approach
>   is to disallow it.

If we follow SASL's recommendation of only one successful authentication
(Continue reading)

Permalink | Reply | 0 comments |
headers
Howard Swinehart | 5 Jan 2003 22:19
Picon

Re: ietf-nntp Multiple AUTHINFOs per session

From: "Jeffrey M. Vinocur" <jeff <at> litech.org>
> - INN at least permits clients to use AUTHINFO USER/PASS multiple times.
>   Do other servers do the same?  (Of course, I suspect few if any clients
>   actually attempt this functionality.  Anyone know about that?)

Binary Boy (http://www.binaryboy.com/) has an option to retry the password,
although I don't know how many people use this feature.  Some servers return
an authentication error when the client opens too many connections, such as
when a user opens both an auto downloader and a newsreader at the same time.
This allows the client to wait out any temporary problems without repeatedly
opening and closing new connections.

_______________________________________________
ietf-nntp mailing list
ietf-nntp <at> academ.com
https://www.academ.com/mailman/listinfo/ietf-nntp
Permalink | Reply | 0 comments |
headers
Andrew Gierth | 6 Jan 2003 02:40
Picon
Picon

Re: ietf-nntp Multiple AUTHINFOs per session

>>>>> "Jeffrey" == Jeffrey M Vinocur <jeff <at> litech.org> writes:

 Jeffrey> Ken has raised the issue of whether a client should be able
 Jeffrey> to AUTHINFO multiple times in the same session.  Some
 Jeffrey> observations:

 Jeffrey> - If an AUTHINFO fails, the client should be able to retry
 Jeffrey> (unless the server has chosen to close the connection).
 Jeffrey> Agreed?

The usual case on failed authentication is to send the 502 response and
close the connection.

There seems to be no obvious reason to allow clients to retry a failed
authentication.

 Jeffrey> - INN at least permits clients to use AUTHINFO USER/PASS
 Jeffrey> multiple times.  Do other servers do the same?

in many cases it's awkward to actually change the credentials
associated with the session. I know that some servers will accept and
ignore subsequent AUTHINFO commands once the user is authorised (either
by IP or by previous AUTHINFO command).

 Jeffrey> (Of course, I suspect few if any clients actually attempt
 Jeffrey> this functionality.  Anyone know about that?)

I've not heard of any client legitimately trying to do this.

The usual (almost universal) assumption is that authentication is for
(Continue reading)

Permalink | Reply | 17 comments |
headers
Jeffrey M. Vinocur | 6 Jan 2003 03:23

Re: ietf-nntp Multiple AUTHINFOs per session

On 6 Jan 2003, Andrew Gierth wrote:

> >>>>> "Jeffrey" == Jeffrey M Vinocur <jeff <at> litech.org> writes:
> 
>  Jeffrey> - If an AUTHINFO fails, the client should be able to retry
>  Jeffrey> (unless the server has chosen to close the connection).
>  Jeffrey> Agreed?
> 
> The usual case on failed authentication is to send the 502 response and
> close the connection.

This is certainly what INN does -- yet it is not required.

> There seems to be no obvious reason to allow clients to retry a failed
> authentication.

Well, most protocols do, don't they?  I can't actually think of one that 
doesn't, offhand.

> in many cases it's awkward to actually change the credentials
> associated with the session. 

I can imagine this in some implementations.

> I know that some servers will accept and
> ignore subsequent AUTHINFO commands once the user is authorised (either
> by IP or by previous AUTHINFO command).

Hum!
(Continue reading)

Permalink | Reply | 16 comments |

Gmane