Subject: Re: SASL mechanism
From: Kurt Zeilenga <[email-masked]>
To: Joel Fieber <[email-masked]>
Cc: <[email-masked]>
Date: Thu, 16 Aug 2007 17:38:41 -0700
List-Id: <ietf-sasl.imc.org>

On Aug 16, 2007, at 5:03 PM, Joel Fieber wrote:

> Any recommendations?

TLS + PLAIN (embedded client or not).

-- Kurt

Date: Thu, 16 Aug 2007 16:10:59 -0700
From: "Rob Siemborski" <[email-masked]>
To: "Kurt Zeilenga" <[email-masked]>
Subject: Re: SASL mechanism
Cc: "Joel Fieber" <[email-masked]>, [email-masked]
Sender: [email-masked]

Ken Murchison did an internet draft of the LOGIN mechanism at one
point, I think it is here, at least:

http://www.lichteblau.com/ldapvi/cyrus-sasl/draft-murchison-sasl-login-00.txt

-Rob

On Aug 16, 2007 3:43 PM, Kurt Zeilenga <[email-masked]> wrote:
>
>
> On Aug 16, 2007, at 3:21 PM, Joel Fieber wrote:
>
> >
> > Hello,
> >
> > I am looking for the definition of the SASL LOGIN mechanism as
> > defined for the SMTP AUTH command. It is the most common mechanism
> > I have seen, yet I can't find it in the registry page (http://
> > www.iana.org/assignments/sasl-mechanisms). Every email client
> > supports it, but no one has defined it. Please help.
>
> The SASL "LOGIN" mechanism doesn't formally exist.  That is, there is
> no formal specification for it (as far as I know).
>
> If it were to ever be registered, it surely would be registered as
> having OBSOLETE usage.
>
> "LOGIN" is deprecated in favor of "PLAIN" [RFC 4616].  "PLAIN" is
> widely implemented.  Note: PLAIN may only be advertised when adequate
> external protective services (e.g., TLS) have been established.
>
>
> Regards, Kurt
>
> >
> > Thanks,
> >
> > Joel Fieber, B.Eng
> > Firmware Engineer
> > Reliable Controls Corporation   www.reliablecontrols.com
> > 120 Hallowell Road              T. Free:        (877) 475-9301
> > Victoria, British Columbia      Tel:    (250) 475-2036
> > Canada V9A 7K2          Fax:    (250) 475-2096
> >
> > CONFIDENTIALITY NOTICE: The information and/or documents contained
> > in this transmission may contain confidential or proprietary
> > information (business or technical data). The information is solely
> > for the use of the addressee named above. If you are not the
> > intended recipient, you are hereby notified that any disclosure,
> > copying, distribution, any action in reliance or other use of the
> > contents of this transmission is strictly prohibited. If you have
> > received this email in error, please send a return email and delete
> > this email from your system.
> >
>
>

-- 
Rob Siemborski        |     PGP:0x5CE32FCC    |     [email-masked]
Software Engineer     |                       |            650-623-6925

Cc: <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
Subject: Re: SASL mechanism
Date: Thu, 16 Aug 2007 15:43:36 -0700
To: "Joel Fieber" <[email-masked]>
Sender: [email-masked]

On Aug 16, 2007, at 3:21 PM, Joel Fieber wrote:

>
> Hello,
>
> I am looking for the definition of the SASL LOGIN mechanism as  
> defined for the SMTP AUTH command. It is the most common mechanism  
> I have seen, yet I can't find it in the registry page (http:// 
> www.iana.org/assignments/sasl-mechanisms). Every email client  
> supports it, but no one has defined it. Please help.

The SASL "LOGIN" mechanism doesn't formally exist.  That is, there is  
no formal specification for it (as far as I know).

If it were to ever be registered, it surely would be registered as  
having OBSOLETE usage.

"LOGIN" is deprecated in favor of "PLAIN" [RFC 4616].  "PLAIN" is  
widely implemented.  Note: PLAIN may only be advertised when adequate  
external protective services (e.g., TLS) have been established.

Regards, Kurt

