ietf-nntp My notes from the NNTP WG meeting at the 37thIETF

[Jack De Winter]

>The intent was that AUTHINFO LIST show you what crypto-mechs were
>supported by the server, and the client picks one.  AUTHINFO GENERIC
>was intended to be a really simple mapping right onto GSSAPI.
>
>By the time the code and "spec" got out there, I had given up almost all
>work on NNTP.  I also didn't know enough about SASL, but at the time
>AG :) was only lagging about two months behind SASL.  John ran really
>hard with his implementation, etc., so the gap is now probably six
>months in terms of finish AG, quality of implementation, etc.  I don't
>know what's the better course of action, primarily because I don't know
>much about SASL.  For example, does it include negotiation that is not
>suspect to man-in-the-middle downgrading?  (I.e., it's not CAT-IETF SNEGO?)

I professional wouldn't see any problems with making AUTHINFO GENERIC into
the equivalent of AUTHSASL with one exception: what about existing news
readers that are doing something with it already?

Other than that, we could rework it so that AUTHINFO LIST would give a list
of the types, etc. However, seeing as we are supposed to be coming up
with 977bis as an accurate reflection of the protocol as it is at the
moment and would need 2 implementations, I am not sure of the
practicalities. (Keith?)

One of the good points of an AUTHSASL extensions is that it does not break
any existing code, but provides an upgrade path.  One of the bad points
is that it might compete with AUTHINFO GENERIC and would hold up and even
be against the 977bis charter.  Another one is that we would have to have
2 complete implementations by the cut of date, or force Stan to make
news changes to the drafts every couple of months (which is not fair by
any means).

As for negotiation, it is totally in the hands of the client.  The server
may enforce a certain level, but that is totally dependant on the server
and is not mandated or even discussed in the spec.  It simply provides
a convenient framework for supplying authentication and encryption
mechanisms to protocols.

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 576-3873		http://www.wildbear.on.ca/

Author of SLMail(95/NT) (http://www.seattlelab.com/) and other great products.