ietf-nntp RFC977bis w.r.t. authentication

[Larry Osterman (Exchange)]

Remember - I'm an individual, as we all are.  This means that I speak for
myself, and not for Microsoft.

I can state what both of the Microsoft servers do, that behavior is
reflected in the text I sent the other day.  I can't speak for what Netscape
does, since I've not actually observed their protocol exchanges (BHERN, care
to comment?), however I suspect that they do something similar.  The
Microsoft clients and servers both encapsulate the authentication traffic by
Base64 encoding the data and transmitting it over NNTP - which is correct
within the terms of SASL.

And there are several SASL authentication mechanisms that are NOT self
representing, and thus MUST be encapsulated in a higher level protocol.  For
example, the DIGEST authentication package that's currently being proposed
for WEBDAV is not self contained, neither is the NTLM or DPA authentication
mechanisms.  These are all authentication mechanisms that are intended to be
encapsulated in a higher level protocol.

I don't see why it is such a big deal to require that the NNTP protocol
describe how to transfer authentication data....

Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 98 and
Exchange Server 5.5.  Please notify the sender of any difficulties


-----Original Message-----
From: Chris Lewis [mailto:Chris.Lewis.clewis at nt.com]
Sent: Thursday, May 07, 1998 11:13 AM
To: ietf-nntp at academ.com
Subject: Re: ietf-nntp RFC977bis w.r.t. authentication


Larry Osterman (Exchange) wrote:
> 
> There are 2 major problems with this idea.
> 
> The first (technical) is that TCP/IP is a stream oriented protocol.  This
> means that every message sent is subject to IP fragmentation, thus every
> packet needs to have enough information contained within it to allow for
> re-assembly on the receiving end.  Many of the existing security protocols
> do not have sufficient information in their packets to allow re-assembly
on
> the receiving end, so in effect the security information is "tunneled"
> through the higher level protocol - in other words, it uses the higher
level
> protocol to carry the security information.

This wasn't the original intent when I "designed" GENERIC.  Packet
reassembly
is what the authenticator (non-NNTP) part has to deal with.

> And that brings me to the second problem, and this one is a total
> show-stopper as far as I'm concerned.  Assuming that the security logic
> "takes over" the NNTP connection is about as egregious a layering
violation
> as I've ever seen.  And layering violations are a VERY bad thing.

The question really is, what is the Microsoft and Netscape servers doing
here?

If you believe this to be a show-stopper, with both Microsoft and Netscape
doing it in the show-stopper fashion, then we're screwed, because nobody
does it in a way compatible with SASL.

> BTW: Why didn't your message have a To: header? It made replying to this
> MUCH harder.

Since this list doesn't use Reply-To: headers properly, a reply-all goes
to both the list, with additional copies to potentially _everyone_ who
ever contributed to the thread to that point.  This pisses off people,
so they try to remove the other individuals in the reply-all.  Which
sometimes
results in the ietf-nntp at academ.com address remaining a Cc and not
a to or from.