Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-04.txt

From: [email-masked]
Date: Tue, 23 Dec 2003 15:35:43 -0500

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-04.txt
	Pages		: 11
	Date		: 2003-12-23
	
SASL provides a method for adding authentication support with an
optional security layer to 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, how a protocol adds support for SASL, defines the
protocol for carrying a security layer over a connection, and defines
the EXTERNAL SASL authentication mechanism.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-04.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-04.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.

---

From: Rob Siemborski <[email-masked]>
Date: Mon, 29 Dec 2003 15:48:20 -0500 (EST)

> 	Title		: Simple Authentication and Security Layer (SASL)

Nit:  Document states that it will be a draft standard, is this still the
case or is the stringprep stuff forcing us to recycle at proposed?

I've sent additional editorial isses to Alexey, but nothing that should
hold up the document.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 29 Dec 2003 13:34:47 -0800

>case or is the stringprep stuff forcing us to recycle at proposed?

We'll be recycling at Proposed.

>I've sent additional editorial isses to Alexey, but nothing that should

Thanks, Kurt

---

From: Rob Siemborski <[email-masked]>
Date: Mon, 29 Dec 2003 15:48:20 -0500 (EST)

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 29 Dec 2003 13:34:47 -0800

Thanks, Kurt 

Date: Mon, 29 Dec 2003 13:34:47 -0800
To: Rob Siemborski <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-04.txt
Cc: [email-masked]
Sender: [email-masked]

Thanks, Kurt 

Date: Mon, 29 Dec 2003 15:48:20 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-04.txt
Sender: [email-masked]

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-04.txt
Date: Tue, 23 Dec 2003 15:35:43 -0500
Sender: [email-masked]

--NextPart

	

Send a message to:
	[email-masked].
In the body type:

--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-04.txt

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

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

--OtherAccess--

--NextPart--

Date: Mon, 15 Dec 2003 12:12:08 -0800
To: Rob Siemborski <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Moving to rfc2222bis last call
Cc: [email-masked]
Sender: [email-masked]

At 11:41 AM 12/15/2003, Rob Siemborski wrote:

>On Mon, 1 Dec 2003, Sam Hartman wrote:
>
>> What are we still waiting on before the next last call of this
>> document?
>
>I just noticed that the EXTERNAL mechanism doesn't have any limits on how
>big the client response can be.
>
>Are servers expected to handle responses of arbitrary length here,

I assume they should be able to 'handle' (not choke) authzid of
any length but can refuse to accept any authzid for any reason
(including it just being unreasonably long).

>or can
>they get away with saying "we don't support authorization identifiers
>longer than x"?

They just generally should fail the exchange if the asserted
authzid is too long (whatever that means to them).  Of course,
if the server believes the client to be rouge, it can (and
likely should) just drop the protocol steam.

I do not think we should impose any artificial limit here
as reasonable lengths.  Where absolutely needed, they should
be stated in application-level profiles (as they own the
form of the authzid).

Kurt 

Date: Mon, 15 Dec 2003 12:00:24 -0800
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: ANONYMOUS
Cc: Hallvard B Furuseth <[email-masked]>, [email-masked]
Sender: [email-masked]

At 11:13 AM 12/15/2003, Sam Hartman wrote:
>>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:
>
>
>    Kurt> As this is a security consideration, not an implementation
>    Kurt> imperative nor applicability statement, I believe 'should'
>    Kurt> is more appropriate than 'SHOULD'.  
>
>I don't much care but how is this particular security consideration
>not an implementation imperative justified for security reasons?

My primary concern is not to give this 'should' special
attention over the many other 'should' statements in
the Security Considerations section AND not to litter
the Security Considerations section with lots of SHOULDs.
SHOULDs should be used sparingly.

I think the current wording is fine.  The section discusses
security considerations.  If, however, people think that
we need to state specific implementation imperatives in
this area, I suggest those be added to Section 1 and the
Security Considerations section be left to just discussing
considerations.

Kurt 

Date: Mon, 15 Dec 2003 14:41:17 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: Re: Moving to rfc2222bis last call
Sender: [email-masked]

On Mon, 1 Dec 2003, Sam Hartman wrote:

> What are we still waiting on before the next last call of this
> document?

I just noticed that the EXTERNAL mechanism doesn't have any limits on how
big the client response can be.

Are servers expected to handle responses of arbitrary length here, or can
they get away with saying "we don't support authorization identifiers
longer than x"?

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
------END GEEK CODE BLOCK-----

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: ANONYMOUS
From: Sam Hartman <[email-masked]>
Date: Mon, 15 Dec 2003 14:13:11 -0500
Sender: [email-masked]

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

    Kurt> As this is a security consideration, not an implementation
    Kurt> imperative nor applicability statement, I believe 'should'
    Kurt> is more appropriate than 'SHOULD'.  

I don't much care but how is this particular security consideration
not an implementation imperative justified for security reasons?

Date: Mon, 15 Dec 2003 11:09:01 -0800
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: ANONYMOUS
Cc: Hallvard B Furuseth <[email-masked]>, [email-masked]
Sender: [email-masked]

At 10:20 AM 12/15/2003, Sam Hartman wrote:

>>>>>> "Hallvard" == Hallvard B Furuseth <[email-masked]> writes:
>
>    Hallvard> [anon] section 4 (Security Considerations) says:
>
>    >> The ANONYMOUS mechanism grants access to information by anyone.
>    >> For this reason it should be disabled by default so the
>    >> administrator can make an explicit decision to enable it.
>
>    Hallvard> I disagree.  I see no reason to disable ANONYMOUS as
>    Hallvard> long as ANONYMOUS 'authentication' is treated as
>    Hallvard> equivalent to no authentication rather than e.g. as
>    Hallvard> authentication with a password.  What is needed is a
>    Hallvard> securicy consideration that ANONYMOUS must not (or MUST
>    Hallvard> NOT?) be enabled unless it is treated specially in this
>    Hallvard> respect.
>
>I think a SHOULD is sufficient.  If your application/environment has
>well defined no authentication semantics, then you have a
>justification for violating the SHOULD.  Write it up in your
>docs/specifications, explain what behavior you have and why you chose
>it and go on with life.

As this is a security consideration, not an implementation imperative
nor applicability statement,  I believe 'should' is more appropriate
than 'SHOULD'.   But same basic logic applies here.  Implementors
should consider the implications before enabling ANONYMOUS by
default.

From: Hallvard B Furuseth <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: ANONYMOUS
Date: Mon, 15 Dec 2003 19:28:44 +0100
Sender: [email-masked]

Sam Hartman writes:
>>>>>> "Hallvard" == Hallvard B Furuseth <[email-masked]> writes:
> 
>     Hallvard> What is needed is a
>     Hallvard> securicy consideration that ANONYMOUS must not (or MUST
>     Hallvard> NOT?) be enabled unless it is treated specially in this
>     Hallvard> respect.
> 
> I think a SHOULD is sufficient.  (...)

OK.

BTW, would it help to specify that ANONYMOUS gives the specified
authentication ID, but a null authorization ID?

-- 
Hallvard

To: Hallvard B Furuseth <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Moving to rfc2222bis last call
From: Sam Hartman <[email-masked]>
Date: Mon, 15 Dec 2003 13:22:00 -0500
Sender: [email-masked]

>>>>> "Hallvard" == Hallvard B Furuseth <[email-masked]> writes:

    Hallvard> I can't offer any suggestions because I don't know what
    Hallvard> belongs there.  I think what I'm really missing is a
    Hallvard> description of the purpose of the protocol profile.
    Hallvard> What will it be used for?  What is it _not_ intended to
    Hallvard> be used for?  Knowing that, the reader (and I) can judge
    Hallvard> for himself what should go in it, besides the mandatory
    Hallvard> items.

Does anyone else feel this issue requires additional clarification?

To: Hallvard B Furuseth <[email-masked]>
Cc: [email-masked]
Subject: Re: ANONYMOUS
From: Sam Hartman <[email-masked]>
Date: Mon, 15 Dec 2003 13:20:08 -0500
Sender: [email-masked]

>>>>> "Hallvard" == Hallvard B Furuseth <[email-masked]> writes:

    Hallvard> [anon] section 4 (Security Considerations) says:

    >> The ANONYMOUS mechanism grants access to information by anyone.
    >> For this reason it should be disabled by default so the
    >> administrator can make an explicit decision to enable it.

    Hallvard> I disagree.  I see no reason to disable ANONYMOUS as
    Hallvard> long as ANONYMOUS 'authentication' is treated as
    Hallvard> equivalent to no authentication rather than e.g. as
    Hallvard> authentication with a password.  What is needed is a
    Hallvard> securicy consideration that ANONYMOUS must not (or MUST
    Hallvard> NOT?) be enabled unless it is treated specially in this
    Hallvard> respect.