>
> Thanks,
>
> Joel Fieber, B.Eng
> Firmware Engineer
> Reliable Controls Corporation   www.reliablecontrols.com
> 120 Hallowell Road              T. Free:        (877) 475-9301
> Victoria, British Columbia      Tel:    (250) 475-2036
> Canada V9A 7K2          Fax:    (250) 475-2096
>
> CONFIDENTIALITY NOTICE: The information and/or documents contained  
> in this transmission may contain confidential or proprietary  
> information (business or technical data). The information is solely  
> for the use of the addressee named above. If you are not the  
> intended recipient, you are hereby notified that any disclosure,  
> copying, distribution, any action in reliance or other use of the  
> contents of this transmission is strictly prohibited. If you have  
> received this email in error, please send a return email and delete  
> this email from your system.
>

Date: Sat, 11 Aug 2007 19:37:52 +0530
From: Abhijit Menon-Sen <[email-masked]>
To: Tony Hansen <[email-masked]>
Cc: [email-masked]
Subject: Re: proposed charter revision
Sender: [email-masked]

At 2007-08-10 11:24:18 -0400, [email-masked] wrote:
>
> I personally think it *needs* to be a native SASL mechanism and we
> should be wishy-washy about it being an instance of GS2. :-)

That's how I feel too.

-- ams

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
Subject: Re: proposed charter revision
Date: Fri, 10 Aug 2007 09:11:09 -0700
To: Tony Hansen <[email-masked]>
Sender: [email-masked]

On Aug 10, 2007, at 7:50 AM, Tony Hansen wrote:

>
> Kurt Zeilenga wrote:
>> I request the WG replace the paragraph discussing the DIGEST-MD5
>> replacement work with:
>>
>>> This group will deliver a Technical Specification, suitable for
>>> publication on the Standards Track, a password-based SASL mechanism.
>>> It is envisioned that this Technical Specification will replace the
>>> DIGEST-MD5 mechanism.  The WG will consider designing the  
>>> mechanism as
>>> a lightweight GSS-API mechanism.  It particular, the mechanism  
>>> should
>>> be designed such as it could be implemented without implementing a
>>> GSS-API framework, possibly by providing formal language  
>>> descriptions
>>> of the SASL encodings.  The WG may also consider designing this
>>> mechanism as a native SASL mechanism.
>
> The "may also" in the last sentence is kind of wishy washy. Unless I'm
> entirely off base, we intend to make it implementable as a native SASL
> mechanism, so why not say that?

The last sentence was intended to give the WG an out if the GSS-API  
design
approach was found unworkable.

> I personally think it *needs* to be a native SASL mechanism and we
> should be wishy-washy about it being an instance of GS2. :-)

We should consider the GS2 approach.  If its workable, great.  If  
not, we
design it as a native-only SASL mechanism.  In either case, we deliver a
suitable DIGEST-MD5 replacement in a reasonable amount of time.

So, I think we're agreeing on intent.  If the suggested text doesn't
adequately reflect this intent, please feel free to suggest alternative
text.

-- Kurt

Date: Fri, 10 Aug 2007 11:24:18 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: proposed charter revision
Sender: [email-masked]

Alexey Melnikov wrote:
>> The "may also" in the last sentence is kind of wishy washy. Unless I'm
>> entirely off base, we intend to make it implementable as a native SASL
>> mechanism, so why not say that?
>>
> I am not sure it is going to be a native SASL mechanism.
> And I don't think we know yet if the mechanism is going to be an
> instance of GS2 or not. I would rather not box ourselves by saying too
> much in the Charter.

I personally think it *needs* to be a native SASL mechanism and we
should be wishy-washy about it being an instance of GS2. :-)

	Tony Hansen
	[email-masked]

Date: Fri, 10 Aug 2007 16:12:34 +0100
From: Alexey Melnikov <[email-masked]>
To: Tony Hansen <[email-masked]>
CC: [email-masked]
Subject: Re: proposed charter revision
Sender: [email-masked]

Tony Hansen wrote:

