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

[Jack De Winter <[e-mail]>]

At 12:20 PM 12/27/96 -0800, Nat Ballou wrote:
>> From: Jack De Winter <[e-mail]>
>> To: Chris Newman <[e-mail]>OM>; Rich Salz <[e-mail]>
>> Cc: [e-mail]
>> 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.
[phone]		http://www.wildbear.on.ca/

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