I think a SHOULD is sufficient.  If your application/environment has
well defined no authentication semantics, then you have a
justification for violating the SHOULD.  Write it up in your
docs/specifications, explain what behavior you have and why you chose
it and go on with life.

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: ANONYMOUS
Date: Mon, 15 Dec 2003 12:03:13 +0100
Sender: [email-masked]

[anon] section 4 (Security Considerations) says:

>  The ANONYMOUS mechanism grants access to information by anyone.  For
>  this reason it should be disabled by default so the administrator can
>  make an explicit decision to enable it.

I disagree.  I see no reason to disable ANONYMOUS as long as ANONYMOUS
'authentication' is treated as equivalent to no authentication rather
than e.g. as authentication with a password.  What is needed is a
securicy consideration that ANONYMOUS must not (or MUST NOT?) be enabled
unless it is treated specially in this respect.

If anon is treated as no auth, some other security considerations
disappear too, since they are no different from if the user did not
authenticate:

>  If the anonymous user has any write privileges, a denial of service
>  attack is possible by filling up all available space.  This can be
>  prevented by disabling all write access by anonymous users.

>  If anonymous users have read and write access to the same area, the
>  server can be used as a communication mechanism to anonymously
>  exchange information.  (...)

>  If the anonymous user can run many expensive operations (e.g., an IMAP
>  SEARCH BODY command), this could enable a denial of service attack.

>  While servers may impose a limit on the number of anonymous users, it
>  is noted that such limits enable denial of service attacks and should
>  be used with caution.

Also,

>  Anonymous connections are susceptible to man in the middle attacks
>  which view or alter the data transferred.  Clients and servers are
>  encouraged to support external integrity and encryption mechanisms.

It's not that the connection is anonymous which makes it suspectible,
but that [anon] provides no SASL security layer.

Also, in an earlier thread, I wrote:
>Alexey Melnikov writes:
>>Kurt D. Zeilenga wrote:
>>>At 04:45 PM 11/5/2003, Hallvard B Furuseth wrote:
>>>
>>>> Looking over the various SASL drafts, I miss one piece of functionality:
>>>> To authenticate anonymously, removing any SASL layer, but still
>>>> providing an unauthenticated ID (e.g. for logging purposes).
>>>> 
>> How is this different from ANONYMOUS (except for @ sign requirement).
> 
> That's the difference.  If there is nothing special about the '@'
> character in the underlying auth IDs, then the exclusion of names with
> '@' in them is unnatural.  Though one could of course introduce a
> private hack like using \ for a quote character and type @ as \40, or
> something.

That reminds me:

Would it be appropriate to put something like this in [anon]?

   A protocol using the ANONYMOUS mechanism may impose additional syntax
   on <message>, e.g. it may say that the NUL, '@' and '\' characters
   are to be encoded as '\00', '\40' and '\5C' respectively in <token> -
   thus allowing such tokens to encode all characters.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: Moving to rfc2222bis last call
Date: Mon, 15 Dec 2003 10:56:00 +0100
Sender: [email-masked]

Alexey Melnikov writes:
>> Subject: Re: rfc2222bis: protocol profile?
>> From: Hallvard B Furuseth <[email-masked]>
>> Date: Mon, 10 Nov 2003 08:10:22 +0100
>> Message-Id: <[email-masked]>
>> URL: http://www.imc.org/ietf-sasl/mail-archive/msg01304.html
>>
>> What belongs in the protocol profile?
>
> I will ignore this one, unless you have a specific suggestion/text.
> I am not sure I can give you a generic future proof advice.

I can't offer any suggestions because I don't know what belongs there.
I think what I'm really missing is a description of the purpose of the
protocol profile.  What will it be used for?  What is it _not_ intended
to be used for?  Knowing that, the reader (and I) can judge for himself
what should go in it, besides the mandatory items.

>> The 'selects no security layer' thread.  I've lost track of this one and
>> will have to reread it.  But originally all I wanted was to clarify that
>> specific phrase: either to 'does not select a security layer' or
>> 'selects that there shall be no security layer', or whatever else is
>> meant.  That has not been done yet.
>  
> I think I've addressed the particular issue by saying that mechanism 
> that are incapable of negotiating a security layer always select "no layer".

OK, if the quotes are in place, or otherwise the new wording can't be
interpreted as "doesn't select a (new) layer".

-- 
Hallvard

Date: Sun, 14 Dec 2003 16:13:15 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: Moving to rfc2222bis last call
Sender: [email-masked]

Hallvard B Furuseth wrote:

>Sam Hartman writes:
>  
>
>>What are we still waiting on before the next last call of this
>>document?
>>    
>>
>
>I think this document needs another version before it is ready for last
>call.  Here is the unfinished business I'm aware of:
>
>------------------------------------------------------------------------
>
>The 'suggested text about multiple SASL mechanisms' thread.
>  
>
I think this is done.

<some issues skipped, will reply to them separately>

>------------------------------------------------------------------------
>
>Subject: Re: rfc2222bis: protocol profile?
>From: Hallvard B Furuseth <[email-masked]>
>Date: Mon, 10 Nov 2003 08:10:22 +0100
>Message-Id: <[email-masked]>
>URL: http://www.imc.org/ietf-sasl/mail-archive/msg01304.html
>
>What belongs in the protocol profile?
>  
>
I will ignore this one, unless you have a specific suggestion/text.
I am not sure I can give you a generic future proof advice.

>------------------------------------------------------------------------
>
>Subject: draft-ietf-sasl-rfc2222bis-02.txt section 4.2
>From: Tony Hansen <[email-masked]>
>Date: Thu, 06 Nov 2003 12:02:22 -0500
>Message-ID: <[email-masked]>
>URL: http://www.imc.org/ietf-sasl/mail-archive/msg01278.html
>
>Split section 4.2 (Authorization identities and proxy authentication).
>It appears to be mixing two totally different discussions together in a
>slightly confusing mess.
>
This is done. I had to merge my recent changes with the proposed text.

>------------------------------------------------------------------------
>
>The 'selects no security layer' thread.  I've lost track of this one and
>will have to reread it.  But originally all I wanted was to clarify that
>specific phrase: either to 'does not select a security layer' or
>'selects that there shall be no security layer', or whatever else is
>meant.  That has not been done yet.
>  
>
I think I've addressed the particular issue by saying that mechanism 
that are incapable of negotiating a security layer always select "no layer".

Alexey
__________________________________________

Isode Limited, http://www.isode.com

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html __________________________________________

Date: Mon, 08 Dec 2003 00:44:59 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>
cc: Jeffrey Hutzelman <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-sasl-crammd5-01.txt
Sender: [email-masked]

On Sunday, December 07, 2003 05:30:47 +0100 Simon Josefsson 
<[email-masked]> wrote:

> Jeffrey Hutzelman <[email-masked]> writes:
>
>> On Wednesday, December 03, 2003 19:56:03 +0100 Simon Josefsson
>> <[email-masked]> wrote:
>>
>>> I don't see a conflict with this and the text I proposed, but I'm not
>>> sure if you argue for or against the text.  In fact, the problem of
>>> forward compatible databases was the motivation for my text.  The text
>>> would help if SASLPrepX(SASLPrep(string)) != SASLPrepX(string) where
>>> SASLPrepX is any future revision of SASLPrep.
>>
>> Yeah; that's supposed to be a guarantee.  Part of this is spelled out
>> in RFC2454, at the end of section 3 and in section 7.1:
>>
>>    Authors of profiles of this document need to consider the effects of
>>    changing the mapping of any currently-assigned character when
>>    updating their profiles.  Adding a new mapping for a currently-
>>    assigned character, or changing an existing mapping, could cause a
>>    variance between the behavior of systems that have been updated and
>>    systems that have not been updated.
>
> This is not much of a guarantee.  To me, the wording suggest that
> stringprep profiles actually can be backwards incompatible, if the
> designers feel the benefits outweigh the costs that are mentioned.

Yes, I believe that's exactly what it says.  It may not seem like much of a 
guarantee, but it's the best we can possibly have.  Designers of future 
versions of a profile will always be able to break backward compatibility, 
no matter what we do -- no "requirement" we write now can be effective 
against an IETF concensus in the future.