>Kurt Zeilenga wrote:
>  
>
>>I request the WG replace the paragraph discussing the DIGEST-MD5
>>replacement work with:
>>    
>>
>>>This group will deliver a Technical Specification, suitable for
>>>publication on the Standards Track, a password-based SASL mechanism. 
>>>It is envisioned that this Technical Specification will replace the
>>>DIGEST-MD5 mechanism.  The WG will consider designing the mechanism as
>>>a lightweight GSS-API mechanism.  It particular, the mechanism should
>>>be designed such as it could be implemented without implementing a
>>>GSS-API framework, possibly by providing formal language descriptions
>>>of the SASL encodings.  The WG may also consider designing this
>>>mechanism as a native SASL mechanism.
>>>      
>>>
>The "may also" in the last sentence is kind of wishy washy. Unless I'm
>entirely off base, we intend to make it implementable as a native SASL
>mechanism, so why not say that?
>  
>
I am not sure it is going to be a native SASL mechanism.
And I don't think we know yet if the mechanism is going to be an 
instance of GS2 or not. I would rather not box ourselves by saying too 
much in the Charter.

Date: Fri, 10 Aug 2007 10:50:49 -0400
From: Tony Hansen <[email-masked]>
CC: [email-masked]
Subject: Re: proposed charter revision
Sender: [email-masked]

Kurt Zeilenga wrote:
> I request the WG replace the paragraph discussing the DIGEST-MD5
> replacement work with:
> 
>> This group will deliver a Technical Specification, suitable for
>> publication on the Standards Track, a password-based SASL mechanism. 
>> It is envisioned that this Technical Specification will replace the
>> DIGEST-MD5 mechanism.  The WG will consider designing the mechanism as
>> a lightweight GSS-API mechanism.  It particular, the mechanism should
>> be designed such as it could be implemented without implementing a
>> GSS-API framework, possibly by providing formal language descriptions
>> of the SASL encodings.  The WG may also consider designing this
>> mechanism as a native SASL mechanism.

The "may also" in the last sentence is kind of wishy washy. Unless I'm
entirely off base, we intend to make it implementable as a native SASL
mechanism, so why not say that?

	Tony Hansen
	[email-masked]

From: Sam Hartman <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: proposed charter revision
Date: Fri, 10 Aug 2007 08:47:28 -0400
Sender: [email-masked]

I also support the proposed charter revision.

Date: Fri, 10 Aug 2007 11:44:15 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: proposed charter revision
Sender: [email-masked]

Simon Josefsson wrote:

>>I request the WG replace the paragraph discussing the DIGEST-MD5
>>replacement work with:
>>    
>>
>>>This group will deliver a Technical Specification, suitable for
>>>publication on the Standards Track, a password-based SASL
>>>mechanism.  It is envisioned that this Technical Specification will
>>>replace the DIGEST-MD5 mechanism.  The WG will consider designing
>>>the mechanism as a lightweight GSS-API mechanism.  It particular,
>>>the mechanism should be designed such as it could be implemented
>>>without implementing a GSS-API framework, possibly by providing
>>>formal language descriptions of the SASL encodings.  The WG may
>>>also consider designing this mechanism as a native SASL mechanism.
>>>      
>>>
>That sounds better to me.
>  
>
This looks fine to me too.

From: Simon Josefsson <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, Tom Yu <[email-masked]>, [email-masked]
Subject: Re: proposed charter revision
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 10 Aug 2007 11:29:55 +0200
Sender: [email-masked]

Kurt Zeilenga <[email-masked]> writes:

> On Aug 9, 2007, at 10:16 AM, Jeffrey Hutzelman wrote:
>
>> Put more simply, I think it is desirable that SASL-FOO and SASL-GS2-
>> FOO interoperate, and I believe this requires that they have the
>> same mechanism name and the same bits on the wire, so that both
>> implementation paths lead to the same protocol.
>
> Yes, one SASL mechanism, in the GS2 family, a GSS-API password-based
> mechanism.
>
> I envision this work to result in a single RFC containing the normative
> specification of the GSS-API mechanism and an informative specification
> (in an appendix) of how one could implement the associated SASL/GS2
> mechanism
> without understanding and/or implementing (or using someone else's
> implementation)
> SASL/GS2 and GSS-API frameworks.

