Subject: New revision of draft-ietf-sasl-gssapi

From: Alexey Melnikov <[email-masked]>
Date: Tue, 29 Jun 2004 10:36:31 +0100

Version 00 has expired recently. I've submitted -01 which was announced 
today. Only minor tweaks in this version: updated Copyright, clarified 
that authorization id is in UTF-8.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 29 Jun 2004 10:36:31 +0100

Alexey

Date: Tue, 29 Jun 2004 10:36:31 +0100
From: Alexey Melnikov <[email-masked]>
To: SASL WG <[email-masked]>
Subject: New revision of draft-ietf-sasl-gssapi
Sender: [email-masked]

Alexey

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-08.txt
Date: Tue, 29 Jun 2004 15:29:15 -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		: Simple Authentication and Security Layer (SASL)
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-sasl-rfc2222bis-08.txt
	Pages		: 11
	Date		: 2004-6-29
	
The Simple Authentication and Security Layer (SASL) is a framework
   for providing authentication and data security services in
   connection-based protocols. It also describes a structure for
   authentication mechanisms.  The result is an abstraction layer
   between protocols and authentication mechanisms such that any SASL-
   compatible authentication mechanism can be used with any SASL-
   compatible protocol.

   This document describes how a SASL authentication mechanism is
   structured, describes how a protocol adds support for SASL, defines
   the protocol for carrying a security layer over a connection, and
   defines the SASL EXTERNAL authentication mechanism.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-08.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-rfc2222bis-08.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-08.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-08.txt

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-gssapi-01.txt
Date: Mon, 28 Jun 2004 15:35:21 -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		: SASL GSSAPI mechanisms
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-sasl-gssapi-01.txt
	Pages		: 15
	Date		: 2004-6-28
	
The Simple Authentication and Security Layer [SASL] is a method for
adding authentication support to connection-based protocols.  This
document describes the method for using the Generic Security Service
Application Program Interface [GSSAPI] in the Simple Authentication
and Security Layer [SASL].

This document replaces section 7.2 of RFC 2222 [SASL], the definition
of the 'GSSAPI' SASL mechanism.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-gssapi-01.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-gssapi-01.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-gssapi-01.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-gssapi-01.txt

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

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

--OtherAccess--

--NextPart--

Date: Fri, 25 Jun 2004 10:34:23 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: bounces when posting to this list
Sender: [email-masked]

I recently noticed that mail to one of the list
subscribers was being bounced back to poster
(instead of to the list owner... or not at all)
asking the post to click on some URL.  I've sent a
note to this subscriber to fix their problem and
intend to remove the subscriber if their problem
is not soon corrected.

If you noticed such problems, you should feel free
to complain to chairs and/or <[email-masked]>.

Kurt
SASL co-chair 

Date: Fri, 25 Jun 2004 08:30:15 -0700
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Use of NFKC in SASLprep
Cc: [email-masked]
Sender: [email-masked]

At 03:37 AM 6/25/2004, Simon Josefsson wrote:
>>and it is for well-formed.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>I have trouble parsing the last part? 

s/well-formed/well-formed text/

Kurt 

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Use of NFKC in SASLprep
Date: Fri, 25 Jun 2004 12:37:49 +0200
Lines: 34
Cancel-Lock: sha1:0DFje/vO2qsGqLW6ur2X7TenZvI=
Sender: [email-masked]

"Kurt D. Zeilenga" <[email-masked]> writes:

> At 02:45 PM 6/7/2004, Sam Hartman wrote:
>>My presumption is that we go forward assuming that saslprep is
>>idempotent even though we know it is not.  That is, we ignore this
>>issue now and for all future versions of saslprep. 
>
> I have written the following text, replacing the first paragraph
> of the Security Consideration discussion, to make note of the
> issue.
>
>   This profile is intended to used to prepare simple user names and
>   passwords strings for comparison or use in cryptographic functions
>   (e.g., message digests).  The preparation algorithm was specifically
>   designed such that its output is canonical, and it is for well-formed.
                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^

I have trouble parsing the last part?