>>    A subsequent version of a profile that references a newer version of
>>    a repertoire with new code points will inherently have some code
>>    points move from category U to either D, MN, or AO.  For backwards
>>    compatibility, a subsequent version of a profile MUST NOT move code
>>    points from any other category.  That is, current AO, MN, or D code
>>    points MUST NOT ever change to a different category.
>
> This is good text, and I thought it would take of this problem.
> However, it doesn't appear to be that simple, because it continue to
> say:
>
>    Applications creating queries MUST treat U code points as if they
>    were AO when preparing the query to be entered in the process
>    described by a profile of stringprep.  Those applications MAY
>    optionally have a preprocessor that provide stricter checks: treating
>    unassigned code points in the input as errors, or warning the user
>    about the fact that the code point is unassigned in the version of a
>    profile that the software is based on; such a choice is a local
>    matter for the software.
>
> So the result is that if the profile is used with AllowUnassigned set
> to true, the computed strings are not necessarily forwards compatible.

That is correct - if you apply stringprep with AllowUnassigned set to TRUE, 
there is no guarantee that two implementations will produce the same result 
given the same input.  But that's OK for a query string that's going to be 
used "once", right now -- the worst thing that can happen is that it 
doesn't match when it "should".

However, for a string that's going to be stored long-term, preparing it 
incorrectly now is fatal; it will then _NEVER_ match a correctly prepared 
string.  If there are unassigned code points, then you can't know if you're 
preparing it correctly; the easiest solution to this problem is to raise an 
exception now, and refuse to store a string if you don't know how to 
prepare it correctly.  That's what setting AllowUnassigned to FALSE does. 
So I'll go back to my original statement -- IF a server is going to prepare 
strings in advance (which it cannot avoid if it's going to precompute a 
partial MD5 context), then it MUST set AllowUnassigned to FALSE and reject 
strings which contain unassigned code points.

> Furthermore, one of the three ways forward presented in
> draft-faltstrom-unicode-synchronisation-00, to support new Unicode
> versions, include breaking backwards compatibility in stringprep
> profiles.

I've not had a chance to read that document yet, so I can't comment on it.

> To summarize, I don't believe the SASLPrep2(SASLPrep1(string)) ==
> SASLPrep2(string) guarantee hold universally, nor follow from the core
> document.
>
> This problem can be solved by adding a discussion in the SASLPrep
> document that contain some guarantee that will hold for future
> versions of the SASLPrep profile.  Perhaps even explicitly mention
> which path in draft-faltstrom-unicode-synchronisation-00 SASLPrep will
> follow.

We can't make an effective guarantee against a future IETF concensus.  But 
given the text in RFC2454, I do agree we need to address the issue, and 
express the intent that the mappings of code points not in class U will not 
change in future versions of the specification.

> Alternatively, you could recommend applications to store the
> unprepared original passwords, which will be safe regardless of what
> SASLPrep will behave in the future.  I prefer this approach, but
> judging from the responses to my proposed text for CRAM-MD5, perhaps
> there isn't consensus about that.

I get the impression that people like the idea of storing a partial MD5 
context, even though doing so doesn't offer much protection.  If servers 
are going to do this, I think they should be REQUIRED to prepare with 
AllowUnassigned set FALSE.  OTOH, if they're going to store passwords, I 
agree that storing unprepared passwords allows for the greatest chance of 
future interoperability.

> Finally, each mechanism using SASLPrep should also say when and how
> AllowUnassigned is set.

Absolutely.

-- Jeff

To: Jeffrey Hutzelman <[email-masked]>
Cc: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-sasl-crammd5-01.txt
From: Simon Josefsson <[email-masked]>
Date: Sun, 07 Dec 2003 05:30:47 +0100
Sender: [email-masked]

Jeffrey Hutzelman <[email-masked]> writes:

> On Wednesday, December 03, 2003 19:56:03 +0100 Simon Josefsson
> <[email-masked]> wrote:
>
>> I don't see a conflict with this and the text I proposed, but I'm not
>> sure if you argue for or against the text.  In fact, the problem of
>> forward compatible databases was the motivation for my text.  The text
>> would help if SASLPrepX(SASLPrep(string)) != SASLPrepX(string) where
>> SASLPrepX is any future revision of SASLPrep.
>
> Yeah; that's supposed to be a guarantee.  Part of this is spelled out
> in RFC2454, at the end of section 3 and in section 7.1:
>
>    Authors of profiles of this document need to consider the effects of
>    changing the mapping of any currently-assigned character when
>    updating their profiles.  Adding a new mapping for a currently-
>    assigned character, or changing an existing mapping, could cause a
>    variance between the behavior of systems that have been updated and
>    systems that have not been updated.

This is not much of a guarantee.  To me, the wording suggest that
stringprep profiles actually can be backwards incompatible, if the
designers feel the benefits outweigh the costs that are mentioned.

>    A subsequent version of a profile that references a newer version of
>    a repertoire with new code points will inherently have some code
>    points move from category U to either D, MN, or AO.  For backwards
>    compatibility, a subsequent version of a profile MUST NOT move code
>    points from any other category.  That is, current AO, MN, or D code
>    points MUST NOT ever change to a different category.

This is good text, and I thought it would take of this problem.
However, it doesn't appear to be that simple, because it continue to
say:

   Applications creating queries MUST treat U code points as if they
   were AO when preparing the query to be entered in the process
   described by a profile of stringprep.  Those applications MAY
   optionally have a preprocessor that provide stricter checks: treating
   unassigned code points in the input as errors, or warning the user
   about the fact that the code point is unassigned in the version of a
   profile that the software is based on; such a choice is a local
   matter for the software.

So the result is that if the profile is used with AllowUnassigned set
to true, the computed strings are not necessarily forwards compatible.

Furthermore, one of the three ways forward presented in
draft-faltstrom-unicode-synchronisation-00, to support new Unicode
versions, include breaking backwards compatibility in stringprep
profiles.

To summarize, I don't believe the SASLPrep2(SASLPrep1(string)) ==
SASLPrep2(string) guarantee hold universally, nor follow from the core
document.

This problem can be solved by adding a discussion in the SASLPrep
document that contain some guarantee that will hold for future
versions of the SASLPrep profile.  Perhaps even explicitly mention
which path in draft-faltstrom-unicode-synchronisation-00 SASLPrep will
follow.

Alternatively, you could recommend applications to store the
unprepared original passwords, which will be safe regardless of what
SASLPrep will behave in the future.  I prefer this approach, but
judging from the responses to my proposed text for CRAM-MD5, perhaps
there isn't consensus about that.

Finally, each mechanism using SASLPrep should also say when and how
AllowUnassigned is set.

Thanks,
Simon

Date: Fri, 05 Dec 2003 21:09:20 -0800
To: "Sebastian Petrescu" <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: sasl + pam : ietf-sasl
Cc: [email-masked]
Sender: [email-masked]

Sebastian,

Your post is off-topic.  This list is reserved for discussions
related to the standardization of SASL.  Your post would more
appropriately be directed to list specific to the software you
are using.  It appears you are using Cyrus SASL, hence I suggest
you direct your enquiry to <cyrus-sasl@<mailto:[email-masked]>lists.andrew.cmu.edu>.

Kurt, IETF SASL WG Co-chair

At 08:32 PM 12/5/2003, Sebastian Petrescu wrote:
>    Hello.
>    I do have a problem. I'm trying to install postfix + sasl with pam support.
>saslauthd -v
>saslauthd 2.1.17
>authentication mechanisms: getpwent rimap shadow
>
>I do have pam installed on my system .. and I'v vonfigured sasl:
>./configure --prefix=3D/usr --enable-anon --enable-plain --enable-login --disable-krb4 --with-pam --with-saslauthd=3D/var/run/saslauthd =
>--with-plugindir=3D/usr/lib/sasl2 --libdir=3D/usr/lib/sasl2 =
>--with-plugindir=3D/usr/lib/sasl2 |grep pam
>
>configure: WARNING: Disabling GSSAPI - no include files found
>configure: running /bin/sh './configure' --prefix=3D/usr/local  '--enable-anon' '--enable-plain' '--enable-login' '--disable-krb4' '--with-saslauthd=3D/var/run/saslauthd' '--libdir=3D/usr/lib/sasl2' '--with-plugindir=3D/usr/lib/sasl2' '--with-pam=3D/lib/security' --cache-file=3D.././config.cache --srcdir=3D.
>configure: WARNING: Disabling GSSAPI - no include files found
>checking for pam_start in -lpam... (cached) no
>
>
>I do have pam installed.. I have recompiled pam and installed latest libraries.
>
>    Can someone please give me a hint ?