I believe that it is quite feasible, and a good idea.

The intention behind draft-josefsson-password-auth-00.txt was to
demonstrate that idea:

http://www.ietf.org/internet-drafts/draft-josefsson-password-auth-00.txt

I believe the GS2 spec needs to get published before we can seriously
consider this approach, though.

/Simon

Cc: Simon Josefsson <[email-masked]>, Tom Yu <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
Subject: Re: proposed charter revision
Date: Thu, 9 Aug 2007 10:43:57 -0700
To: Jeffrey Hutzelman <[email-masked]>
Sender: [email-masked]

On Aug 9, 2007, at 10:16 AM, Jeffrey Hutzelman wrote:

> Put more simply, I think it is desirable that SASL-FOO and SASL-GS2- 
> FOO interoperate, and I believe this requires that they have the  
> same mechanism name and the same bits on the wire, so that both  
> implementation paths lead to the same protocol.

Yes, one SASL mechanism, in the GS2 family, a GSS-API password-based  
mechanism.

I envision this work to result in a single RFC containing the normative
specification of the GSS-API mechanism and an informative specification
(in an appendix) of how one could implement the associated SASL/GS2  
mechanism
without understanding and/or implementing (or using someone else's  
implementation)
SASL/GS2 and GSS-API frameworks.

-- Kurt

