ietf-nntp My notes from the NNTP WG meeting at the 37thIETF
Jack De Winter
jack at wildbear.on.ca
Sat Dec 28 10:01:20 PST 1996
At 12:20 PM 12/27/96 -0800, Nat Ballou wrote:
>> From: Jack De Winter <jack at wildbear.on.ca>
>> To: Chris Newman <Chris.Newman at INNOSOFT.COM>; Rich Salz <rsalz at osf.org>
>> Cc: ietf-nntp at academ.com
>> Subject: Re: ietf-nntp My notes from the NNTP WG meeting at the 37thIETF
>> Date: Friday, December 20, 1996 1:38 PM
>>
>> [... this is actually a follow-up to two of Jack's messages ...]
>>
>> >Using AUTHINFO GENERIC as defined seems the fast path to getting
>> >977bis out. Adding new commands belongs in extensions.
>>
>> I agree with this. My contention is that there may be existing
>> implementation that may use AUTHINFO GENERIC in a way that could
>> contradict with the SASL stuff. If we specifically put information
>> into the spec that says words to the effect of 'AUTHINFO GENERIC
>> allows the use of any protocols defined through the SASL framework'...
>> then I would give it my rubber stamp.
>>
>> Once again, if we can implmenent AUTHINFO GENERIC so that it is in
>> effect SASL, then I agree with it 100%. Otherwise, I am concerned
>> about any implementations that may have done something else with it.
>> And I would strongly object to AUTHINFO GENERIC SASL as the space
>> occupied by SASL should be for authentication type, not the SASL
>> framework.
>
>O.K. - now I understand where you are coming from - and I agree
>with making AUTHINFO GENERIC support the SASL framework for NNTP.
same here. I am not tied to the draft becoming an RFC, I just want
to see a solid, extensible security framework, and I think SASL
(which by default supports Kerberos, SKEY(MD4), and one other) is
a great step. Also, seeing as it is being looked at already by
the Security area, means that it will make it that easier for any
security concerns.
>> p.s. What would be the best way of showing a list of the valid
>> authentication types in NNTP? LIST AUTHINFO? AUTHINFO LIST?
>
>A while back, I threw out the following behavior for the AUTHINFO
>command :
>
> C: AUTHINFO GENERIC
> S: 281 List follows
> S: KERBEROS_V4
> S: GSSAPI
> S: .
>
>That is, an AUTHINFO GENERIC command with no arguments would return
>a CR/LF separated lis of authentication providers supported by the
>server. This is similar to Myer's AUTH SASL proposal for POP3/IMAP.
>This is a simple change to AUTHINFO GENERIC that is unlikely to
>break any existing clients and provides a simple method for clients
>capable of negotiating authentication providers.
This is a six of one, 14 of another. While SASL leans towards that
way, it also leans towards a request structure. Seeing as the bulk
of the news commands don't have defaults, and uses the LIST command
for information, my candidates would be:
AUTHINFO LIST and LIST AUTHINFO
as they would fit in with the architecture.
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.
More information about the ietf-nntp
mailing list