Date: Fri, 05 Dec 2003 20:32:43 -0800
To: [email-masked]
From: "Sebastian Petrescu" <[email-masked]>
Subject: sasl + pam : ietf-sasl
Sender: [email-masked]

    Hello.
    I do have a problem. I'm trying to install postfix + sasl with pam support.
saslauthd -v
saslauthd 2.1.17
authentication mechanisms: getpwent rimap shadow

I do have pam installed on my system .. and I'v vonfigured sasl:
./configure --prefix=3D/usr --enable-anon --enable-plain --enable-login --disable-krb4 --with-pam --with-saslauthd=3D/var/run/saslauthd =
--with-plugindir=3D/usr/lib/sasl2 --libdir=3D/usr/lib/sasl2 =
--with-plugindir=3D/usr/lib/sasl2 |grep pam

configure: WARNING: Disabling GSSAPI - no include files found
configure: running /bin/sh './configure' --prefix=3D/usr/local  '--enable-anon' '--enable-plain' '--enable-login' '--disable-krb4' '--with-saslauthd=3D/var/run/saslauthd' '--libdir=3D/usr/lib/sasl2' '--with-plugindir=3D/usr/lib/sasl2' '--with-pam=3D/lib/security' --cache-file=3D.././config.cache --srcdir=3D.
configure: WARNING: Disabling GSSAPI - no include files found
checking for pam_start in -lpam... (cached) no

I do have pam installed.. I have recompiled pam and installed latest libraries.

    Can someone please give me a hint ?

To: Lyndon Nerenberg <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-sasl-crammd5-01.txt
From: Sam Hartman <[email-masked]>
Date: Fri, 05 Dec 2003 11:14:38 -0500
Sender: [email-masked]

>>>>> "Lyndon" == Lyndon Nerenberg <[email-masked]> writes:

    Lyndon> I'm having no luck coming up with text that explains this
    Lyndon> clearly. And I'm still not convinced that this should be
    Lyndon> discussed in the mechanism spec, since it applies much
    Lyndon> more widely than just CRAM. 2222bis seems to me to be a
    Lyndon> better place to lay this out.

I disagree.  How to prepare authentication identities is entirely a
mechanism matter.  The base spec can point out the general concern but
cannot constrain what the mechanism does.

For example various GSSAPI mechanisms may do much more complicated
stringprep.  Kerberos certainly will.

Date: Fri, 05 Dec 2003 12:19:23 +0000
From: Alexey Melnikov <[email-masked]>
To: Sam Hartman <[email-masked]>
CC: [email-masked]
Subject: Re: Moving to rfc2222bis last call
Sender: [email-masked]

Sam Hartman wrote:

>What are we still waiting on before the next last call of this
>document?
>
Rob's assessment is right.
I also need to work on some issues raised by Hallvard.

I am a bit busy at the moment. I will try to push a new revision in a 
week or so.

Alexey

Date: Thu, 04 Dec 2003 19:07:19 -0800
From: Lyndon Nerenberg <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>, Simon Josefsson <[email-masked]>
cc: [email-masked]
Subject: Re: draft-ietf-sasl-crammd5-01.txt
Sender: [email-masked]

--On Wednesday, December 3, 2003 1:05 PM -0800 "Kurt D. Zeilenga" 
<[email-masked]> wrote:

> The client copy of the user name and shared secret should
> be defined as query strings and, hence, unassigned code points
> are allowed to appear in the prepared output.  The server
> copy of the user name and shared secret should be viewed
> as stored strings and, hence, unassigned code points are not
> allowed to appear in the prepared output.
>
> The draft needs to be revised to make this clear.

I'm having no luck coming up with text that explains this clearly. And 
I'm still not convinced that this should be discussed in the mechanism 
spec, since it applies much more widely than just CRAM. 2222bis seems 
to me to be a better place to lay this out.

That said, I have to rev the CRAM draft again for other (editorial) 
reasons, so if someone can come up with a diff to -01 I'll incorporate 
it. (Or is Kurt's paragraph above clear enough?)

--lyndon

Date: Thu, 04 Dec 2003 18:21:45 -0800
From: Lyndon Nerenberg <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
Subject: Re: PLAIN examples
Sender: [email-masked]

> C: Jane<NUL>John<NUL>xipj3plmq

I would change Jane and John to something not quite so similar, just to 
make the distinction more obvious.

--lyndon

Date: Thu, 04 Dec 2003 11:12:35 -0800
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Proposed new slate of milestones for SASL WG
Sender: [email-masked]

The chairs propose updating our slate of milestones to:

Done	Submit revised SASL (+ EXTERNAL) I-D 
Done	Submit revised SASL ANONYMOUS I-D 
Done	Submit revised SASL PLAIN I-D 
Done	Submit revised SASL CRAM-MD5 I-D 
Done	Submit revised SASL DIGEST-MD5 I-D 
Done	Submit revised SASL GSSAPI I-D 
Jan 04	Submit SASL (+ EXTERNAL), SASLprep, ANONYMOUS, PLAIN to IESG
	for consideration as Proposed Standards
Feb 04	Submit CRAM-MD5 to IESG for consideration as a Proposed Standard
Mar 04	Submit DIGEST-MD5 to IESG for consideration as a Proposed Standard
May 04	Submit GSSAPI to IESG for consideration as a Proposed Standard
Jun 04 Provide implementation report plan (with milestones)
Aug 04	Revise charter or conclude 

Note that the milestone dates are basically those suggested
at IETF#58 but slipped a month or so.

Note as well that this slate calls for all of the revised
SASL specifications, including the rfc2222bis I-D, to be
recycled at Proposed.  This is mainly due to the
introduction of SASLprep (which even the rfc2222bis I-D
normatively references).

If you have comments/concerns regarding this slate, please
post them within the next week or so.  The chairs plan on
making a decision regarding what slate of milestones to
progressed to our AD by 19th of this month.

Kurt, SASL WG co-chair

Date: Wed, 03 Dec 2003 18:37:13 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>, Sam Hartman <[email-masked]>
cc: [email-masked]
Subject: Re: draft-ietf-sasl-crammd5-01.txt
Sender: [email-masked]

On Wednesday, December 03, 2003 19:56:03 +0100 Simon Josefsson 
<[email-masked]> wrote:

> I don't see a conflict with this and the text I proposed, but I'm not
> sure if you argue for or against the text.  In fact, the problem of
> forward compatible databases was the motivation for my text.  The text
> would help if SASLPrepX(SASLPrep(string)) != SASLPrepX(string) where
> SASLPrepX is any future revision of SASLPrep.

Yeah; that's supposed to be a guarantee.  Part of this is spelled out in 
RFC2454, at the end of section 3 and in section 7.1:

   Authors of profiles of this document need to consider the effects of
   changing the mapping of any currently-assigned character when
   updating their profiles.  Adding a new mapping for a currently-
   assigned character, or changing an existing mapping, could cause a
   variance between the behavior of systems that have been updated and
   systems that have not been updated.

   A subsequent version of a profile that references a newer version of
   a repertoire with new code points will inherently have some code
   points move from category U to either D, MN, or AO.  For backwards
   compatibility, a subsequent version of a profile MUST NOT move code
   points from any other category.  That is, current AO, MN, or D code
   points MUST NOT ever change to a different category.

The rest comes from Unicode itself, which guarantees that normalizations 
for existing code points will not change.  Sadly, it appears the UTC has 
been willing to violate that guarantee in some cases.

> This is not the only interpretation.  It is possible to consider the
> SASL library to be performing a query against the HMAC-MD5 oracle to
> decide whether a Unicode string the library received from the
> application (possibly ultimately from a database), after the library
> has prepared it with SASLPrep with AllowUnassigned set to true, is the
> same secret used by the client.

This critical issue is that for servers where a partial MD5 context is 
stored based on the shared secret, the secret MUST first be prepared 
according to SASLprep.  In this case, the secret needs to be treated as a 
storage string -- there's no way to reverse the context establishment, so 
if the string was not normalized correctly to begin with, you can't go back 
and fix it when you upgrade.  Thus, unassigned code points MUST NOT be 
permitted in such a case.

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

>
>>> If the answer is yes, I don't agree, because that would make CRAM-MD5
>>> reject passwords containing characters introduced by Unicode 4.0.0.
>>
>> As intended!   Until stringprep is updated to detail how these
>> newly assigned code points are to be handled, we need to exclude
>> them from appearing in the "stored" password string.
>
> The behaviour of inputting Unicode 4.0.0 characters should still be
> well defined.  The current text say nothing about what the server
> should do, so rejecting the input isn't the only alternative.
>
> Thanks,
> Simon
>
>
>

Date: Wed, 03 Dec 2003 15:35:04 -0800
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: PLAIN examples
Sender: [email-masked]

Here are the updated examples section:

This section provides examples of PLAIN authentication exchanges.
The examples are intended to help the readers understand the above
text.  The examples are not definitive.

"C:" and "S:" indicate lines sent by the client and server respectively.
"<NUL>" represents a single NUL (U+0000) character.  The Application
Configuration Access Protocol ([ACAP]) is used in the examples.

The first example shows how the PLAIN mechanism might be used for
user authentication.

S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
C: a001 STARTTLS
S: a001 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "CRAM-MD5" "PLAIN")
C: a002 AUTHENTICATE "PLAIN"
S: + ""
C: {21}
C: <NUL>tim<NUL>tanstaaftanstaaf
S: a002 OK "Authenticated"           

