Subject: LAST CALL: Simple Authentication and Security Layer (SASL)

From: Tom Yu <[email-masked]>
Date: Wed, 22 Jun 2005 18:26:58 -0400

This begins a Working Group Last Call on submitting the following
document for publication as a Proposed Standard.  The Last Call will
expire at 17:00 EDT on July 8, 2005.

	Title		: Simple Authentication and Security Layer (SASL)
	Author(s)	: A. Melnikov, K. Zeilenga
	Filename	: draft-ietf-sasl-rfc2222bis-11.txt
	Pages		: 29
	Date		: 2005-6-1
	
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-11.txt

In my opinion, there has not been enough review of this document for
me to comfortably declare a WG consensus.  A lack of objections WILL
NOT be sufficient grounds for advancing the document.

If you have read this document and believe that it is ready for
IETF-wide Last Call, please reply indicating so.  Specific positive
comments are particularly encouraged.

If you have not read the document, I urge you to do so and to comment,
especially if your work is affected by the SASL specification.  Please
address all technical comments to the list.

- ---Tom

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 24 Jun 2005 15:21:01 +0200

Hello all,

In general, I think the document is pretty good.  It could use a
re-read, to fix editorial flaws.  I only reviewed my pet problem-area
of SASLprep below.

Section 4, Protocol Requirements:

     Specifications are encouraged to prescribe use of existing
     authorization identity forms as well as existing string
     representations, such as simple user names [RFC4013].  Protocols
     whose authorization identities are simple user names SHOULD use of
     SASLprep [RFC4013] (a profile of the StringPrep [RFC3454]
     preparation algorithm) as their preparation algorithm.

The intention of the requirement appear unclear to me.  For example,
take IMAP or SMTP authentication, with simple username+password.  Is
the intention that the transferred authorization identity should be in
SASLprep:ed form?  If so, I believe it is better to preserve as much
as possible of what the user typed as long as possible.  Having the
client apply SASLprep to the authorization identity would violate
that.

On the other hand, requiring the server to apply SASLprep may be too
expensive.  There are resource-starvation issues to consider here.
Customers are asking for optimized versions of my StringPrep
implementation to be able to use it in a server.

If the above requirement is going to be present, I believe it should
either be clear on what is intended, or acknowledge that it is meant
to be fuzzy and that is leaves things open.  To me, I get the
impression that it is meant to be fuzzy.  Adopting parts of the
following paragraph, from Mechanism Requirements, would acknowledge
that the fuzziness is intended, and that protocol specifications must
clarify the details.  What do you think?

  In order to avoid interoperability problems due to differing
  normalizations, when a mechanism calls for character data is to be
  used as input to a cryptographic and/or comparison function, the
  specification MUST detail precisely how and where (client or server)
  the character data is to be prepared, including all normalizations,
  for input into the function to ensure proper operation.

Also, there is a typo, s/SHOULD use of/SHOULD use/.

Section 5, Mechanism Requirements:

  The mechanism SHOULD NOT use the authorization identity string in
  generation of any long-term cryptographic keys or hashes as there is
  no requirement that the authorization identity string be be
  non-canonical.

I might be picking words here, but 'non-canonical'?  Shouldn't that be
'canonical'?  Even so, if I understand correctly, what is intended is
that one user may have different authorization identities in different
protocols, and that is why mechanisms shouldn't use the authorization
identities as input to hash functions etc.  If so, I don't think
"canonical" is a good word here, since one protocol's authzid is as
good as another protocol's authzid.  There is no "canonical" authzid
to speak of.

Also, there is a typo, s/be be/to be/.

Cheers,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 24 Jun 2005 15:21:01 +0200

Hello all,

Cheers,
Simon

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: LAST CALL: Simple Authentication and Security Layer (SASL)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 24 Jun 2005 15:21:01 +0200
Sender: [email-masked]

Hello all,

Cheers,
Simon

To: [email-masked]
Subject: LAST CALL: Simple Authentication and Security Layer (SASL)
From: Tom Yu <[email-masked]>
Date: Wed, 22 Jun 2005 18:26:58 -0400
Lines: 27
Sender: [email-masked]

	

- ---Tom

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-11.txt
Date: Wed, 01 Jun 2005 16:08:00 -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.

The Simple Authentication and Security Layer (SASL) is a framework for
  providing authentication and data security services in
  connection-oriented protocols via replaceable mechanisms.  It provides
  a structured interface between protocols and mechanisms.  The
  resulting framework allows new protocols to reuse existing mechanisms
  and allows old protocols to make use of new mechanisms.  The framework
  also provides a protocol for securing subsequent protocol exchanges
  within a data security layer.

  This document describes how a SASL mechanism is structured, describes
  how protocols include support for SASL, and defines the protocol for
  carrying a data security layer over a connection.  Additionally, this
  document defines one SASL mechanism, the EXTERNAL mechanism.

  This document obsoletes RFC 2222.

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-rfc2222bis-11.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-rfc2222bis-11.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-rfc2222bis-11.txt

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

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

--OtherAccess--

--NextPart--