Date: Thu, 09 Aug 2007 13:16:07 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>, Kurt Zeilenga <[email-masked]>
cc: Tom Yu <[email-masked]>, [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: proposed charter revision
Originator-Info: login-token=Mulberry:019gV5n2Bt7hNCUPEgKYOpDo13sMp9OfJjeqcELIU=; token_authority=[email-masked]
Sender: [email-masked]

On Thursday, August 09, 2007 10:49:26 AM +0200 Simon Josefsson 
<[email-masked]> wrote:

> I think having a dual GSSAPI/SASL password-based mechanism is a good
> idea.  It should be possible to implement the protocol (easily!) as a
> SASL mechanism, without having to understand or support GSS-API, and it
> should be possible to implement the protocol as a GSS-API mechanism.

The question is, do we base the SASL mechanism directly on the underlying 
protocol or on the GSS-API mechanism.  The main criteria I heard in Chicago 
was that SASL implementors be able to _implement_ the SASL mechanism 
without having to build or depend on a GSS-API implementation.  I believe 
it is possible to meet that requirement while still building the SASL 
mechanism on GS2 and the GSS-API mechanism.  I also think that doing so 
enhances interoperability, because it means that a SASL implementation 
which implements this mechanism directly will interoperate with one which 
implements GS2 and has a GSS-API implementation with this mechanism.

Put more simply, I think it is desirable that SASL-FOO and SASL-GS2-FOO 
interoperate, and I believe this requires that they have the same mechanism 
name and the same bits on the wire, so that both implementation paths lead 
to the same protocol.

-- Jeff

From: Simon Josefsson <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Tom Yu <[email-masked]>, [email-masked]
Subject: Re: proposed charter revision
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 09 Aug 2007 10:49:26 +0200
Sender: [email-masked]

Kurt Zeilenga <[email-masked]> writes:

> On Jul 24, 2007, at 5:02 PM, Tom Yu wrote:
>> This group will deliver a Technical Specification for a password-based
>> SASL mechanism to replace DIGEST-MD5.  In particular, this
>> specification will not transmit plaintext passwords (even if
>> encrypted), but will require less infrastructure than typical GSS-API
>> mechanisms.
>
> During the SASL session, we primarily discussed how the SCRAM and HEXA
> approaches might be combined as a solution to this work item.
> However, we also discussed the desire that work item be specified as
> a GSS-API mechanism that could be implemented without implementing
> the GSS-API specifications.  That is, by separately describing the
> mechanisms encodings using some formal language (e.g., ABNF).  There
> seemed to be reasonable support for, at least, attempting to specify
> this as a GSS-API mechanism with
> appendix providing formal language and other information to allow it
> to be implemented without implementing GSS-API.  This is not
> reflected in the proposed charter.

I think having a dual GSSAPI/SASL password-based mechanism is a good
idea.  It should be possible to implement the protocol (easily!) as a
SASL mechanism, without having to understand or support GSS-API, and it
should be possible to implement the protocol as a GSS-API mechanism.

> I request the WG replace the paragraph discussing the DIGEST-MD5
> replacement work with:
>
>> This group will deliver a Technical Specification, suitable for
>> publication on the Standards Track, a password-based SASL
>> mechanism.  It is envisioned that this Technical Specification will
>> replace the DIGEST-MD5 mechanism.  The WG will consider designing
>> the mechanism as a lightweight GSS-API mechanism.  It particular,
>> the mechanism should be designed such as it could be implemented
>> without implementing a GSS-API framework, possibly by providing
>> formal language descriptions of the SASL encodings.  The WG may
>> also consider designing this mechanism as a native SASL mechanism.

That sounds better to me.

/Simon

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
Subject: Re: proposed charter revision
Date: Wed, 8 Aug 2007 16:08:33 -0700
To: Tom Yu <[email-masked]>
Sender: [email-masked]

On Jul 24, 2007, at 5:02 PM, Tom Yu wrote:
> This group will deliver a Technical Specification for a password-based
> SASL mechanism to replace DIGEST-MD5.  In particular, this
> specification will not transmit plaintext passwords (even if
> encrypted), but will require less infrastructure than typical GSS-API
> mechanisms.

During the SASL session, we primarily discussed how the SCRAM and  
HEXA approaches might be combined as a solution to this work item.   
However, we also discussed the desire that work item be specified as  
a GSS-API mechanism that could be implemented without implementing  
the GSS-API specifications.  That is, by separately describing the  
mechanisms encodings using some formal language (e.g., ABNF).  There  
seemed to be reasonable support for, at least, attempting to specify  
this as a GSS-API mechanism with
appendix providing formal language and other information to allow it  
to be implemented without implementing GSS-API.  This is not  
reflected in the proposed charter.

Though not specifically mentioned during the meeting, the draft- 
johansson-password-auth I-D, might serve as a basis for the
GSS-API mechanism.

Though the proposed charter language doesn't state which, if any,  
current or past I-Ds might be used as a basis for this work item,  
there seems to be the unsaid assumption that the SCRAM and HEXA I-Ds  
will be used as a basis, and the charter language, by not discussing  
the GSS-API approach, furthers this assumption.

I request the WG replace the paragraph discussing the DIGEST-MD5  
replacement work with:

> This group will deliver a Technical Specification, suitable for  
> publication on the Standards Track, a password-based SASL  
> mechanism.  It is envisioned that this Technical Specification will  
> replace the DIGEST-MD5 mechanism.  The WG will consider designing  
> the mechanism as a lightweight GSS-API mechanism.  It particular,  
> the mechanism should be designed such as it could be implemented  
> without implementing a GSS-API framework, possibly by providing  
> formal language descriptions of the SASL encodings.  The WG may  
> also consider designing this mechanism as a native SASL mechanism.

Though this text also doesn't mention any I-Ds to be used as a basis  
for the work, I think this language washes away the assumption that  
SCRAM and HEXA, only, will serve as the basis.

Regards, Kurt

To: [email-masked]
From: Lyndon Nerenberg <[email-masked]>
Subject: CRAM -09 published
Date: Tue, 7 Aug 2007 11:00:53 -0700
Sender: [email-masked]

Version -09 of the draft is out.  It fixes the grammar conflict I  
found just after -08 was published.

--lyndon

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-crammd5-09.txt 
Date: Tue, 07 Aug 2007 11:15:01 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.

	Title		: The CRAM-MD5 SASL Mechanism
	Author(s)	: L. Nerenberg
	Filename	: draft-ietf-sasl-crammd5-09.txt
	Pages		: 10
	Date		: 2007-8-7
	
This document defines a simple challenge-response authentication
   mechanism, using a keyed MD5 digest, for use with the Simple
   Authentication and Security Layer (SASL).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-09.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-sasl-crammd5-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sasl-crammd5-09.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sasl-crammd5-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sasl-crammd5-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--