The second example shows how the PLAIN mechanism might be used to
assuming the identity of another user.  In this example, the server
rejects the request.  Also, this example makes use of the protocol
optional initial response capability to eliminate a round-trip.

S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
C: a001 STARTTLS
S: a001 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "CRAM-MD5" "PLAIN")
C: a002 AUTHENTICATE "PLAIN" {19+}
C: Jane<NUL>John<NUL>xipj3plmq              
S: a002 NO "Not authorized to assume asserted identity" 

Date: Wed, 03 Dec 2003 14:27:23 -0800
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: PLAIN and unassigned characters (Was: draft-ietf-sasl-crammd5-01.txt)
Sender: [email-masked]

In consideration of the on-going CRAM-MD5 unassigned code point
discussions, I reviewed draft-ietf-sasl-plain-xx.txt handling
in this area and found that a few additional words would add
clarity in this area.

Hence, I'd like to make the following change:
@@ -151,10 +151,12 @@
 The presented authentication identity and password strings are not
 to be compared directly with stored strings.  The server SHALL first
 prepare authentication identity and password strings using the
 [SASLPrep] profile of the [StringPrep] algorithm.
+Per Section 7 of [StringPrep], unassigned code points may appear in
+prepared presented (query) strings but are prohibited in stored strings.
 If preparation fails or results in an empty string, verification SHALL
 fail.  If the server stores only the hash of expected string, the
 string MUST be prepared before generation of the hash.

(+ indicates new text)

Additionally (as previously discussed), I'll update the pseudo
code such that SASLprep() takes a second argument as follows:

+The second parameter of the SASLprep function, when true, indicates
+that the input string is a "query" string [StringPrep] and, hence,
+unassigned code points are allowed.  When the SASLprep function is
+called to prepared the password prior to computing the stored hash,
+the second parameter would be false as unassigned code points are
+not allowed in "stored strings" [StringPrep].

Kurt

At 01:05 PM 12/3/2003, Kurt D. Zeilenga wrote:

>At 10:56 AM 12/3/2003, Simon Josefsson wrote:
>>"Kurt D. Zeilenga" <[email-masked]> writes:
>>
>>> In each of the password-based mechanisms (PLAIN, CRAM-MD5,
>>> DIGEST-MD5, etc.), the user provided string is clear a "query"
>>> string and the string which it is compared against (directly
>>> or indirectly) is a "stored" string (regardless of whether
>>> the server stores it locally or in some external systems).
>>
>>This is not the only interpretation.  It is possible to consider the
>>SASL library to be performing a query against the HMAC-MD5 oracle to
>>decide whether a Unicode string the library received from the
>>application (possibly ultimately from a database), after the library
>>has prepared it with SASLPrep with AllowUnassigned set to true, is the
>>same secret used by the client.
>
>Well, maybe the language I used was not clear enough.
>
>My point is that the mechanism specification must clearly
>state which strings are query strings and which strings are
>stored strings and ensure that two query strings prepared
>by different implementations are not (directly or indirectly)
>compared.
>
>The client copy of the user name and shared secret should
>be defined as query strings and, hence, unassigned code points
>are allowed to appear in the prepared output.  The server
>copy of the user name and shared secret should be viewed
>as stored strings and, hence, unassigned code points are not
>allowed to appear in the prepared output.
>
>The draft needs to be revised to make this clear.
>
>Kurt  

Date: Wed, 3 Dec 2003 16:36:33 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Sam Hartman <[email-masked]>
cc: [email-masked]
Subject: Re: Moving to rfc2222bis last call
Sender: [email-masked]

On Mon, 1 Dec 2003, Sam Hartman wrote:

> What are we still waiting on before the next last call of this
> document?

>From the minutes, we need to see an updated security considerations
section (for the MITM attack), and we need examples for the initial client
response and server last sends.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
------END GEEK CODE BLOCK-----

Date: Wed, 03 Dec 2003 13:05:45 -0800
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: draft-ietf-sasl-crammd5-01.txt
Cc: Sam Hartman <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked]
Sender: [email-masked]

At 10:56 AM 12/3/2003, Simon Josefsson wrote:
>"Kurt D. Zeilenga" <[email-masked]> writes:
>
>> In each of the password-based mechanisms (PLAIN, CRAM-MD5,
>> DIGEST-MD5, etc.), the user provided string is clear a "query"
>> string and the string which it is compared against (directly
>> or indirectly) is a "stored" string (regardless of whether
>> the server stores it locally or in some external systems).
>
>This is not the only interpretation.  It is possible to consider the
>SASL library to be performing a query against the HMAC-MD5 oracle to
>decide whether a Unicode string the library received from the
>application (possibly ultimately from a database), after the library
>has prepared it with SASLPrep with AllowUnassigned set to true, is the
>same secret used by the client.

Well, maybe the language I used was not clear enough.

My point is that the mechanism specification must clearly
state which strings are query strings and which strings are
stored strings and ensure that two query strings prepared
by different implementations are not (directly or indirectly)
compared.

The client copy of the user name and shared secret should
be defined as query strings and, hence, unassigned code points
are allowed to appear in the prepared output.  The server
copy of the user name and shared secret should be viewed
as stored strings and, hence, unassigned code points are not
allowed to appear in the prepared output.

The draft needs to be revised to make this clear.

Kurt  

To: Simon Josefsson <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-sasl-crammd5-01.txt
From: Sam Hartman <[email-masked]>
Date: Wed, 03 Dec 2003 15:36:37 -0500
Sender: [email-masked]

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

    Simon> Sam Hartman <[email-masked]> writes:
    >>>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
    >>
    Simon> I'm sorry to be dense, but can you be more specific?  I
    Simon> thought future stringprep profiles were allowed to use
    Simon> Unicode 4.0.0, including the correct normalization tables,
    Simon> but if SASLPrep2 would do so, the above guarantee doesn't
    Simon> hold.
    >>  The problem here being that normalization changed between 3.2
    >> and 4.0 in incompatible ways?

    Simon> That's one example of the problem, yes.  In general, I
    Simon> didn't find any guarantee that a future version of a
    Simon> stringprep profile must be backwards compatible to the
    Simon> previous version.  For SASLPrep, that could be useful, but
    Simon> I haven't found any place that say it must be so.  If there
    Simon> isn't, storing the unprepared string in databases appear to
    Simon> be the safe recommendation.  (It might be anyway, if the
    Simon> database is shared with other password infrastructures that
    Simon> doesn't use SASLPrep, but that's besides the point.)

It's my understanding that the entire IETF internationalization
architecture as it depends on stringprep depends on this guarantee.
Sort of unfortunate that it is not stated.

To: Sam Hartman <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-sasl-crammd5-01.txt
From: Simon Josefsson <[email-masked]>
Date: Wed, 03 Dec 2003 21:34:08 +0100
Sender: [email-masked]

Sam Hartman <[email-masked]> writes:

>>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
>
>
>     Simon> I'm sorry to be dense, but can you be more specific?  I
>     Simon> thought future stringprep profiles were allowed to use
>     Simon> Unicode 4.0.0, including the correct normalization tables,
>     Simon> but if SASLPrep2 would do so, the above guarantee doesn't
>     Simon> hold.
>
> The problem here being that normalization changed between 3.2 and 4.0
> in incompatible ways?