>   However, due to an anomaly [PR29] in specification of Unicode     
>   normalization, canonical equivalence is not guaranteed for a select
>   few character sequences.  These sequences, however, do not appear  
>   in well-formed text.  This specification was published despite     
>   this known technical problem.  It is expected that this specification
>   will be revised before further progression on the Standards Track               
>   (after [Unicode] and/or [StringPrep] specifications have been updated    
>   to address this problem).
>
> Comments?  Alternative wording?

Otherwise it looks fine to me!

Thanks,
Simon

Date: Thu, 24 Jun 2004 21:02:47 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Use of NFKC in SASLprep
Sender: [email-masked]

At 02:45 PM 6/7/2004, Sam Hartman wrote:
>My presumption is that we go forward assuming that saslprep is
>idempotent even though we know it is not.  That is, we ignore this
>issue now and for all future versions of saslprep. 

I have written the following text, replacing the first paragraph
of the Security Consideration discussion, to make note of the
issue.

  This profile is intended to used to prepare simple user names and
  passwords strings for comparison or use in cryptographic functions
  (e.g., message digests).  The preparation algorithm was specifically
  designed such that its output is canonical, and it is for well-formed.          
  However, due to an anomaly [PR29] in specification of Unicode     
  normalization, canonical equivalence is not guaranteed for a select
  few character sequences.  These sequences, however, do not appear  
  in well-formed text.  This specification was published despite     
  this known technical problem.  It is expected that this specification
  will be revised before further progression on the Standards Track               
  (after [Unicode] and/or [StringPrep] specifications have been updated    
  to address this problem).

Comments?  Alternative wording?

Kurt

Date: Thu, 24 Jun 2004 10:36:28 -0700
From: Paul Romero <[email-masked]>
Organization: RCOM Communications Software
To: [email-masked]
Subject: Validation of SASL/AUTH Features
Sender: [email-masked]

Dear SASL Group:

I need to perform some experiments with AUTH functionality.
Can anybody recommend  ISPs which operate in Northern
California and offer a variety of AUTH features.
My particular interest is CRAM-MD5  without a dial up
connection.

Best Regards,

Paul R.

--
Paul Romero

RCOM Communications Software

Phone/Fax: (510)339-2628
E-Mail: [email-masked]

Date: Tue, 22 Jun 2004 00:00:33 +0100
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: "Kurt D. Zeilenga" <[email-masked]>, Rob Siemborski <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Sender: [email-masked]

Ken Murchison wrote:

> Ken Murchison wrote:
>
>> Kurt D. Zeilenga wrote:
>>
>>> At 11:41 AM 5/21/2004, Rob Siemborski wrote:
>>>
>>>> It also states:
>>>>
>>>> 7.4.  External mechanism
>>>>  The client sends an initial response with the authorization identity.
>>>
>>> Note that it does not say:
>>>         The client may optionally send an initial response with the 
>>> authorization
>>>         identity.
>>>
>>> And, if the client were not to send an initial response, there is no
>>> specified challenge for the server to issue to obtain the authorization
>>> identity.
>>
>> I think the problem here is that the EXTERNAL spec uses the term 
>> "initial response" which is implying that the response can only be 
>> sent with the command which starts the authentication.  My 
>> understanding is that EXTERNAL consists of a single message sent from 
>> client to server which contains the authzid.  If the protocol profile 
>> allows for an initial response and the client chooses to do so, then 
>> the authzid MAY be sent as an initial response.  Otherwise, the 
>> server will send an empty challenge to prompt the client for the 
>> authzid.  Either way, the client MUST provide an authzid.
>
>
> I should have added the following to my last sentence: "which may be 
> empty".

I've changed the paragraph to be:

The client sends a single message containing the UTF-8 encoding of the
authorization identity. The message may be empty. The form of the
authorization identity is further restricted by the application-level
protocol's SASL profile.

Alexey

Date: Mon, 21 Jun 2004 23:51:23 +0100
From: Alexey Melnikov <[email-masked]>
To: SASL WG <[email-masked]>
Subject: Final changes to the base SASL document
Sender: [email-masked]

Rob Siemborski wrote:

>On Fri, 21 May 2004, Sam Hartman wrote:
>  
>
>>    >> It seems we can handle this cleanly enough if we treat it just
>>    >> like the initial response.
>>
>>But is it worth the complexity?  IT seems that if we can avoid the
>>introduction of distinguishing the two cases we should do so.
>>    
>>
>
>If it is not worth the complexity (and, really, I can't think of any
>situation where an empty server success data would be *useful*-- it just
>seems that we'd be giving up some level of flexibility), then we should
>just forbid empty success data -- this would lead to the less confusion
>than attributing two potential meanings to "no success data".
>  
>
Should I treat "forbid empty success data" as the WG consensus on empty 
versa no data on success?

I would like to publish [the last] revision of  the base SASL spec.

Alexey

Date: Fri, 18 Jun 2004 14:06:46 -0700
From: Paul Romero <[email-masked]>
Organization: RCOM Communications Software
To: [email-masked], [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: SMTP/AUTH Software Recommendation
Sender: [email-masked]

Hi Folks:

Could you recommend a stand alone  SMTP CLIENT
software package that satisfies the following criteria ?

* It provides the following AUTH mechanisms in order
 of importance: CRAM-MD5, DIGEST-MD5, and
 GSS API-Kerberos. (i.e. Don't really need TLS.)

* Has an API accessible via C subroutine calls.

* Is independent of TCP/IP connection media--
   modem, ethernet etc.

* Uses a relatively small amount of  memory.

*  Runs on Linux  in user space using only standard
   Linux tools and socket calls, and relies only
   on Linux "inetd" and "pppd".

* Sends E-mail directly to SMTP servers without local
  queuing or additional MTAs.

*  Is ported or can easily be ported to UC Linux.

*  Can accept multiple user data API writes after
   a successful  354 response to the SMTP DATA
  command. (i.e. Streaming E-mail.)

Any comments or insight would be appreciated.

Best Regards,

Paul  R.

--
Paul Romero

RCOM Communications Software

Phone/Fax: (510)339-2628
E-Mail: [email-masked]

Date: Fri, 18 Jun 2004 13:19:32 -0700
From: Paul Romero <[email-masked]>
Organization: RCOM Communications Software
To: [email-masked]
CC: [email-masked]
Subject: LIBESMTPD: E-Mail Client on UC Linux ?
Sender: [email-masked]

Dear Brian and LIBESMTP Aficionados:

I downloaded the Debian version of the libesmtp source code
and can now send E-mail with the sample program--provided
with libesmtp-dev, under the following conditions.
(i.e. My system does not provide an SMTP server.)
The Linux "inetd" has established an Internet connection,
TCP port number 25 is used, and the host--as specified with "-h"--
identifies a system that provides SMTP service. (i.e. I
used symbolic names for the mail servers.) Some seemingly
important modifications were required which are detailed
below--as well as the other significant factors.

My system runs Linux "inetd" over an Ethernet
card, but I suspect this would work with a
modem connection once the IP/PPP to ISP connection
is established with cooperation from Linux
"pppd" and "inetd". Also, I did not actually
try the AUTH capability.

I plan to use my SMTP software to connect directly
to SMTP servers--without additional forwarding or
queuing software--and would like more insight into the following
general  issues: (i.e. My application is an MTA only between
the PC and the ISP SMTP Server--virtually an MUA.)

* Is the libesmtp package described on the website significantly
  different than the Linux version--libesmtp5 and libesmtp-dev ?

* Does libesmtp provide DIGEST-MD5 and GSS API-Kerberos authentication
  as well as CRAM-MD5 ? If not, what are the future plans
  in this respect ?

* Is libesmpt robust enough to handle direct connections to
  SMTP servers--via TCP/IP ? (i.e. Not on my local system.)

* Has libesmtp been ported to UC Linux or would you recommend
  doing so ? (i.e. Memory space is quite limited.)

* Do you know of US ISPs that would allow low cost
  experimentation with the AUTH mechanism ?

* What part of the documentation describes how
  to configure the "secret" etc. as used by
  the CRAM-MD5 variant of AUTH ?

* Would it be difficult to modify the libesmtp
  to facilitate the transmission of streaming E-mail ?
  (i.e. Multiple user data writes after a positive
   354 response to the SMTP DATA command instead
   of retrieving data from a file.)

If you feel that libesmtpd is not appropriate for
the environment I described, can you recommend
another software package ? Finally, the details
I mentioned earlier follow.

Best Regards,

Paul Romero

MODIFICATIONS

The libesmtp-dev software had to be recompiled
and reinstalled with the following modifications
before E-mail could be sent.
had to be set up for a UDP Datagram socket.

* The sample program was modified
pass both the host name and TCP port number 25 to
the lower level software.

* Before calling getaddrinfo() the parameters
had to be set up for a UDP Datagram socket.
(i.e. In protocol.c) The relevant parameters--
mostly in the "hints" structure are as follows:

. Protocol Family: PF_INET
. Socket Type: SOCK_DGRAM
. Protocol: IPPROTO_UDP
. Flags: AI_CANONNAME
(i.e. ai_canonname set to the host name which
is also passed as an argument to getaddrinfo().)

Notes:  The exact details are particular to Debian
but, I suspect they don't vary much on most versions
of Linux. Also, there is only 1 getaddrinfo() call
in the whole file.

* The socket() call to establish a connection
had to be modified to setup up a TCP streaming
socket. (i.e. In protocol.c) The socket() arguments
are as follows:

. domain: PF_INET
. type: SOCK_STREAM
. protocols: 0 (i.e. Mandatory for Debian.)

Note: There is only 1 getaddrinfo() call in
the same file, and I think this will work for
all versions of Linux.

SMTP SOFTWARE

* Standard Debian Version of libesmtp5--version 0.8--and
  libesmtp-dev--Version 8.11--packages.
  (i.e. Downloaded these from the Debian website.)

PROTOCOL SETUP

* Standard Linux & Socket TCP/IP tools.

* IP over LLC2 (i.e. via conventional Linux "inetd")

* Ethernet Card attached to PC Bus and
  connected to Netopia DSL router.

* DSL router uses ADSL and exchanges date
via ATM with the DSLAM at the CO.

HARDWARE ENVIRONMENT

* Normal Intel Based PC

* Ethernet Card

* Netopia DSL Router

OS

* Stock distribute of "Woody" Debian Linux.
  (i.e. Release 2.2.17 )

--
Paul Romero

RCOM Communications Software

Phone/Fax: (510)339-2628
E-Mail: [email-masked]

To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: Use of NFKC in SASLprep
From: Sam Hartman <[email-masked]>
Date: Mon, 07 Jun 2004 17:45:23 -0400
Sender: [email-masked]

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> appears to make SASLPrep2 more complicated to specify
    Simon> (since SASLprep is not idempotent), with consequences for
    Simon> SASL user database migration (if prepared strings are
    Simon> stored in the database, which I have suggested shouldn't be
    Simon> the case in another thread).  

As someone who tends to believe that prepared strings should be stored
in the database, I think it is worth working through the issues of
what we will do with saslprep2 now.

My presumption is that we go forward assuming that saslprep is
idempotent even though we know it is not.  That is, we ignore this
issue now and for all future versions of saslprep.

--Sam

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Use of NFKC in SASLprep
Date: Sun, 06 Jun 2004 12:20:03 +0200
Lines: 25
Cancel-Lock: sha1:RZeeepijxtJ6QM25COpKhxxPWz4=
Sender: [email-masked]

Jeffrey Hutzelman <[email-masked]> writes:

> There is not a problem with NFKC.  There is a TYPO in the document
> which specifies it.  If NFKC is implemented correctly, as is done by
> multiple implementations _including the sample implementation in the
> same document_, there is no problem.

I spoke to other implementors of StringPrep, which do implement NFKC
the same way as the reference implementation (i.e., not according to
the letter of the specification), and one of the Stringprep authors
had told them that then they were simply not following the current
specifications.  I think a public statement committing to one of the
two interpretation (i.e., either consider it a typo in the old version
of NFKC, or that the typo corrected NFKC will be a new version, which
StringPrep doesn't use yet) of this problem would be useful.

> In the meantime, because SASLprep will be used in security-sensitive
> applications including SASL and Kerberos, I think it is appropriate to
> include a reference to PR-29 and a recommendation that implementors
> insure that NFKC is implemented correctly.

We agree about this.

Thanks,
Simon

Date: Sat, 05 Jun 2004 20:39:46 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: Use of NFKC in SASLprep
Sender: [email-masked]

On Saturday, June 05, 2004 14:19:48 +0200 Simon Josefsson <[email-masked]> 
wrote:

> So, what do we have here?  There is a known specification ambiguity in
> NFKC that, for example, appear to allow implementations to return
> three distinct output from the input string U+0B47 U+0300 U+0B3E
> U+0323 (see earlier discussion).  This is an interoperability problem.
> It appears to make SASLPrep2 more complicated to specify (since
> SASLprep is not idempotent), with consequences for SASL user database
> migration (if prepared strings are stored in the database, which I
> have suggested shouldn't be the case in another thread).  It is
> difficult to see that this property is impossible to abuse when
> attacking systems that use SASLprep on authentication/authorization
> tokens.  And the conclusion?  Let's ignore the issue, and make sure it
> is not even mentioned.

It strikes me that people are blowing this way out of proportion, and I 
really dislike the repeated attempts in this working group to "fix" 
Unicode, which is _way way way_ out of scope for us.

There is not a problem with NFKC.  There is a TYPO in the document which 
specifies it.  If NFKC is implemented correctly, as is done by multiple 
implementations _including the sample implementation in the same document_, 
there is no problem.

This is not the end of the world.  We've certainly had similar problems in 
IETF documents; the RFC Editor has a long list of errata for published 
RFC's.  I cannot imagine that the Unicode Consortium will not publish a 
corrigendum to correct the erroneous document.

In the meantime, because SASLprep will be used in security-sensitive 
applications including SASL and Kerberos, I think it is appropriate to 
include a reference to PR-29 and a recommendation that implementors insure 
that NFKC is implemented correctly.

I do _not_ think it is appropriate to suggest behaviour _other_ than simply 
implementing NFKC correctly.  For example, I don't think it's appropriate 
to specify that a large class of sequences be prohibited from output.  Any 
implementation which would be in a position to implement such a suggestion 
is _also_ in a position to get NFKC right in the first place, thereby 
avoiding the entire problem.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Use of NFKC in SASLprep
Date: Sat, 05 Jun 2004 14:19:48 +0200
Lines: 70
Cancel-Lock: sha1:/eeEHBfvkEPyendj6K8TeUuxiQQ=
Sender: [email-masked]

"Kurt D. Zeilenga" <[email-masked]> writes:

> We also had a discussion as to wether the SASLprep I-D should
> note the existence of this issue (without any fix) and its
> impact upon implementations (and use) of SASLprep.  They argued
> that such would be inappropriate for SASLprep I-D to include
> such as there no issue specific to the SASLprep profile of
> Stringprep here.

So, what do we have here?  There is a known specification ambiguity in
NFKC that, for example, appear to allow implementations to return
three distinct output from the input string U+0B47 U+0300 U+0B3E
U+0323 (see earlier discussion).  This is an interoperability problem.
It appears to make SASLPrep2 more complicated to specify (since
SASLprep is not idempotent), with consequences for SASL user database
migration (if prepared strings are stored in the database, which I
have suggested shouldn't be the case in another thread).  It is
difficult to see that this property is impossible to abuse when
attacking systems that use SASLprep on authentication/authorization
tokens.  And the conclusion?  Let's ignore the issue, and make sure it
is not even mentioned.

Speaking as an implementor, I hesitate to expose my users to this
issue.  The conservative approach appear to be to enforce, in the
implementation, a local policy of rejecting the ambiguous input
strings directly.  This remove the need to worry about this issue,
without any obvious negative consequences (correct me if I'm wrong).

Applying the same conservative approach to the specification seem
possible.  The drawback of doing so?  We have to describe how
implementions should detect and reject the ambiguous combination of
code points.  The advantage?  Implementors aren't exposed to
interoperability and security issues.  Further, migrating to SASLprep2
may be simpler since it is more likely to be able to assume SASLprep
is idempotent.

Below is a proposal for this section, and I hope it can be considered.
If the text, or something similar to it, is not adopted, I feel that
at least acknowledging the issue would be appropriate.  The ambiguity
in NFKC doesn't disappear even if you refuse to acknowledge it.

What do other implementors think?  Have you compared the NFKC
implementation you use with the test vectors in PR-29?

Thanks,
Simon

   2.3.1 Prohibited Output Of Problem Sequences

   The algorithm used by [StringPrep] to normalize sequences have been
   discovered [PR-29] to be non-idempotent.  Fortunately, this appear
   to only affect a restricted set of combination of code points, and
   none of those combinations are believed to occur naturally (due to
   different linguistic uses of the characters).  Idempotency of the
   SASLprep operation is important for interoperability, security, and
   migration to revised versions of SASLprep.  Thus, this section
   prohibit the problem sequences from occurring in SASLprep output.
   The logic to detect and prohibit the problem sequences uses the
   tables from [PR-29].

   The problem sequences begin with a code point from one row in
   column 1 of table 1, followed by one or more of the 163 code points
   with a non-zero Canonical Combination Class (see Table 2), followed
   by one of the code points in the same row, in column 2 of Table,
   corresponding to the row of the first code point.

   [Table 1 is table 2 from <http://www.unicode.org/review/pr-29.html>.]

   [Table 2 is the non-zero entries of
   <http://www.unicode.org/Public/3.2-Update/extracted/DerivedCombiningClass-3.2.0.txt>]

Date: Fri, 04 Jun 2004 08:54:54 -0700
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Use of NFKC in SASLprep
Cc: [email-masked]
Sender: [email-masked]

At 04:19 PM 4/22/2004, Simon Josefsson wrote:
>FYI, as SASLprep is using NFKC per Unicode 3.2, you might be
>interested in the NFKC stability problem discussed on
><http://www.unicode.org/review/pr-29.html>. The page mention a
>strategy to maintain stability across NFKC revisions, which might be
>relevant for SASLPrep.  I'd be interested to hear people's opinions on
>the problem.

I recently consulted with authors of [Stringprep] (namely Paul
Hoffman) as well as our liaison to the UTC (Patrik Fältström)
regarding this [SASLprep] concern.  They recommend that the
SASLprep I-D not attempt to fix the issue discussed in PR#29.
They argue (as I understand their arguments) that it would be
inappropriate for SASLprep, a profile of Stringprep, to apply
PR#29 to a version of Unicode instead of utilize Unicode
normalization as required by Stringprep.  Or, to say it in
another way, PR#29 issues in a consistent manner for all profiles
of Stringprep and hence ought to be handled as part of the
ongoing revision of Stringprep (and its normative references).
They suggest we not wait for this revision.

I fully support with their recommendation (which is consistent
with my prior recommendations to the WG).

We also had a discussion as to wether the SASLprep I-D should
note the existence of this issue (without any fix) and its
impact upon implementations (and use) of SASLprep.  They argued
that such would be inappropriate for SASLprep I-D to include
such as there no issue specific to the SASLprep profile of
Stringprep here.  They noted it **might** be appropriate to
publish an Informational RFC updating [Stringprep].

While I have some mild reservations, I can support this
recommendation.

Please consider these recommendations.  Sam (as chair) and I (as
editor) intend to response to the IESG comment regarding
concern within the next week. 

Kurt 

Date: Thu, 03 Jun 2004 10:21:56 -0700
From: Paul Romero <[email-masked]>
Organization: RCOM Communications Software
To: [email-masked], [email-masked]
Subject: Use of AUTH with SMTP
Sender: [email-masked]

Dear SASL User Group

Can anybody provide some insight into the following
questions about how the AUTH mechanism is used
with SMTP ?

1) How commonly deployed is the AUTH mechanism--as
   described in RFC 2554--in commercial ISP SMTP implementations ?

2) Is the CRAM-MD5 variant normally used ?
   If not, which others are commonly used ?

3) Is the AUTH mechanism usually implemented
   on a stand alone basis or in conjunction
   with other service--for instance TLS ?

3.1) If it is implemented with other services,
     what are the relevant RFCs ?

Best Regards,

Paul Romero

--
Paul Romero

RCOM Communications Software

Phone/Fax: (510)339-2628
E-Mail: [email-masked]