Subject: last cut of SASL

From: John Gardiner Myers <[email-masked]>
Date: Wed, 18 Dec 1996 16:27:03 -0500 (EST)

I'm putting out an -07 version of the base spec and will be
immediately asking for it to go to Last Call.  This version fixes a
typo and clarifies that the SKEY mechanism is for S/Key used with MD4.

> The mechanisms in the document should be defined according the the
> registration template, so they can better serve as examples.

The registration of a mechanism and its description are two different
things.  When the draft gets approved, I will be sending in
registrations for the mechanism defined in the document, referring to
the document for the mechanisms' description.

-- 
_.John Gardiner Myers	Internet: [email-masked]
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up

Date: Wed, 18 Dec 1996 16:27:03 -0500 (EST)
From: John Gardiner Myers <[email-masked]>
To: [email-masked]
Subject: last cut of SASL
Sender: [email-masked]

I'm putting out an -07 version of the base spec and will be
immediately asking for it to go to Last Call.  This version fixes a
typo and clarifies that the SKEY mechanism is for S/Key used with MD4.

> The mechanisms in the document should be defined according the the
> registration template, so they can better serve as examples.

The registration of a mechanism and its description are two different
things.  When the draft gets approved, I will be sending in
registrations for the mechanism defined in the document, referring to
the document for the mechanisms' description.

-- 
_.John Gardiner Myers	Internet: [email-masked]
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up

Date: Mon, 16 Dec 1996 14:50:12 -0800 (PST)
From: Mike Macgirvin <[email-masked]>
Reply-To: Mike Macgirvin <[email-masked]>
Subject: Re: MAILING LIST LAST CALL
To: Jack De Winter <[email-masked]>
cc: Chris Newman <[email-masked]>, [email-masked], John C Klensin <[email-masked]>
Sender: [email-masked]

> One of my problems with SKEY has always been the 'use MD4 but
> a lot of implementations use MD5' line in the SKEY spec. 

IMAO, S/Key will probably be subsumed rapidly by OTP; which allows for passing
the hash algorithm name between the comm end-points and also allows resets
(when coupled with the OTP extended response draft). So AUTH=SKEY will
certainly be MD4 and only MD4. Anybody using MD5 or SHA hashes should use OTP
instead. The OTP negotiation itself is similiar enough to S/Key that folks can
probably implement at least the authentication phases based on how s/key works
today. The only question mark is the status of the OTP extended response draft,
which might affect how resets are done. (Maybe this has stabilized, I haven't
looked for a few weeks). 

Mike Macgirvin			<[email-masked]>
Postmaster General		Netscape Communications Corporation
Mail Server Engineering		http://netscape/people/max/

Any views expressed etc., etc.

Date: Mon, 16 Dec 1996 17:27:58 -0500
To: Chris Newman <[email-masked]>, [email-masked]
From: "Jack De Winter" <[email-masked]>
Subject: Re: MAILING LIST LAST CALL
Cc: John C Klensin <[email-masked]>
Sender: [email-masked]

>The S/Key mechanism should state explicitly that it uses MD4, or
>be flushed from the base spec.
>
>I'd like to see CRAM-MD5 folded into the base SASL spec, if John Klensin
>agrees.
>
>The mechanisms in the document should be defined according the the
>registration template, so they can better serve as examples.
>
>I'm looking forward to seeing this go standards track ASAP, and don't
>consider any of the above three suggestions show stoppers.

I concur.  One of my problems with SKEY has always been the 'use MD4 but
a lot of implementations use MD5' line in the SKEY spec.  And as someone
who just implemented CRAM, it is very easy to do as soon as you make sure
you read the example in the spec very carefully.

Also, since San Jose, I assume that we now have a IANA process for
registering new SASL types, and that should explicitly be spelled out,
as well as what to do in cases of collision and proprietary or testing
extensions.

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.

Date: Mon, 16 Dec 1996 14:23:22 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Re: MAILING LIST LAST CALL
To: [email-masked]
Cc: John C Klensin <[email-masked]>
Sender: [email-masked]

On Tue, 10 Dec 1996, John Gardiner Myers wrote:
> [mailing list last call on:]
> draft-myers-auth-sasl-06.txt

The S/Key mechanism should state explicitly that it uses MD4, or
be flushed from the base spec.

I'd like to see CRAM-MD5 folded into the base SASL spec, if John Klensin
agrees.

The mechanisms in the document should be defined according the the
registration template, so they can better serve as examples.

I'm looking forward to seeing this go standards track ASAP, and don't
consider any of the above three suggestions show stoppers.

Date: Tue, 10 Dec 1996 16:41:05 -0500 (EST)
From: John Gardiner Myers <[email-masked]>
To: [email-masked]
Subject: MAILING LIST LAST CALL
Sender: [email-masked]

Given the lack of a concrete proposal to the registration scheme in
draft-myers-auth-sasl-06.txt, and also given the lack of discussion
leading towards such a proposal, I am now issuing a mailing list last
call for the following documents.

draft-myers-sasl-pop3-00.txt
draft-myers-smtp-auth-04.txt
draft-myers-auth-sasl-06.txt

Unless I get a significant negative response by this time next week, I
intend to request an appropriate Area Director to review the documents
and issue an IETF-wide Last Call.

-- 
_.John Gardiner Myers	Internet: [email-masked]
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up