That's one example of the problem, yes.  In general, I didn't find any
guarantee that a future version of a stringprep profile must be
backwards compatible to the previous version.  For SASLPrep, that
could be useful, but I haven't found any place that say it must be so.
If there isn't, storing the unprepared string in databases appear to
be the safe recommendation.  (It might be anyway, if the database is
shared with other password infrastructures that doesn't use SASLPrep,
but that's besides the point.)

Thanks,
Simon

To: Simon Josefsson <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-sasl-crammd5-01.txt
From: Sam Hartman <[email-masked]>
Date: Wed, 03 Dec 2003 14:43:29 -0500
Sender: [email-masked]

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

    Simon> I'm sorry to be dense, but can you be more specific?  I
    Simon> thought future stringprep profiles were allowed to use
    Simon> Unicode 4.0.0, including the correct normalization tables,
    Simon> but if SASLPrep2 would do so, the above guarantee doesn't
    Simon> hold.

The problem here being that normalization changed between 3.2 and 4.0
in incompatible ways?

Well, that's sort of an open issue within the IETF because that wasn't
supposed to happen.  Stringprep assumes normalization never changes;
we assume that future versions of stringprep onlly change in handling
of unassigned codepoints.  Unicode has created a mess for us and we
have not decided how to deal.

To: Sam Hartman <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-sasl-crammd5-01.txt
From: Simon Josefsson <[email-masked]>
Date: Wed, 03 Dec 2003 20:35:33 +0100
Sender: [email-masked]

Sam Hartman <[email-masked]> writes:

>>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
>
>     Simon> If SASLPrepX is guaranteed to behave the same as SASLPrep
>     Simon> for currently assigned characters, there is no problem in
>     Simon> storing SASLPrep prepared strings in the database, and my
>     Simon> text is incorrect.  However, in that case, I believe the
>     Simon> guarantee that SASLPrepX(SASLPrep(string)) =
>     Simon> SASLPrepX(string) should be stated in the SASLPrep
>     Simon> document.
>
> I believe this guarantee is stated in stringprep.

I'm sorry to be dense, but can you be more specific?  I thought future
stringprep profiles were allowed to use Unicode 4.0.0, including the
correct normalization tables, but if SASLPrep2 would do so, the above
guarantee doesn't hold.

Thanks,
Simon

To: Simon Josefsson <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-sasl-crammd5-01.txt
From: Sam Hartman <[email-masked]>
Date: Wed, 03 Dec 2003 14:17:39 -0500
Sender: [email-masked]

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

    Simon> If SASLPrepX is guaranteed to behave the same as SASLPrep
    Simon> for currently assigned characters, there is no problem in
    Simon> storing SASLPrep prepared strings in the database, and my
    Simon> text is incorrect.  However, in that case, I believe the
    Simon> guarantee that SASLPrepX(SASLPrep(string)) =
    Simon> SASLPrepX(string) should be stated in the SASLPrep
    Simon> document.

I believe this guarantee is stated in stringprep.

To: [email-masked]
Subject: Draft Minutes for SASL working group meeting
From: Sam Hartman <[email-masked]>
Date: Wed, 03 Dec 2003 14:08:52 -0500
Sender: [email-masked]

Please comment; I'll submit at the end of the week or the proceedings
deadline, whichever is sooner.

From: Philip Guenther <[email-masked]>

               Minutes  for IETF 58 SASL Working Group

scribe: Philip Guenther
[email-masked]

chairs: Sam Hartman <[email-masked]>, Kurt Zeilenga <[email-masked]>

agenda change:
- add short discussion of  private-use characters in saslprep

status of drafts:
- base-spec last call was not discussed in previous meeting, but it has
  been last called since then
- saslprep has been last called, but generated no comments at that time.
  fullstop issue arose after that
- Alexey taking on editorship of gssapi mech draft
- digests and cram-md5 updated to support stringprep
- plain mech to be clarified.  When applying saslprep, is a query string
  or a stored string, as that affects unassigned characters
  - example to be added showing no initial first reply
  - example to be added showing non-empty authorization ID
  - example to be added showing failure vs success
  - *not* to clarify SMTP usage or use SMTP instead of ACAP

Rob Siemborski (speaking for Alexey):
- 2222bis:
  - discussion of attack if the security layer is *not* dropped on
    reauthentication:
    - attack:
      - client authenticates to realm A (monitored by B)
      - reauthenticates to realm B w/o dropping the layer
      - realm B server now has an oracle on the confidentiality layer
    - the chairs noted that the risk of attack is related to the trust
      relationships in the server setup
    - poll of room re: how to handle
      - 15 to zero in favor of documenting in the security
        considerations and not altering the SASL requirement
      - the option of leaving it up to the protocol profile was
        considered by some to be an even worse choice due to the extra
	complexity it introduces.
    - will be taken to list for confirmation of consensus
  - consider adding text: client should check to verify that a MITM attack
    didn't remove mechanisms from the list by checking after 
    - believed to be resolved with careful wording

Kurt:
- last call on saslprep draft
  - fullstop issue
    - some discussion on list
    - Ienup Sung <[email-masked]> presents: why fullstop != .
      - defs from unicode:
	- U+002E defined not just as period but also for decimals
	- U+3002 has U+002E as reference, not equivalence
	- U+FF0E (fullwidth period) *is* equivalent to U+002E
	- NFKC reflects this
      - ideographics stops are *only* used in text, not as decimal point
        (this is stricter in Japan and China than in Korea)
      - ergo: they should only be in the same equivalence class for internet
	style domain names (IDNA) and *not* in saslprep
      - <demonstration of japanese input method showing how the same
        keystroke generates different characters cased oin context>
      - comments [confusing to follow]
	- Jeff Altman:
	  - wording by Ienup seems to be that decimal *can* be used in text
	  - therefore, *should* do mapping because users might not be able to
	    control it
	- Marc Crispin:Please provide an example of a real world
          situation where this is a problem. 
	- Paul Hoffman:
	  - if you believe that normal names that will be used in sasl
	    will include periods that will be used in context-sensitive
	    ways, then do not to the mapping
	- Ienup:
	  - feels that parens vs bracket in english is an analogous situations
	- Jeff Altman:
	  - no, saslprep shouldn't always do the mapping; but that mechs
	    should overide that for saslprep usages that specify things
	    like domain-name-like items
	- Marc Crispin:
	  - does not seem credibile that the mapping is necessary
	  - wants credible example
	- Nico Williams:
          - felt that credible example was given, thinks that it
            may be a UI issue
  - private-use characters
    - suggestion by Jeff Altman that private-use char restriction should
      be removed and replaced with discussion of usages and lack
      of interoperability
    - characters not yet in unicode from previous charsets including
      experimental and those in internal use in corps
    - ?would require normalization of private-use characters?
    - Ienup:
      - saslprep prohibits them
	- some text cannot be entered without these
      - there is some need, understand problems and issues
	need to make clear that this is limited use
    - Kurt:
      - cannot just drop prohibition because too much is defined privately
    - chair: show of hands to go forward with even considering
      - 4 hands for
      - 5 hands against
    - Michel:
      - extremely bad idea
      - no semantic defined
      - not stable
	- even inside same organization, different usages may exist
      - no temporal stability
    - Paul Hoffman:
      - all that, plus, this is for identifiers and password only
	- name that requires private use character is  unlikely
  - will be taken back to the list
- Rob: SMTP AUTH
  - proposal to add initial response to IMAP
  - issue is in the rfcs, it's just not clear
  - new pop3 and smtp profile drafts
    - cleanup, add examples, fill in gaps
    - especially cases showing failing to send initial response
  - consensus on list was to *not* change examples in sasl plain from
    ACAP to SMTP 
  - examples of initial client response and server last challenge
    *will* be added to rfc2222bis
- WG wrap up
  - milestones
    - GSSAPI I-D is still missing, Alexey says new version should be out
      by end of November
    - implementation report to be pushed out because recycling at proposed
      - (or maybe not?  chairs to discuss); base may not need recycling
    - base is ready for last call
    - plain has minor tweaks, needs last call
    - anonymous is ready
    - saslprep has minor issues
    - cram-md5 and digest-md5 need a little more work before last call
      Alexey has dealt with CBC issues but missed cut-off before meeting
    - base, plain, anonymous, and saslprep before end of year
    - digest + cram shortly thereafter
    - gssapi by, say, May?
  - Bob Morgan
    - FYI: OASIS has interest in defining a SASL mech doing single-sign-on
      expect note to mailing list

To: Sam Hartman <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-sasl-crammd5-01.txt
From: Simon Josefsson <[email-masked]>
Date: Wed, 03 Dec 2003 19:56:03 +0100
Sender: [email-masked]

Sam Hartman <[email-masked]> writes:

> I mean that this should be a requirement for interoperability in the
> long term.  If you don't have this requirement, then you may run into
> cases where saslprep eventually maps out those characters in the
> future.
>
> Basically, if we require allowunassigned to be false, we guarantee
> future interoperability at the cost of refusing to allow people to use
> unassigned characters until saslprep is updated.

I don't see a conflict with this and the text I proposed, but I'm not
sure if you argue for or against the text.  In fact, the problem of
forward compatible databases was the motivation for my text.  The text
would help if SASLPrepX(SASLPrep(string)) != SASLPrepX(string) where
SASLPrepX is any future revision of SASLPrep.

If SASLPrepX is guaranteed to behave the same as SASLPrep for
currently assigned characters, there is no problem in storing SASLPrep
prepared strings in the database, and my text is incorrect.  However,
in that case, I believe the guarantee that SASLPrepX(SASLPrep(string))
= SASLPrepX(string) should be stated in the SASLPrep document.

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

> In each of the password-based mechanisms (PLAIN, CRAM-MD5,
> DIGEST-MD5, etc.), the user provided string is clear a "query"
> string and the string which it is compared against (directly
> or indirectly) is a "stored" string (regardless of whether
> the server stores it locally or in some external systems).

This is not the only interpretation.  It is possible to consider the
SASL library to be performing a query against the HMAC-MD5 oracle to
decide whether a Unicode string the library received from the
application (possibly ultimately from a database), after the library
has prepared it with SASLPrep with AllowUnassigned set to true, is the
same secret used by the client.

>>If the answer is yes, I don't agree, because that would make CRAM-MD5
>>reject passwords containing characters introduced by Unicode 4.0.0. 
>
> As intended!   Until stringprep is updated to detail how these
> newly assigned code points are to be handled, we need to exclude
> them from appearing in the "stored" password string.

The behaviour of inputting Unicode 4.0.0 characters should still be
well defined.  The current text say nothing about what the server
should do, so rejecting the input isn't the only alternative.

Thanks,
Simon

To: Simon Josefsson <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-sasl-crammd5-01.txt
From: Sam Hartman <[email-masked]>
Date: Wed, 03 Dec 2003 12:21:28 -0500
Sender: [email-masked]

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

    Simon> I'm having trouble understanding what these statements
    Simon> imply for the protocol.  Perhaps my trouble is because the
    Simon> discussion is now focused on the database, and not on the
    Simon> protocol.

    Simon> Do you mean that servers will be _required_ to use
    Simon> passwords prepared with AllowUnassigned false in the
    Simon> HMAC-MD5 computation?

I mean that this should be a requirement for interoperability in the
long term.  If you don't have this requirement, then you may run into
cases where saslprep eventually maps out those characters in the
future.

Basically, if we require allowunassigned to be false, we guarantee
future interoperability at the cost of refusing to allow people to use
unassigned characters until saslprep is updated.

Date: Tue, 02 Dec 2003 20:09:44 -0800
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: draft-ietf-sasl-crammd5-01.txt
Cc: [email-masked]
Sender: [email-masked]

At 04:21 PM 12/2/2003, Simon Josefsson wrote:
> Regardless of whether the prepared string is ever stored in a
> database?

First, I think "in a database" is a unnecessary qualification.
All that matters is that it is a "stored" string per stringprep.

In each of the password-based mechanisms (PLAIN, CRAM-MD5,
DIGEST-MD5, etc.), the user provided string is clear a "query"
string and the string which it is compared against (directly
or indirectly) is a "stored" string (regardless of whether
the server stores it locally or in some external systems).

> Perhaps my trouble is because the discussion is now focused
> on the database, and not on the protocol.

I do think that it should be considered an implementation detail
whether the server applies SASLprep with unassigned disallowed
before or after use storage.  What matters to the protocol/algorithm
is the server apply the SASLprep with disallowed before comparison
to the "stored" string.  Generally, doing it before storage is
more appropriate.  However, there is no harm (and there may be
advantage in some instances (e.g., external password stores))
of doing it after fetching it from storage (BUT before comparison).

So, maybe we're agreeing...

>If the answer is yes, I don't agree, because that would make CRAM-MD5
>reject passwords containing characters introduced by Unicode 4.0.0. 

As intended!   Until stringprep is updated to detail how these
newly assigned code points are to be handled, we need to exclude
them from appearing in the "stored" password string.

Kurt

To: Sam Hartman <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-sasl-crammd5-01.txt
From: Simon Josefsson <[email-masked]>
Date: Wed, 03 Dec 2003 01:21:04 +0100
Sender: [email-masked]

Sam Hartman <[email-masked]> writes:

>>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:
>
>     Jeffrey> The correct way to handle this situation is to require
>     Jeffrey> that if the server stores the prepared string (or maybe,
>     Jeffrey> even if not), the server prepare the string with
>     Jeffrey> AllowUnassigned set to FALSE, thereby prohibiting
>     Jeffrey> unassigned code points.  If the server stores the
>     Jeffrey> prepared string, then it is properly a "storage string"
>     Jeffrey> and should not be permitted to contain unassigned code
>     Jeffrey> points.
>
>
> I agree.  I believe cram-md5 should always treat the secret as a
> storage string when it is updating its database.

I'm having trouble understanding what these statements imply for the
protocol.  Perhaps my trouble is because the discussion is now focused
on the database, and not on the protocol.

Do you mean that servers will be _required_ to use passwords prepared
with AllowUnassigned false in the HMAC-MD5 computation?

Regardless of whether the prepared string is ever stored in a
database?

If the answer is yes, I don't agree, because that would make CRAM-MD5
reject passwords containing characters introduced by Unicode 4.0.0.

Regards,
Simon

PS. Forward compatibility issues with StringPrep profiles are
discussed in the recent draft-faltstrom-unicode-synchronisation-00.

To: Jeffrey Hutzelman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-sasl-crammd5-01.txt
From: Sam Hartman <[email-masked]>
Date: Tue, 02 Dec 2003 14:31:20 -0500
Sender: [email-masked]

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> The correct way to handle this situation is to require
    Jeffrey> that if the server stores the prepared string (or maybe,
    Jeffrey> even if not), the server prepare the string with
    Jeffrey> AllowUnassigned set to FALSE, thereby prohibiting
    Jeffrey> unassigned code points.  If the server stores the
    Jeffrey> prepared string, then it is properly a "storage string"
    Jeffrey> and should not be permitted to contain unassigned code
    Jeffrey> points.

I agree.  I believe cram-md5 should always treat the secret as a
storage string when it is updating its database.

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked] (Sam Hartman)
Cc: [email-masked]
Subject: Re: Moving to rfc2222bis last call
Date: Tue, 2 Dec 2003 10:20:55 +0100
Sender: [email-masked]

Sam Hartman writes:
> What are we still waiting on before the next last call of this
> document?

I think this document needs another version before it is ready for last
call.  Here is the unfinished business I'm aware of:

------------------------------------------------------------------------

The 'suggested text about multiple SASL mechanisms' thread.

------------------------------------------------------------------------

Subject: [Fwd: Keeping/dropping existing SASL security layer]
From: Alexey Melnikov <[email-masked]>
Date: Tue, 11 Nov 2003 20:35:01 +0000
Message-ID: <[email-masked]>
URL: http://www.imc.org/ietf-sasl/mail-archive/msg01312.html

Alexey's attack when keeping an old security layer.  He sent it to Rob
and me before the list, and I replied that I still did not understand,
with a list of where I got lost.

------------------------------------------------------------------------

Subject: Re: rfc2222bis: re-negotiating SASL security layer
From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 11 Nov 2003 22:24:45 +0100
Message-Id: <[email-masked]>
URL: http://www.imc.org/ietf-sasl/mail-archive/msg01313.html

When can a security layer be removed?  What I said in this message seems
to reflect what Alexey said last, but I don't quite think that's what he
meant...

------------------------------------------------------------------------

Subject: Re: rfc2222bis: protocol profile?
From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 10 Nov 2003 08:10:22 +0100
Message-Id: <[email-masked]>
URL: http://www.imc.org/ietf-sasl/mail-archive/msg01304.html

What belongs in the protocol profile?

------------------------------------------------------------------------

Subject: draft-ietf-sasl-rfc2222bis-02.txt section 4.2
From: Tony Hansen <[email-masked]>
Date: Thu, 06 Nov 2003 12:02:22 -0500
Message-ID: <[email-masked]>
URL: http://www.imc.org/ietf-sasl/mail-archive/msg01278.html

Split section 4.2 (Authorization identities and proxy authentication).
It appears to be mixing two totally different discussions together in a
slightly confusing mess.

------------------------------------------------------------------------

The 'selects no security layer' thread.  I've lost track of this one and
will have to reread it.  But originally all I wanted was to clarify that
specific phrase: either to 'does not select a security layer' or
'selects that there shall be no security layer', or whatever else is
meant.  That has not been done yet.

------------------------------------------------------------------------

-- 
Hallvard

Date: Mon, 01 Dec 2003 18:05:02 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-sasl-crammd5-01.txt
Sender: [email-masked]

On Monday, December 01, 2003 23:39:51 +0100 Simon Josefsson 
<[email-masked]> wrote:

> I suggest adding:
>
>       The server MUST prepare the shared secret string using the
>       [SASLPrep] profile of the [StringPrep] algorithm.  The resulting
>       value MUST be encoded as UTF-8 [UTF8].  The server may store the
>       prepared string instead of, or as well as, the unprepared
>       string, so that it does not have to prepare it every time it is
>       needed for computation.  However, if the original, unprepared
>       string, is not stored, it may render the computed secret to be
>       incompatible with a future revisions of SASLPrep that support
>       currently unassigned code points (compare section 7 of
>       [StringPrep]).  It is therefor recommended to store the
>       unprepared string in the database.

The correct way to handle this situation is to require that if the server 
stores the prepared string (or maybe, even if not), the server prepare the 
string with AllowUnassigned set to FALSE, thereby prohibiting unassigned 
code points.  If the server stores the prepared string, then it is properly 
a "storage string" and should not be permitted to contain unassigned code 
points.

-- 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]
Subject: draft-ietf-sasl-crammd5-01.txt
From: Simon Josefsson <[email-masked]>
Date: Mon, 01 Dec 2003 23:39:51 +0100
Sender: [email-masked]

Hello, I have read the document.  Some comments:

,----
|      The client MUST prepare the user name and shared secret strings
|      using the [SASLPrep] profile of the [StringPrep] algorithm.  The
|      resulting values MUST be encoded as UTF-8 [UTF8].
`----

I suggest adding:

      The server MUST prepare the shared secret string using the
      [SASLPrep] profile of the [StringPrep] algorithm.  The resulting
      value MUST be encoded as UTF-8 [UTF8].  The server may store the
      prepared string instead of, or as well as, the unprepared
      string, so that it does not have to prepare it every time it is
      needed for computation.  However, if the original, unprepared
      string, is not stored, it may render the computed secret to be
      incompatible with a future revisions of SASLPrep that support
      currently unassigned code points (compare section 7 of
      [StringPrep]).  It is therefor recommended to store the
      unprepared string in the database.

Also, the example section is incorrect.  Suggested new version:

     S: * OK [CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED AUTH=CRAM-MD5]
     C: A0001 AUTHENTICATE CRAM-MD5
     S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UuZXhhbXBsZS5uZXQ+
     C: am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3
     S: A0001 OK CRAM-MD5 authentication successful

     In this example, the shared secret is the string

          tanstaaftanstaaf

     Hence, the Keyed MD5 digest is produced by calculating

          MD5((tanstaaftanstaaf XOR opad),
               MD5((tanstaaftanstaaf XOR ipad),
               <[email-masked]>))

     where ipad and opad are as defined in [KEYED-MD5] and the string
     shown in the challenge is the base64 encoding of
     <[email-masked]>. The shared secret is
     null-padded to a length of 64 bytes. If the shared secret is longer
     than 64 bytes, the MD5 digest of the shared secret is used as a 16
     byte input to the keyed MD5 calculation.

     This produces a digest value (in hexadecimal) of

          3dbc88f0624776a737b39093f6eb6427

     The user name is then prepended to it, forming

          joe 3dbc88f0624776a737b39093f6eb6427

     Which is then base64 encoded to meet the requirements of the IMAP4
     AUTHENTICATE command (or the similar POP3 AUTH command), yielding

          am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3

Perhaps it would be useful to add an example for non-ASCII strings
too, using <U+4711> or similar to indicate non-ASCII characters.

Thanks,
Simon

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Rob Siemborski <[email-masked]>, Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms
From: Sam Hartman <[email-masked]>
Date: Mon, 01 Dec 2003 17:06:44 -0500
Sender: [email-masked]

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

    Kurt> At 07:16 PM 11/14/2003, Sam Hartman wrote:
    >> One thing we need to keep in mind is that over time, we get a
    >> better idea of what best practices for using SASL are.

    Kurt> My operational experiences with LDAP show that making
    Kurt> available a list of mechanisms post authentication isn't the
    Kurt> "best" practice for preventing MITM downgrade attacks.

    Kurt> I think the "best" practice is for the client and server to
    Kurt> have policy which states what the levels of service are or
    Kurt> are not acceptable (and when).  A simple mechanism can just
    Kurt> dictate minimum levels and refuse when not met.  A more
    Kurt> complex mechanism could have two levels, minimum and
    Kurt> recommend, where less than recommended but higher than
    Kurt> minimum required user authorization.

We all agree this is sufficient.

However I believe that IETF experience with other security protocols
strongly favors having a way to detect downgrades when possible.

The problem is that in practice, people tend to establish fairly loose
policies on their clients, so in situations where it is possible to
detect the downgrade it is a good idea to do so.

I agree there is not significant experience with this in the SASL
community, but I believe there is sufficient experience in the SASL
community to say that client policies do tend to be fairly lax and
experience in the rest of the IETF to say that downgrade detection is
desirable.

I believe that is sufficient to provide advice for new protocols.

Date: Mon, 01 Dec 2003 13:47:40 -0800
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms
Cc: Rob Siemborski <[email-masked]>, Hallvard B Furuseth <[email-masked]>, [email-masked]
Sender: [email-masked]

At 07:16 PM 11/14/2003, Sam Hartman wrote:
>One thing we need to keep in mind is that over time, we get a better
>idea of what best practices for using SASL are.

My operational experiences with LDAP show that making available a
list of mechanisms post authentication isn't the "best" practice
for preventing MITM downgrade attacks.

I think the "best" practice is for the client and server to have
policy which states what the levels of service are or are not
acceptable (and when).  A simple mechanism can just dictate minimum
levels and refuse when not met.  A more complex mechanism could
have two levels, minimum and recommend, where less than recommended
but higher than minimum required user authorization.

I think the list mechanism approach in LDAP is a bit problematic.
First, SASL (or other) security layers may not have been established
making the information subject to MITM attack.  Second, LDAP allows
the list of mechanisms to change based upon current availability
(to this client).  It is possible that a stronger mechanism is,
for legitimate reasons, no longer available.  It is not possible
for the client to deduce why a change in the listing was made.  A
more workable approach would be to recommend the server provide
a list of mechanisms which WERE available to the client when it
authenticated to the server.  Lastly, the list doesn't prevent
any similar MITM attacks (for example, downgrading of the
cipher suites used by a listed mechanism).

I also note that I have yet to find a client which actually uses
the list of available mechanisms to detect MITM attacks.  Clients
which do attempt to detect such attacks tend to use a policy based
mechanism.

In short, I don't think we have enough good operational experience
to add these imperatives to the technical specification.

Kurt 

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-crammd5-01.txt
Date: Mon, 01 Dec 2003 15:30:46 -0500
Sender: [email-masked]

--NextPart

	Title		: The CRAM-MD5 SASL Mechanism
	Author(s)	: L. Nerenberg
	Filename	: draft-ietf-sasl-crammd5-01.txt
	Pages		: 7
	Date		: 2003-12-1
	
This document defines a simple challenge-response authentication
mechanism, using a keyed-hash 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-01.txt

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-01.txt".

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sasl-crammd5-01.txt".

--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-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sasl-crammd5-01.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]
Subject: Moving to rfc2222bis last call
Date: Mon,  1 Dec 2003 12:44:09 -0500 (EST)
From: [email-masked] (Sam Hartman)
Sender: [email-masked]

What are we still waiting on before the next last call of this
document?