Subject: Re: SASLPrep vs Full Stop code points

From: Ienup Sung <[email-masked]>
Date: Fri, 31 Oct 2003 17:42:56 -0800 (PST)

Regarding the full stops, while I do understand the point of display vs.
storage/query string in my opinion, I think the issue boils down onto
the followign two things in my view:

1. Should/can we treat ideographic/Asian full stops as equivalent characters
   of the ASCII full stop (U+002E) in 100% of the possible cases/usages?
   The answer is no since the U+002E is not only a full stop character but
   it is also a period and dot/decimal point character; CJK speakers do not use
   the ideographic/Asian full stops as the dot/decimal point character and
   hence some use of the ideographic/Asian full stops rather be preserved as
   they are to be distingushed. And in that cases, can we distinguish what to
   preserve and what not to preserve and map?

2. Should/can we keep the compatiblity with the IDNA's additional and
   pre-processing on the label separators, i.e., mappings of all full stops to
   the U+002E, for the domain style (IDN) names before they are used?
   I think the answer should be yes.

I know the above two sound conflicting and the example shown at the argument
#1 could be considered as a case that may not need to be really supported.
But I thought presenting them might be a valuable thing to do.

With regards,

Ienup

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 31 Oct 2003 20:52:15 -0800

>   of the ASCII full stop (U+002E) in 100% of the possible cases/usages?

SASLprep is only applicable to two use cases: simple user names and password.

>   preserve and what not to preserve and map?

SASLprep scope is limited to preparation of user input strings for matching.
Issues such as how to preserving the (unprepared) user input is simply beyond
our scope as matching and hence SASLprep.

>   I think the answer should be yes.

SASLprep can define one preparation algorithm for simple user names and
passwords.  Simple here implies the input has no structure.  That is,
names have no particular style in respect to the algorithm.

It is possible that specification using SASLprep could apply additional
transformations be done.  However, such transforms are beyond the scope
of SASLprep.

>But I thought presenting them might be a valuable thing to do.

I would be interested in hearing whether you think the additional suggested
mapping is appropriate or not for matching of simple user names or passwords,
and why.

I think this issue boils down to whether the user provided strings:
        <STRING1><U+002E><STRING2>
        <STRING1><U+3003><STRING2>
        <STRING1><U+FF0E><STRING2>
        <STRING1><U+FF61><STRING2>

should match or not.  Because user names are often constructed from domain
names, and IDNA says these stops are to be treated as equivalent, I believe
they should match.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 31 Oct 2003 20:52:15 -0800

Kurt 

Date: Fri, 31 Oct 2003 20:52:15 -0800
To: Ienup Sung <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: SASLPrep vs Full Stop code points
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Kurt 

Date: Fri, 31 Oct 2003 17:42:56 -0800 (PST)
From: Ienup Sung <[email-masked]>
Subject: Re: SASLPrep vs Full Stop code points
To: [email-masked], [email-masked]
Reply-to: Ienup Sung <[email-masked]>
Content-MD5: egx+Eeie5tdm2UXdN7GdKQ==
Sender: [email-masked]

With regards,

Ienup

Date: Fri, 31 Oct 2003 17:44:13 -0500
From: Jeffrey Altman <[email-masked]>
Organization: Columbia University in the City of New York
To: [email-masked], [email-masked]
Subject: Re: SASLPrep vs Full Stop code points
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms060501080504060901060506
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Jeffrey Hutzelman wrote:

> In any case, including this mapping in SASLprep will not save us (or 
> applications, or krb5_sname_to_principal, or whatever) from having to 
> recognize and specially handle U+002E, U+3002, U+FF0E, and U+FF61 when 
> constructing principal names or other strings from domain names.  This 
> is because Nameprep may only be applied to individual labels, not 
> entire domain names, and thus such names _must_ be split into separate 
> labels at these characters, each label processed separately, and then 
> the name reassembled, presumably using U+002E (full stop) as the label 
> separator. This is effectively a separate processing step that is 
> required any time nameprep is to be applied.
>
> -- Jeff

The application of SASLprep produces a Storage string or a Query 
string.  These strings are
not appropriate for use as Display strings.  The distinction between the 
different forms
of "full stops" just like the distinction between "spaces" is important 
for display strings.
I just don't see how they can be important for query and storage strings. 

There is an on-going battle taking place on the [email-masked] 
mailing list.  It is a rehashing of all the arguments which have taken 
place over the last ten years on whether or
not internationalization is a good idea.  The argument is clearly 
pointless.  Internationalized
strings are not just a necessity but a desirable feature. 

The fundamental problems related to internationalizing protocols have been
caused by an attempt to allow the use of Storage Strings as Display 
Strings.  This
is wrong.  Storage and query strings are meant to be used within wire 
protocols.
Display strings are meant to be used in user interfaces.  Their use is 
different and
therefore so are the requirements.

I do not see any reason why protocols which rely on SASLprep must allow 
this misuse.
For example, in Kerberos the set/change password protocol and the kdb 
could very well
provide for both a storage string and a display string.  The KDC could 
have a query
function which allows any query string to be used to obtain the display 
string.  The
KDC would also utilize the display string in error messages when 
necessary.  The
purpose of this is to maintain the proper separation between the User 
Interface and
the Wire Protocols.  The one requirement is that the string prep'd 
Display String must
equal the string prep'd storage string when the principal is created.

- Jeff

--------------ms060501080504060901060506
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms060501080504060901060506--

Date: Fri, 31 Oct 2003 14:35:42 -0800
To: Jeffrey Altman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: SASLPrep vs Full Stop code points
Cc: [email-masked], [email-masked]
Sender: [email-masked]

I concur.  I suggest the following bullet item be added to
Section 2.1 of [SASLPrep]:

  - the IDEOGRAPHIC FULL STOP (U+3002), FULLWIDTH FULL STOP (U+FF0E),
    and HALFWIDTH IDEOGRAPHIC FULL STOP (U+FF61) characters be
    mapped to the FULL STOP (U+002E) character.

Kurt

At 10:49 AM 10/31/2003, Jeffrey Altman wrote:
>Over the last week I have realized that we may have overlooked a necessary mapping for the SASLPrep: Full Stop code points.
>
>The Full Stop code points
>
>   U+002E (full stop)
>   U+3002 (ideographic full stop)
>   U+FF0E (fullwidth full stop)
>   U+FF61 (halfwidth ideographic full stop).
>
>do not have mapping tables in StringPrep and are not mapped in NamePrep because IDNA (RFC 3490) uses these characters as an equivalent class of label separators.  Therefore, they cannot exist in any input to which NamePrep would have been applied.
>
>It is my belief that SASLPrep must specify a mapping requiring all Full Stop code points to be mapped to U+002E (full stop).
>
>Jeffrey Altman

Date: Fri, 31 Oct 2003 16:50:59 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Ienup Sung <[email-masked]>, [email-masked], [email-masked]
Subject: Re: SASLPrep vs Full Stop code points
Sender: [email-masked]

On Friday, October 31, 2003 11:48:48 -0800 Ienup Sung 
<[email-masked]> wrote:

> Actually, the IDNA specifies that out of the Stringprep and the Nameprep
> profile; in the similar sense/reasons and to preserve the context of the
> various full stops as much as possible, it seems the Kerberos extension
> also need to specify the additional mappings at the extension not at the
> Stringprep profile and only for the Internet domain-style names.

Please bear in mind that when we discuss saslprep, we're not just talking 
about Kerberos; we're also talking about the whole range of SASL mechansims 
which also use the SASLprep profile for their authentication ID's or for 
other strings, and any SASL applications which use the SASLprep profile on 
authzids.

Also, since you're apparently not familiar with the history, I'll point out 
that there is a simple reason why Kerberos uses the SASLprep profile.  Both 
groups recently had need for stringprep profiles, and began to develop 
requirements and produce documents.  As things progressed, we noticed that 
we were essentially writing exactly the same profile twice.  So, after some 
investigation to determine that we had essentially the same needs, we 
agreed to combine the work and produce a single document.  The folks you've 
been discussing IDN issues with over in krb-wg were part of this process.

Further, I'll point out to the others reading the fundamental point that 
you try to make, which may have been missed -- it may be desirable to map 
U+3002, U+FF0E, and U+EE61 to U+002E _only_ in the context of domain names 
(where it is required), and not in other contexts.  Doing that would indeed 
require that the work of mapping be done other than in SASLprep.

Nameprep does not specify mapping for the full stop characters Jeff 
mentioned, not out of a desire to "preserve context", but because Nameprep 
applies to individual DNS labels, and the full stop characters are not 
permitted in such labels in order to avoid confusion when full domain names 
are represented as strings with "." separating the labels.

IDNA (specifically, RFC3490) has the following to say:

   1) Whenever dots are used as label separators, the following
      characters MUST be recognized as dots: U+002E (full stop), U+3002
      (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61
      (halfwidth ideographic full stop).

It also requires, in the following paragraph, that when dots are used as 
label separators in a domain name placed into an IDN-unaware domain name 
slot, the label separator MUST be U+002E, for the simple reason that none 
of the other possible choices are valid US-ASCII characters.  However, this 
is of relevance only as an indication of intent, since we are NOT presently 
talking about any domain name slots, IDN-aware or otherwise.

One legitimate way to accomplish these requiements is to insure that by the 
time anything is parsed out as a domain name, all of these characters have 
been mapped to U+002E (full stop).  That is what Jeff is proposing for 
SASLprep.  There are two significant advantages to this approach:

(a) It eliminates the need for "special processing" based on whether 
something is to be treated as a domain name.  This is particularly 
important in Kerberos, because even those strings in Kerberos which may be 
derived from domain names (certain realm names and principal name 
components) are _never_ treated as an independent sequence of labels; they 
are treated as single strings which do, in fact, contain periods.  In order 
for KDB lookups and other operations to succeed, the periods must be 
consistent.

(b) It provides for consistent behaviour over all strings of the relevant 
types (among them, Kerberos realm names and principal name components, plus 
the authentication ID's of several SASL mechanisms), rather than giving a 
different behavour for those strings or parts of strings which may contain 
or be derived from domain names.

However, there is also a disadvantage, which is that this is a mapping 
based primarily on visual similarity.  SASLprep does not presently contain 
any such mappings, other than the mapping of non-ASCII space characters to 
U+0020 (space).  I believe we came to the conclusion in the process of 
designing the (now abandoned) Kerberos stringprep profile that such 
mappings would lead down a vague and inconsistent path of attempting to 
second-guess the user, and would thus be counterproductive.  Section 1.2 of 
RFC3490 addresses this issue as well.

It may be the case that the special use of dots in domain names, combined 
with the recommendations of RFC3490 on processing certain other full stop 
characters as domain label separators, justifies special handling in 
SASLprep.  My first inclination was to agree with Jeff and Nico that this 
was obviously the right answer; after thinking about it for a few minutes, 
I'm not so sure.

In any case, including this mapping in SASLprep will not save us (or 
applications, or krb5_sname_to_principal, or whatever) from having to 
recognize and specially handle U+002E, U+3002, U+FF0E, and U+FF61 when 
constructing principal names or other strings from domain names.  This is 
because Nameprep may only be applied to individual labels, not entire 
domain names, and thus such names _must_ be split into separate labels at 
these characters, each label processed separately, and then the name 
reassembled, presumably using U+002E (full stop) as the label separator. 
This is effectively a separate processing step that is required any time 
nameprep is to be applied.

-- Jeff

Date: Fri, 31 Oct 2003 16:38:09 -0500
From: Jeffrey Altman <[email-masked]>
Organization: Columbia University in the City of New York
To: [email-masked], [email-masked]
Subject: Re: SASLPrep vs Full Stop code points
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms050204020601030306090208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ienup:

I do not agree with you. 

You cannot have it both ways.  Either the code points are considered to be
equivalent in which case they are mapped, or they are not equivalent in 
which
case they cannot be mapped.

Please remember that the purpose of SASLPrep is to produce a unique 
representation
of a string which is independent of locale and which can be stored in a 
database
for the purpose of ensuring that it can be queried successfully in the 
future.

Strings which have a String Prep profile applied to them are NOT meant 
to be
used for displaying strings to end users.  They are meant only for the 
purpose
of on the wire equivalency.

SASLPrep is a string prep profile which specifies all of the steps which 
must be
taken an in which order they are to be taken in order to produce the 
form to be
stored in the database.  If there are different classes of strings for 
which
there should be different string prep profiles specified for the 
different classes.

- Jeff

Ienup Sung wrote:

>Thanks.
>
>I agree with you on the place where the mappings of various full stops to
>the U+002E (ASCII's full stop) should be done; the best place would be before
>any Stringprep profile based preparation and iff the name is of Internet domain
>style names.
>
>The reason for the above is that the U+002E isn't equivalent/equal to any
>other ideographic full stops for all the cases and thus, rather, the ideographic
>full stops needed to be preserved as they are. One notable exception is
>of course when they are used as label separators for the Internet domain
>style names.
>
>With regards,
>
>Ienup
>
>
>] Date: Fri, 31 Oct 2003 15:07:42 -0500
>] From: Jeffrey Altman <[email-masked]>
>] Subject: Re: SASLPrep vs Full Stop code points
>] To: [email-masked], [email-masked]
>] MIME-version: 1.0
>] Content-transfer-encoding: 7bit
>] X-Accept-Language: en-us, en
>] X-No-Spam-Score: Local
>] X-Scanned-By: MIMEDefang 2.35
>] 
>] Ienup Sung wrote:
>] 
>] >Actually, the IDNA specifies that out of the Stringprep and the Nameprep
>] >profile; in the similar sense/reasons and to preserve the context of the 
>various
>] >full stops as much as possible, it seems the Kerberos extension also need to
>] >specify the additional mappings at the extension not at the Stringprep profile
>] >and only for the Internet domain-style names
>] >  
>] >
>] I see no justification for while this should be specified at some level 
>] above the
>] application of SASLprep.  SASLprep is applied to Storage and Query 
>] strings for the
>] purpose of ensuring that the strings are equivalent when matching are 
>] performed
>] or that the one true form is used as input to cryptographic operations.
>] 
>] If the Full Stop must be mapped to U+002E before applying SASLprep, and 
>] both
>] operations must always be performed, then it follows that the Full Stop 
>] mapping
>] should be part of SASLprep. 
>] 
>] 
>] 
>] 
>] 
>  
>

--------------ms050204020601030306090208
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms050204020601030306090208--

Date: Fri, 31 Oct 2003 13:07:14 -0800 (PST)
From: Ienup Sung <[email-masked]>
Subject: Re: SASLPrep vs Full Stop code points
To: [email-masked], [email-masked]
Reply-to: Ienup Sung <[email-masked]>
Content-MD5: reBJGW8+y0HsYkgyST+BQg==
Sender: [email-masked]

Thanks.

I agree with you on the place where the mappings of various full stops to
the U+002E (ASCII's full stop) should be done; the best place would be before
any Stringprep profile based preparation and iff the name is of Internet domain
style names.

The reason for the above is that the U+002E isn't equivalent/equal to any
other ideographic full stops for all the cases and thus, rather, the ideographic
full stops needed to be preserved as they are. One notable exception is
of course when they are used as label separators for the Internet domain
style names.

With regards,

Ienup

] Date: Fri, 31 Oct 2003 15:07:42 -0500
] From: Jeffrey Altman <[email-masked]>
] Subject: Re: SASLPrep vs Full Stop code points
] To: [email-masked], [email-masked]
] MIME-version: 1.0
] Content-transfer-encoding: 7bit
] X-Accept-Language: en-us, en
] X-No-Spam-Score: Local
] X-Scanned-By: MIMEDefang 2.35
] 
] Ienup Sung wrote:
] 
] >Actually, the IDNA specifies that out of the Stringprep and the Nameprep
] >profile; in the similar sense/reasons and to preserve the context of the 
various
] >full stops as much as possible, it seems the Kerberos extension also need to
] >specify the additional mappings at the extension not at the Stringprep profile
] >and only for the Internet domain-style names
] >  
] >
] I see no justification for while this should be specified at some level 
] above the
] application of SASLprep.  SASLprep is applied to Storage and Query 
] strings for the
] purpose of ensuring that the strings are equivalent when matching are 
] performed
] or that the one true form is used as input to cryptographic operations.
] 
] If the Full Stop must be mapped to U+002E before applying SASLprep, and 
] both
] operations must always be performed, then it follows that the Full Stop 
] mapping
] should be part of SASLprep. 
] 
] 
] 
] 
] 

Date: Fri, 31 Oct 2003 15:07:42 -0500
From: Jeffrey Altman <[email-masked]>
Organization: Columbia University in the City of New York
To: [email-masked], [email-masked]
Subject: Re: SASLPrep vs Full Stop code points
Sender: [email-masked]

Ienup Sung wrote:

>Actually, the IDNA specifies that out of the Stringprep and the Nameprep
>profile; in the similar sense/reasons and to preserve the context of the various
>full stops as much as possible, it seems the Kerberos extension also need to
>specify the additional mappings at the extension not at the Stringprep profile
>and only for the Internet domain-style names
>  
>
I see no justification for while this should be specified at some level 
above the
application of SASLprep.  SASLprep is applied to Storage and Query 
strings for the
purpose of ensuring that the strings are equivalent when matching are 
performed
or that the one true form is used as input to cryptographic operations.

If the Full Stop must be mapped to U+002E before applying SASLprep, and 
both
operations must always be performed, then it follows that the Full Stop 
mapping
should be part of SASLprep. 

To: [email-masked]
Subject: Consensus call: changing examples from ACAP to SMTP
Date: Fri, 31 Oct 2003 14:52:05 -0500 (EST)
From: [email-masked] (Sam Hartman)
Sender: [email-masked]

Hi.  The discussion seems to have died down on the issue of replacing
the ACAP example with an SMTP example in the plain draft.

The rough consensus of this working group is that we will not change
to an SMTP-based example.  We seem to believe that the examples in the
plain document should illustrate that mechanisms, not illustrate common
implementation errors in other related protocols.

I think that we have something approaching a consensus that we will be
better served by encouraging implementers to read all the appropriate
documents than to include information designed to make sure that
implementers will not make mistakes even if they do not read the
appropriate documents.  That's not as clear as the consensus against
changing the example to SMTP; there may be more room for discussion on
this issue.

Personally I believe that we may want to consider ways in which we can
make it clear to implementers what documents they want to read.

--Sam

Date: Fri, 31 Oct 2003 11:48:48 -0800 (PST)
From: Ienup Sung <[email-masked]>
Subject: Re: SASLPrep vs Full Stop code points
To: [email-masked], [email-masked]
Reply-to: Ienup Sung <[email-masked]>
Sender: [email-masked]

--Boundary_(ID_iHfplVVsxREVrFiq1oDd/g)
Content-type: TEXT/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-MD5: CwuEY9WEdIoX6gjf2xZb2Q==

Actually, the IDNA specifies that out of the Stringprep and the Nameprep
profile; in the similar sense/reasons and to preserve the context of the various
full stops as much as possible, it seems the Kerberos extension also need to
specify the additional mappings at the extension not at the Stringprep profile
and only for the Internet domain-style names.

Please see the attached, esp., the issue-1.

With regards,

Ienup

] Date: Fri, 31 Oct 2003 13:49:31 -0500
] From: Jeffrey Altman <[email-masked]>
] Subject: SASLPrep vs Full Stop code points
] To: [email-masked], [email-masked]
] MIME-version: 1.0
] Content-transfer-encoding: 7bit
] X-Accept-Language: en-us, en
] X-No-Spam-Score: Local
] X-Scanned-By: MIMEDefang 2.35
] 
] Over the last week I have realized that we may have overlooked a 
] necessary mapping for the SASLPrep: Full Stop code points.
] 
] The Full Stop code points
] 
]     U+002E (full stop)
]     U+3002 (ideographic full stop)
]     U+FF0E (fullwidth full stop)
]     U+FF61 (halfwidth ideographic full stop).
] 
] do not have mapping tables in StringPrep and are not mapped in NamePrep 
] because IDNA (RFC 3490) uses these characters as an equivalent class of 
] label separators.  Therefore, they cannot exist in any input to which 
] NamePrep would have been applied.
] 
] It is my belief that SASLPrep must specify a mapping requiring all Full 
] Stop code points to be mapped to U+002E (full stop).
] 
] Jeffrey Altman
] 
] 
] 
] 
] 

--Boundary_(ID_iHfplVVsxREVrFiq1oDd/g)
Content-type: TEXT/plain; name=idn-considerations-with-kerberos-extension.txt;
 charset=us-ascii; x-unix-mode=0644
Content-transfer-encoding: 7BIT
Content-disposition: attachment;
 filename=idn-considerations-with-kerberos-extension.txt
Content-description: idn-considerations-with-kerberos-extension.txt
Content-MD5: VfsNrPuCPZApp138x+c8QQ==

								10/23/2003
							[email-masked]

Internationalized Domain Name considerations at Kerberos extension
------------------------------------------------------------------

1. Overview

Many existing implementations and system administrators derive Kerberos Realm
and Principal Names from Internet domain-style domain names [1, 2].

While it is rather and relatively a simple task when the coded character
set (codeset) is a 7-bit ASCII, when the repertoire of the characters to
support increases and have to support various scripts and languages at
the same time, the complexity also increases and there are issues that
the existing standards have not been anticipated. Furthermore,
recent standardization of Internationalized Domain Name (IDN) and accompanying
application layer architecture/model called Internationalized Domain Names in
Applications (IDNA) [3], further increase the complexity and uncertainty on
the compatible support of the IDN.

This memo tries to describe what are the surrounding issues when we move to
the Unicode character set repertoire and also when we have to support IDN
and also have maximum compatibility with the IDNA implementations.

This memo does not cover or deal with any other internationalization issues
at the moment. The U+XXXX and U+YYYYYY are the usual Unicode notations where
the XXXX and the YYYYYY denote code point values in the Unicode coding space.

2. Issues and Possible Resolution Suggestions

In my opinion, the following issues should be mentioned at the
extension and hopefully with normative assertions/guidelines/recommendations
on what should be done:

- Issue-1: IDNA allows various label separators such as U+002E (full stop),
	U+3002 (ideographic full stop), U+FF0E (fullwidth full stop), and
	U+FF61 (halfwidth ideographic full stop).
- Resolution-1: Before such domain-style names be used at the Kerberos
	implementations to derive the Realm, Principal Names, or both, such
	label separators should all be mapped to 7-bit ASCII/UTF-8 full-stop
	character ('.' which is U+002E). This is only for Internet
	domain-style names.

- Issue-2: IDNA allows both ASCII Compatible Encoding (ACE) [3, 5] names and
	IDN names with 8-bit characters as possible user input.
- Resolution-2: The Kerberos extension will use UTF-8 as the codeset of
	the choice; thus if user input is in ACE which starts with "xn--"
	prefix, then, such names must be converted back to non-ACE, UTF-8
	IDN names through the [3]'s conversion steps before the use. For
	any IDN names with 8-bit characters with non-UTF-8 codsets/codepages,
	such names should be must be converted to UTF-8 IDN names before
	the use if the name is not in the UTF-8.

- Issue-3: Since the Nameprep [4] used as the Stringprep [5] profile at
	the IDNA does the case-folding [7] mappings before the Normalization
	Form KC (NFKC) [8], the IDNA effectively allows various equivalent IDN
	names for a domain name (or, hostname for that matter). On the other
	hand, the SASLprep [9] that will be used by the extension does
	not employee the case-folding mapping and, as a consequence, generates
	different results for various equivalent names.
- Resolution-3: Before the use, any IDN names with 8-bit characters must be
	converted to UTF-8 if necessary and then the Nameprep must be applied;
	this will ensure that the various equivalent names map to a single
	Realm and Principal names derived.

- Issue-4: SASLprep and Nameprep prohibits Private Use Area (PUA) characters
	and hence denying characters/character codes of user-defined characters
	commonly used in Asian countries at the Principal names.
- Resolution-4: Either accept that as the limitation, update the
	SASLprep and allow the PUA characters, or come up with
	a Kerberosprep profile that will allow the PUA characters by
	omitting the Stringprep Table C.3 from the "Prohibited Output"
	section.

- Issue-5: The clarification [2] defines Realm and PrincipalName be encoded
	as KerberosString. The KerberosString type includes ACE string by
	definition.
- Resolution-5: To reduce future confusions, the exclusion recommendation of
	the ACE encoded string at the KerberosString with a rationale is
	desired preferably at the [2] and also at the extension.
	If to allow the ACE, then, also ample descriptions on consequences
	and also additional info should be given at the [2] and the extension.

- Issue-6: Case conversions are required for the Principals and Realms;
	Unicode introduces complications to case mappings due to 
	the character set includes characters from various scripts and
	languages.
- Resolution-6: If the case conversions are also required for the IDN names,
	they must be done as normative steps for the Realm and Principal Names.
	In doing so, it is necessary to provide the rules and mapping tables
	to have the deterministic case conversions; the rules and mappings
	should come from [7] and standard Unicode data files. Furthermore,
	considering normalized names are necessary to have deterministic name
	matchings in my opinion, the case conversions should not be done alone
	but should be done before or possibly together with the normalization
	depending on the normalization form that will be used for the Realm
	and the Principal names. Also, considering there is no mapping tables
	defined for the case conversions in any of the existing
	profiles or the Stringprep itself, it appears that the WG should
	come up with case conversion mapping tables that will be used at
	the Stringprep profile's mapping step prior to or along with
	the normalization step. (More investigation and study would
	required on this issue by the way.)

- Issue-7: Unlike case-foldings that can be done in *pretty much* locale-
	independent way, case conversions can yield and also require different
	per-locale conversion mappings.
- Resolution-7: Either there should be additional mappings at the mapping
	step of the Stringprep profile that will be used for the extension
	so that such locale-specific case conversion differences will be
	erased (in a sense, a small set of case-folding or semi-case-folding,
	if you will, on certain characters) or allow such per-locale conversions
	and treat the converted names not equivalent.

3. References

[1] RFC 1510 Kerberos
[2] Kerberos clarification Internet Draft
[3] RFC 3490 IDNA
[4] RFC 3491 Nameprep
[5] RFC 3492 Punycode
[6] RFC 3454 Stringprep
[7] UAX21 Case Mappings for Unicode 3.2
[8] UAX15 Unicode Normalization Forms for Unicode 3.2
[9] SASLprep Internet Draft

--Boundary_(ID_iHfplVVsxREVrFiq1oDd/g)--

Date: Fri, 31 Oct 2003 10:54:39 -0800
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Jeffrey Altman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: SASLPrep vs Full Stop code points
Mail-Followup-To: Sam Hartman <[email-masked]>, Jeffrey Altman <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Fri, Oct 31, 2003 at 01:56:57PM -0500, Sam Hartman wrote:
> >>>>> "Jeffrey" == Jeffrey Altman <[email-masked]> writes:
> 
>     Jeffrey> Over the last week I have realized that we may have overlooked a
>     Jeffrey> necessary mapping for the SASLPrep: Full Stop code points.
> 
> As you know, the document has already passed working group last call.
> So if we are going to make a change we should come to consensus soon.
> To that end, I'm seeking comments on this proposed change from the
> working group.

I agree with Jeff's point.

Nico
-- 

To: Jeffrey Altman <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: SASLPrep vs Full Stop code points
From: Sam Hartman <[email-masked]>
Date: Fri, 31 Oct 2003 13:56:57 -0500
Sender: [email-masked]

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

    Jeffrey> Over the last week I have realized that we may have overlooked a
    Jeffrey> necessary mapping for the SASLPrep: Full Stop code points.

As you know, the document has already passed working group last call.
So if we are going to make a change we should come to consensus soon.
To that end, I'm seeking comments on this proposed change from the
working group.

Date: Fri, 31 Oct 2003 13:49:31 -0500
From: Jeffrey Altman <[email-masked]>
Organization: Columbia University in the City of New York
To: [email-masked], [email-masked]
Subject: SASLPrep vs Full Stop code points
Sender: [email-masked]

Over the last week I have realized that we may have overlooked a 
necessary mapping for the SASLPrep: Full Stop code points.

The Full Stop code points

    U+002E (full stop)
    U+3002 (ideographic full stop)
    U+FF0E (fullwidth full stop)
    U+FF61 (halfwidth ideographic full stop).

do not have mapping tables in StringPrep and are not mapped in NamePrep 
because IDNA (RFC 3490) uses these characters as an equivalent class of 
label separators.  Therefore, they cannot exist in any input to which 
NamePrep would have been applied.

It is my belief that SASLPrep must specify a mapping requiring all Full 
Stop code points to be mapped to U+002E (full stop).

Jeffrey Altman

To: [email-masked]
Subject: Any new lines of thought on the SMTP comments
Date: Thu, 30 Oct 2003 15:05:42 -0500 (EST)
From: [email-masked] (Sam Hartman)
Sender: [email-masked]

It seems like we're starting to repeat ourselves somewhat especially
on the issue of revising examples in the plain SASL mechanism
document.

Are there any new positions that have not previously been considered
or any misunderstandings that need to be worked out before we conclude
that discussion?

To: Cyrus Daboo <[email-masked]>
Cc: Ken Murchison <[email-masked]>, "Kurt D. Zeilenga" <[email-masked]>, Mark Crispin <[email-masked]>, Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt
From: Sam Hartman <[email-masked]>
Date: Thu, 30 Oct 2003 15:04:03 -0500
Sender: [email-masked]

>>>>> "Cyrus" == Cyrus Daboo <[email-masked]> writes:

    Cyrus> | I think that encouraging/enforcing this point | is more
    Cyrus> important than cross-pollinating the docs with the same
    Cyrus> info.

    Cyrus> Again I would like to suggest some kind of "implementer's
    Cyrus> guide" document for SASL that would provide comprehensive
    Cyrus> examples for each type of protocol and each mechanism, as
    Cyrus> well as a list of the common implementation errors that
    Cyrus> have cropped up. That's not meant to replace having to read
    Cyrus> and understand each of the other documents, but can be used
    Cyrus> more as a starting point for multiple protocol
    Cyrus> implementations etc.

Why is this preferable to including protocol specific implementation
notes in the protocol profile documents?

--Sam

Date: Thu, 30 Oct 2003 10:39:29 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
cc: Ken Murchison <[email-masked]>, Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt
Sender: [email-masked]

On Thu, 30 Oct 2003, Kurt D. Zeilenga wrote:
> If they don't read the SASL specification, then any wouldn't read any
> examples we'd place there.

Exactly.  That's why it has to be in all the relevant documents, in the
hope that the implementor will see the example in the document he chooses
to read.

> I also note that examples are informative
> in nature.  It should be possible to independently develop interoperable
> implementations without reading any example.

I wish that too; but it is unrealistic.

> I think we're resisting attempts to add examples intended to clarify
> aspects of protocol which are not specified in this document.  Clarifying
> the SMTP, LDAP, IMAP, and other application level protocol specifications
> is beyond the scope of this document.

PLAIN is a mechanism which can operate in one of two ways, depending upon
whether or not the client supplies initial data.  This applies to all
application protocols that use SASL.  Therefore, this is within the scope
of PLAIN.

The choice of SMTP instead of ACAP is defensible by the fact that there
will be many more SMTP implementations than ACAP implementations.  Also,
SMTP style interaction is much more typical of Internet protocols than
ACAP (or POP3 or IMAP).  NNTP and FTP are other examples of such protocols
that use SASL now (or are likely to in the future).

The fact that a server needs to send something like "334 " (note the
trailing space) and nothing else is non-intuitive and surprising.  It
triggers a "that can't be right" feeling.  Therefore, there needs to be
explicit examples that say, "yes, it is right".

No matter how redundant an example may seem to be, if it prevents a bad
implementation then less harm is done by having the example in the
document.  I regularly deal with individuals who insist that because
explicit text isn't in one particular RFC, the associated requirement
therefore does not exist -- no matter how many normative documents say
otherwise!

This is why RFCs 2821 and 2822 spend a considerable amount of effort
belaboring points that seem to be in the other document's scope.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Thu, 30 Oct 2003 09:44:53 -0800
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: Agenda items to discuss
Mail-Followup-To: Sam Hartman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Thu, Oct 30, 2003 at 11:45:55AM -0500, Sam Hartman wrote:
> 
> >>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:
> 
>     Nicolas> On Wed, Oct 29, 2003 at 01:44:05PM -0500, Sam Hartman
>     Nicolas> wrote:
>     >> * There was some discussion of multiple layers of encryption
>     >> (TLS vs security layers) in XMPP; do we want to develop
>     >> guidance for protocol designers on this issue?
> 
>     Nicolas> I think this should be discussed.
> 
>     Nicolas> I think the guidance we want to give is: don't delegate
>     Nicolas> session protection from one layer to another without
>     Nicolas> confirming that the end-points at both layers are the
>     Nicolas> same.
> 
Sam> This approach is out of scope for the SASL working group as it
Sam> cannot be implemented within the current charter.  If you want to
Sam> discuss the approach on the list, that's fine.  However I don't
Sam> think modifying SASL to gain channel bindings is appropriate for
Sam> meeting time at the IETF.

I don't see how the text from me that you quote could possibly be out of
scope for this WG - that text calls for "guidance" - security
considerations text.

The following text from me which you didn't quote does propose two
things, one of which may well be out of scope for the WG - which is fine
by me, as long as guidance is given:

Nico> It would be nice if SASL had a channel bindings facility.  Such a
Nico> facility could be added or applications could be encouraged to
Nico> exchange channel bindings data integrity protected at the SASL
Nico> layer.

I can see that adding a channel bindings facility to SASL may be out of
scope for this WG.

That said, you could argue that the channel bindings I-D itself
provides, or should provide, sufficient guidance for developers of SASL
application protocols.  If so, please review the text in section 3.2 of
draft-ietf-nfsv4-channel-bindings-00.txt.

Thanks,

Nico
-- 

Date: Thu, 30 Oct 2003 09:43:15 -0800
To: Mark Crispin <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt
Cc: Ken Murchison <[email-masked]>, Rob Siemborski <[email-masked]>, [email-masked]
Sender: [email-masked]

At 07:48 AM 10/30/2003, Mark Crispin wrote:
>People cut corners, skip documents, and make assumptions through empirical
>tests with existing implementation.  I wish that the world was not this
>way.  It is.
>
>For people with that mindset, the only thing that you need the SMTP SASL
>document for is to learn the response codes.  Nothing else needs to be
>read.  They don't read 2222 either.  "It works with Netscape and Outlook"
>is their rallying call.

If they don't read the SASL specification, then any wouldn't read any
examples we'd place there.  I also note that examples are informative
in nature.  It should be possible to independently develop interoperable
implementations without reading any example.

>Clarifying examples are always good.

If placed in the appropriate document and don't get in the way of the
definitive specification, I would accept that non-redundant clarifying
examples are generally good thing.

>I understand why you resist
>examples; I underwent that myself with the IMAP specification.  The IMAP
>specification had to grow enormously to accomodate all the examples that
>people insisted upon adding.  But even I have to acknowledge that the
>result was better than what was before.

I think we're resisting attempts to add examples intended to clarify
aspects of protocol which are not specified in this document.  Clarifying
the SMTP, LDAP, IMAP, and other application level protocol specifications
is beyond the scope of this document.

Kurt

Date: Thu, 30 Oct 2003 12:39:32 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Cyrus Daboo <[email-masked]>
CC: "Kurt D. Zeilenga" <[email-masked]>, Mark Crispin <[email-masked]>, Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Ken,
> 
> --On Thursday, October 30, 2003 9:55 -0500 Ken Murchison 
> <[email-masked]> wrote:
> 
> | No matter how you slice it, any good/responsible implementer is going to
> | *have* to read three docs.
> 
> Its not just three, in fact it is one (SASL), + one per-mechanism, + one 
> per-protocol. If you're writing an email client, chances are that's 

Right.  I was just looking at the SMTP + PLAIN scenario.

> going to be IMAP, POP3 and SMTP, with LDAP a likelihood too. In our case 
> we also have to contend with ACAP, IMSP and ManageSIEVE (and soon BEEP). 
> Each of those is slightly different in some way. Multiply that by all 
> the mechanisms...
> 
> | I think that encouraging/enforcing this point
> | is more important than cross-pollinating the docs with the same info.
> 
> Again I would like to suggest some kind of "implementer's guide" 
> document for SASL that would provide comprehensive examples for each 
> type of protocol and each mechanism, as well as a list of the common 
> implementation errors that have cropped up. That's not meant to replace 
> having to read and understand each of the other documents, but can be 
> used more as a starting point for multiple protocol implementations etc.

I think this is an excellent idea.  I might even be able to volunteer to 
author or co-author such a document.

> I would also like to suggest the possibility of an interop event once 
> the new docs are out so that we can pin down problems related to the new 
> i18n stuff, as well as weed out existing problems. The feedback from 
> that could be used in the implementer's guide too.

Another good idea.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Thu, 30 Oct 2003 17:10:37 +0000
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Ken Murchison <[email-masked]>, "Kurt D. Zeilenga" <[email-masked]>, Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt
Sender: [email-masked]

Mark Crispin wrote:

>Clarifying examples are always good.  I understand why you resist
>examples; I underwent that myself with the IMAP specification.  The IMAP
>specification had to grow enormously to accomodate all the examples that
>people insisted upon adding.  But even I have to acknowledge that the
>result was better than what was before.
>
Instead of modifying PLAIN, I would rather recommend adding more 
examples to RFC2222bis or create a new draft "SASL Implementation 
Considerations" which contains list of common mistakes and compares 
different profiles.

Alexey

Date: Thu, 30 Oct 2003 12:00:16 -0500
From: Cyrus Daboo <[email-masked]>
To: Ken Murchison <[email-masked]>, "Kurt D. Zeilenga" <[email-masked]>
cc: Mark Crispin <[email-masked]>, Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt
Sender: [email-masked]

Hi Ken,

--On Thursday, October 30, 2003 9:55 -0500 Ken Murchison <[email-masked]> 
wrote:

| No matter how you slice it, any good/responsible implementer is going to
| *have* to read three docs.

Its not just three, in fact it is one (SASL), + one per-mechanism, + one 
per-protocol. If you're writing an email client, chances are that's going 
to be IMAP, POP3 and SMTP, with LDAP a likelihood too. In our case we also 
have to contend with ACAP, IMSP and ManageSIEVE (and soon BEEP). Each of 
those is slightly different in some way. Multiply that by all the 
mechanisms...

| I think that encouraging/enforcing this point
| is more important than cross-pollinating the docs with the same info.

Again I would like to suggest some kind of "implementer's guide" document 
for SASL that would provide comprehensive examples for each type of 
protocol and each mechanism, as well as a list of the common implementation 
errors that have cropped up. That's not meant to replace having to read and 
understand each of the other documents, but can be used more as a starting 
point for multiple protocol implementations etc.

I would also like to suggest the possibility of an interop event once the 
new docs are out so that we can pin down problems related to the new i18n 
stuff, as well as weed out existing problems. The feedback from that could 
be used in the implementer's guide too.

-- 
Cyrus Daboo

To: [email-masked]
Subject: Re: Agenda items to discuss
From: Sam Hartman <[email-masked]>
Date: Thu, 30 Oct 2003 11:45:55 -0500
Sender: [email-masked]

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Wed, Oct 29, 2003 at 01:44:05PM -0500, Sam Hartman
    Nicolas> wrote:
    >> * There was some discussion of multiple layers of encryption
    >> (TLS vs security layers) in XMPP; do we want to develop
    >> guidance for protocol designers on this issue?

    Nicolas> I think this should be discussed.

    Nicolas> I think the guidance we want to give is: don't delegate
    Nicolas> session protection from one layer to another without
    Nicolas> confirming that the end-points at both layers are the
    Nicolas> same.

This approach is out of scope for the SASL working group as it cannot
be implemented within the current charter.  If you want to discuss the
approach on the list, that's fine.  However I don't think modifying
SASL to gain channel bindings is appropriate for meeting time at the
IETF.

Date: Thu, 30 Oct 2003 07:48:27 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: "Kurt D. Zeilenga" <[email-masked]>, Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt
Sender: [email-masked]

On Thu, 30 Oct 2003, Ken Murchison wrote:
> No matter how you slice it, any good/responsible implementer is going to
> *have* to read three docs.  I think that encouraging/enforcing this
> point is more important than cross-pollinating the docs with the same info.

Unfortunately, the "good/responsible implementors" do not include the
authors of SMTP SASL for qmail, Microsoft Exchange, or for one of China's
main SMTP servers (smtp.163.net).

People cut corners, skip documents, and make assumptions through empirical
tests with existing implementation.  I wish that the world was not this
way.  It is.

For people with that mindset, the only thing that you need the SMTP SASL
document for is to learn the response codes.  Nothing else needs to be
read.  They don't read 2222 either.  "It works with Netscape and Outlook"
is their rallying call.

I am not of that mindset, but I have spent many weary hours convincing
those who have that mindset that their software is broken.

Clarifying examples are always good.  I understand why you resist
examples; I underwent that myself with the IMAP specification.  The IMAP
specification had to grow enormously to accomodate all the examples that
people insisted upon adding.  But even I have to acknowledge that the
result was better than what was before.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Thu, 30 Oct 2003 09:55:53 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: "Kurt D. Zeilenga" <[email-masked]>
CC: Mark Crispin <[email-masked]>, Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt
Sender: [email-masked]

Kurt D. Zeilenga wrote:
> At 11:17 PM 10/29/2003, Mark Crispin wrote:
> 
>>On Wed, 29 Oct 2003, Kurt D. Zeilenga wrote:
>>
>>>I think ACAP is a good choice for illustration of SASL/PLAIN
>>>mechanism.  No base64, meaningful protocol tokens (instead of
>>>numeric codes), and a straightforward/simple syntax.
>>
>>It is precisely because ACAP does not use BASE64 and does not use numeric
>>code that makes it unsuitable.  IMAP is also unsuitable.
> 
> 
> The sole purpose of the example is to illustrate the syntax and
> semantics described in Section 2 and this purpose is, in my opinion,
> best served by avoiding protocol encodings which obfuscate the value
> of the message production.

I tend to agree.  The mechanism docs should only have to worry about the 
order and contents of the exchanges, not how they are encoded or how the 
client-first and server-last issues are handled.

>>>The trouble we've seen with SMTP implementations, I think, make
>>>SMTP a particular bad choice for use here.
>>
>>The trouble with SMTP implementation is the *exact* reason why SMTP
>>examples are needed.  You don't need examples for things that people will
>>get right.  You need examples for things that people get wrong!
> 
> 
> Some folks have problems getting LDAP/SASL right, so, by your argument,
> we should include LDAP-based examples in the PLAIN document.
> 
> The trouble with SMTP implementations of SMTP's SASL profile is more
> appropriately addressed by revising the SMTP specification.  Attempting
> to address these problems in the PLAIN specification might lead to
> even more confusion in the SMTP community.

I understand why Mark is proposing more examples (to prevent large 
deployment of incorrect implementations that we all have to deal with), 
but I have to agree with Kurt that the protocol profile is where 
comprehensive examples belong.  RFC 2222[bis] was written so that the 
protocol profiles and mechanism specifications are orthogonal.  In fact, 
the PLAIN doc shouldn't have to worry about whether particular protocols 
support an initial response or not.  RFC 2222bis describes how to handle 
this, and the protocol profile should describe how to implement it.

No matter how you slice it, any good/responsible implementer is going to 
*have* to read three docs.  I think that encouraging/enforcing this 
point is more important than cross-pollinating the docs with the same info.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Thu, 30 Oct 2003 01:11:56 -0800
To: Mark Crispin <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt
Cc: Rob Siemborski <[email-masked]>, [email-masked]
Sender: [email-masked]

At 11:17 PM 10/29/2003, Mark Crispin wrote:
>On Wed, 29 Oct 2003, Kurt D. Zeilenga wrote:
>> I think ACAP is a good choice for illustration of SASL/PLAIN
>> mechanism.  No base64, meaningful protocol tokens (instead of
>> numeric codes), and a straightforward/simple syntax.
>
>It is precisely because ACAP does not use BASE64 and does not use numeric
>code that makes it unsuitable.  IMAP is also unsuitable.

The sole purpose of the example is to illustrate the syntax and
semantics described in Section 2 and this purpose is, in my opinion,
best served by avoiding protocol encodings which obfuscate the value
of the message production.

>> The trouble we've seen with SMTP implementations, I think, make
>> SMTP a particular bad choice for use here.
>
>The trouble with SMTP implementation is the *exact* reason why SMTP
>examples are needed.  You don't need examples for things that people will
>get right.  You need examples for things that people get wrong!

Some folks have problems getting LDAP/SASL right, so, by your argument,
we should include LDAP-based examples in the PLAIN document.

The trouble with SMTP implementations of SMTP's SASL profile is more
appropriately addressed by revising the SMTP specification.  Attempting
to address these problems in the PLAIN specification might lead to
even more confusion in the SMTP community.

Kurt 

Date: Wed, 29 Oct 2003 23:17:40 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
cc: Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt
Sender: [email-masked]

On Wed, 29 Oct 2003, Kurt D. Zeilenga wrote:
> I think ACAP is a good choice for illustration of SASL/PLAIN
> mechanism.  No base64, meaningful protocol tokens (instead of
> numeric codes), and a straightforward/simple syntax.

It is precisely because ACAP does not use BASE64 and does not use numeric
code that makes it unsuitable.  IMAP is also unsuitable.

> The trouble we've seen with SMTP implementations, I think, make
> SMTP a particular bad choice for use here.

The trouble with SMTP implementation is the *exact* reason why SMTP
examples are needed.  You don't need examples for things that people will
get right.  You need examples for things that people get wrong!

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Wed, 29 Oct 2003 23:10:51 -0800
To: Rob Siemborski <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 04:05 PM 10/29/2003, Rob Siemborski wrote:
>Mark had a few comments on the PLAIN draft, mostly centered around the
>issue of the initial response examples.  I tend to agree with his
>assessments.  I'll note (as Kurt did), that this document has already been
>through the WG last call.
>
>a) ACAP is probably not the best choice of protocol for the example, since
>it is not in wide use.  A protocol such as SMTP is probably more
>appropriate (especially given the trouble we've seen with SMTP
>implementations getting initial response handling correct).  SMTP has the
>added advantage of having 3 digit response codes that in other have
>optional text -- though that is not the case in the SASL challenges.

I think ACAP is a good choice for illustration of SASL/PLAIN
mechanism.  No base64, meaningful protocol tokens (instead of
numeric codes), and a straightforward/simple syntax.  I doubt
developers needs to consult the ACAP specific to understand the
example.

The trouble we've seen with SMTP implementations, I think, make
SMTP a particular bad choice for use here.

>b) An example demonstrating plain without using the initial response
>argument on a protocol that supports it.  This would again help to address
>the implementation problems with the optional initial client send.

I have no objection to adding another example.  I'll offer
specific text for the WG to consider in a subsequent post.

>One thing that may also help is to place reminders in mechanism (and
>protocol) documents that a correct implementation of SASL for a given
>protocol requires an understanding of the protocol profile, the SASL
>framework, and the mechanism, and that reading all three documents is
>necessary to get it right.

I'll stay on the fence on this one, so I suggest that someone who
currently supports adding such offer specific text for WG
consideration.

Kurt 

Date: Wed, 29 Oct 2003 19:05:11 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt
Sender: [email-masked]

Mark had a few comments on the PLAIN draft, mostly centered around the
issue of the initial response examples.  I tend to agree with his
assessments.  I'll note (as Kurt did), that this document has already been
through the WG last call.

a) ACAP is probably not the best choice of protocol for the example, since
it is not in wide use.  A protocol such as SMTP is probably more
appropriate (especially given the trouble we've seen with SMTP
implementations getting initial response handling correct).  SMTP has the
added advantage of having 3 digit response codes that in other have
optional text -- though that is not the case in the SASL challenges.

b) An example demonstrating plain without using the initial response
argument on a protocol that supports it.  This would again help to address
the implementation problems with the optional initial client send.

There are examples in draft-siemborski-rfc2554bis-00.txt (using SMTP) that
satisfy this, and could be used.

One thing that may also help is to place reminders in mechanism (and
protocol) documents that a correct implementation of SASL for a given
protocol requires an understanding of the protocol profile, the SASL
framework, and the mechanism, and that reading all three documents is
necessary to get it right.  Of course, in a perfect world, normative
references would be enough, but experience seems to be showing this not to
be the case.

(I'd also like to encourage people again to read over and comment more
generally on draft-siemborski-rfc2554bis-00.txt and
draft-siemborski-rfc1734bis-00.txt).

We're also both planning on being at the SASL WG meeting in Minneapolis,
and can discuss this further then.

-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, 29 Oct 2003 15:44:12 -0800
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Cc: Sam Hartman <[email-masked]>
Subject: Re: Agenda items to discuss
Mail-Followup-To: [email-masked], Sam Hartman <[email-masked]>
Sender: [email-masked]

On Wed, Oct 29, 2003 at 06:44:26PM -0500, Jeffrey Altman [Kermit Project Volunteer] wrote:
> Nicolas Williams wrote:
> [...]
> >http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-channel-bindings-00.txt
> [...]

> I second this sentiment.  We need to provide advice on how the 
> underlying session security can be validated as part of the SASL 
> authentication OR after the authentication by exchanging messages using 
> the SASL Security Layer which can be then be turned off if validation 
> was successful.

Note that I did post a request for this and other WGs to review the
channel bindings draft.  There is a section in that I-D about SASL, BTW.

Cheers,

Nico
-- 

Date: Wed, 29 Oct 2003 18:44:26 -0500
From: "Jeffrey Altman [Kermit Project Volunteer]" <[email-masked]>
Reply-To: [email-masked]
Organization: Columbia University in the City of New York
To: Nicolas Williams <[email-masked]>
CC: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: Agenda items to discuss
Sender: [email-masked]

Nicolas Williams wrote:

>On Wed, Oct 29, 2003 at 01:44:05PM -0500, Sam Hartman wrote:
>  
>
>>* There was some discussion of multiple layers of encryption (TLS vs security layers) in XMPP; do we want
>>to develop guidance for protocol designers on this issue?
>>    
>>
>
>I think this should be discussed.
>
>I think the guidance we want to give is: don't delegate session
>protection from one layer to another without confirming that the
>end-points at both layers are the same.
>
>See:
>
>http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-channel-bindings-00.txt
>
>
>It would be nice if SASL had a channel bindings facility.  Such a
>facility could be added or applications could be encouraged to exchange
>channel bindings data integrity protected at the SASL layer.
>
>Can GSS-API channel bindings facility be used when using the GSS-* SASL
>mechanisms?
>
>Cheers,
>
>Nico
>  
>
I second this sentiment.  We need to provide advice on how the 
underlying session security can be validated as part of the SASL 
authentication OR after the authentication by exchanging messages using 
the SASL Security Layer which can be then be turned off if validation 
was successful.

Jeffrey Altman

Date: Wed, 29 Oct 2003 14:51:09 -0800
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: Agenda items to discuss
Mail-Followup-To: Sam Hartman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Oct 29, 2003 at 01:44:05PM -0500, Sam Hartman wrote:
> * There was some discussion of multiple layers of encryption (TLS vs security layers) in XMPP; do we want
> to develop guidance for protocol designers on this issue?

I think this should be discussed.

I think the guidance we want to give is: don't delegate session
protection from one layer to another without confirming that the
end-points at both layers are the same.

See:

http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-channel-bindings-00.txt

It would be nice if SASL had a channel bindings facility.  Such a
facility could be added or applications could be encouraged to exchange
channel bindings data integrity protected at the SASL layer.

Can GSS-API channel bindings facility be used when using the GSS-* SASL
mechanisms?

Cheers,

Nico
-- 

Subject: Re: Agenda items to discuss
From: Greg Hudson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Date: Wed, 29 Oct 2003 16:51:41 -0500
Sender: [email-masked]

On Wed, 2003-10-29 at 13:44, Sam Hartman wrote:
> * There was some discussion of multiple layers of encryption (TLS vs security layers) in XMPP; do we want
> to develop guidance for protocol designers on this issue?

I won't be at the meeting, but I'd like to weigh in with the opinion
that we shouldn't make it any harder for implementations to do dual
encryption of data for defense-in-depth.  It may seem redundant and
expensive to encrypt or sign twice (and it's certainly fair for an
implementation to avoid using a security layer if it's running over
TLS), but it's not completely redundant; the keys used for one security
layer may be compromisable under different assumptions than the keys
used for another.

For example: I make a TLS connection to an MIT server and then
SASL-authenticate via GSSAPI.  Unbeknownst to me, a CA trusted by my
client has issued a bogus X.509 certificate for MIT to an attacker.  The
attacker intercepts my connection, initiates its own connection to the
real MIT server, and passes through my communications so that GSSAPI
authentication succeeds.  If my client insists on using a SASL security
layer, the attacker will not be able to modify (or perhaps even read) my
communications despite having compromised TLS.

I'm not sure if anyone was seriously considering disallowing dual
security layers, but RFC 3080 section 4.1 does so, so it seemed worth
heading off.

> I think most of the other changes that have been brought forward have
> been resolved; please correct me if I'm wrong.  I think Greg's
> comments on implementing SASL have not suggested any specific changes
> to documents that need discussion.

Correct; I hope my comments will be kept in mind for future work, but
they don't have any ramifications for current documents.

(And, apologies for the misconception about authzids.  I still feel they
should have appeared within the framework and not within mechanisms, but
I was wrong to assume that they were specific to DIGEST-MD5.)

To: [email-masked]
Subject: Agenda items to discuss
Date: Wed, 29 Oct 2003 13:44:05 -0500 (EST)
From: [email-masked] (Sam Hartman)
Sender: [email-masked]

There has been a lot of discussion on the list since the last IETF and
I'm curious which issues actually need meeting time.  I'd appreciate
it if people could suggest issues that still seem to be open.

Thing I think may be open or need discussion are:

* Initial server challenges especially as they interact with SMTP
* Security layer replacement in the base SASL spec
* Authorization ID text (data vs blob, confusion about restriction, etc)
* There was some discussion of multiple layers of encryption (TLS vs security layers) in XMPP; do we want
to develop guidance for protocol designers on this issue?

I think most of the other changes that have been brought forward have
been resolved; please correct me if I'm wrong.  I think Greg's
comments on implementing SASL have not suggested any specific changes
to documents that need discussion.

There's also been a lot of IDN related discussion in the Kerberos
working group.  So far, I don't think any of that discussion affects
saslprep.  If any of those issues do end up affecting saslprep, we may
at least want to be aware of them.  I'll review those discussion
within the next week.

Date: Tue, 28 Oct 2003 16:50:44 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Greg Hudson <[email-masked]>, Sam Hartman <[email-masked]>
cc: [email-masked]
Subject: Re: Some implementor's notes
Sender: [email-masked]

On Tuesday, October 28, 2003 16:13:29 -0500 Greg Hudson <[email-masked]> 
wrote:

>
> On Tue, 2003-10-28 at 15:31, Sam Hartman wrote:
>> I think the only point you raise that I disagree with is the idea that
>> authorization IDs are not important.
>
> And yet, to the best of my knowledge, they are not introduced by any
> mechanism other than DIGEST-MD5.  (Kerberos has multi-level principals,
> but they each have different passwords, so they aren't analagous to
> DIGEST-MD5 authzids.)  They are trivial to support by authenticating and
> then transmitting the desired authzid.  So they should either be part of
> the protocol or part of the SASL framework, but certainly not part of
> SASL mechanisms.

They're not introduced by this mechanism, either.  Authorization identities 
_are_ part of the SASL framework -- a client may optionally specify the 
authorization identity he wishes to assume, independent of the 
authentication identity provided by the mechanism.  It is the 
responsibility of the mechanism to transport the requested authzid, if 
there is one.

-- Jeff

Date: Tue, 28 Oct 2003 16:48:48 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Greg Hudson <[email-masked]>
cc: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: Some implementor's notes
Sender: [email-masked]

On Tue, 28 Oct 2003, Greg Hudson wrote:

> On Tue, 2003-10-28 at 15:31, Sam Hartman wrote:
> > I think the only point you raise that I disagree with is the idea that
> > authorization IDs are not important.
>
> And yet, to the best of my knowledge, they are not introduced by any
> mechanism other than DIGEST-MD5.

In addition to DIGEST-MD5, the PLAIN, KERBEROS_V4, GSSAPI, SRP, and OTP
mechanisms all support authorization identifiers.  This certainly isn't
something completely new introduced by DIGEST-MD5.

> They are trivial to support by authenticating and then transmitting the
> desired authzid.  So they should either be part of the protocol or part
> of the SASL framework, but certainly not part of SASL mechanisms.

I admit that hindsight reveals that it would be nice for SASL to be able
to support authorization ids as part of the framework -- it would solve
the inconsistency introduced by CRAM-MD5.  I don't think we really want to
do this at the application layer either, since that repeats this work for
every SASL application (having application-specific constraints on the
authorization ID, however, would be fine).

However, I don't think we can abandon the current deployed infrastructure
to fix the SASL framework to allow this at this point.

-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: Tue, 28 Oct 2003 21:20:43 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-03.txt
Sender: [email-masked]

[email-masked] wrote:

>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-03.txt
>	Pages		: 11
>	Date		: 2003-10-28	
>  
>
The updated draft deals with most (but not all) issues raised during WG 
Last Call. There are some mostly editorial issues left.

There was a recent discussion on IMAP mailing list about adding examples 
to show how to encode initial response when it is/is not supported by 
the protocol.
I will add this in the next revision.

I am not going to attend IETF in Minneapolis. What is the planned agenda 
for the SASL meeting in Minneapolis?

Cheers,
Alexey
__________________________________________
Isode Limited, http://www.isode.com
__________________________________________

Subject: Re: Some implementor's notes
From: Greg Hudson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Date: Tue, 28 Oct 2003 16:13:29 -0500
Sender: [email-masked]

On Tue, 2003-10-28 at 15:31, Sam Hartman wrote:
> I think the only point you raise that I disagree with is the idea that
> authorization IDs are not important.

And yet, to the best of my knowledge, they are not introduced by any
mechanism other than DIGEST-MD5.  (Kerberos has multi-level principals,
but they each have different passwords, so they aren't analagous to
DIGEST-MD5 authzids.)  They are trivial to support by authenticating and
then transmitting the desired authzid.  So they should either be part of
the protocol or part of the SASL framework, but certainly not part of
SASL mechanisms.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-plain-03.txt
Date: Tue, 28 Oct 2003 15:45:51 -0500
Sender: [email-masked]

--NextPart

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

	Title		: The Plain SASL Mechanism
	Author(s)	: K. Zeilenga
	Filename	: draft-ietf-sasl-plain-03.txt
	Pages		: 9
	Date		: 2003-10-28
	
This document defines a simple clear-text user/password Simple
Authentication and Security Layer (SASL) mechanism called the PLAIN
mechanism.  The PLAIN mechanism intended to be used, in combination
with data confidentiality services provided by a lower layer, in
protocols which lack a simple password authentication command.

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

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-03.txt
Date: Tue, 28 Oct 2003 15:45:43 -0500
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-03.txt
	Pages		: 11
	Date		: 2003-10-28
	
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-03.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-03.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-03.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-03.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-saslprep-04.txt
Date: Tue, 28 Oct 2003 15:45:35 -0500
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		: SASLprep: Stringprep profile for user names and passwords
	Author(s)	: K. Zeilenga
	Filename	: draft-ietf-sasl-saslprep-04.txt
	Pages		: 6
	Date		: 2003-10-28
	
This document describes how to prepare Unicode strings representing
user names and passwords for comparison.  The document defines the
'SASLprep' 'stringprep' profile to be used for both user names and
passwords.  This profile is intended to be used by Simple
Authentication and Security Layer (SASL) mechanisms (such as PLAIN,
CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging user
names and/or passwords.

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

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

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

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

--OtherAccess--

--NextPart--

To: Greg Hudson <[email-masked]>
Cc: [email-masked]
Subject: Re: Some implementor's notes
From: Sam Hartman <[email-masked]>
Date: Tue, 28 Oct 2003 15:31:33 -0500
Sender: [email-masked]

>>>>> "Greg" == Greg Hudson <[email-masked]> writes:
    Greg>   * It introduces the concepts of realms, subsequent
    Greg> authentication, and authorization IDs, none of which seem to
    Greg> be important functionality for a generic shared-secret
    Greg> authentication scheme, and all of which could (I think) be
    Greg> handled out of band.  Fortunately, it's not too difficult to
    Greg> avoid supporting those features.

I think the only point you raise that I disagree with is the idea that
authorization IDs are not important.

I can understand why an implementation might not want to use them, but
I believe they are important for protocols to support and are
something you will tend to want to add over time to an implementation.

To: Alexey Melnikov <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Replacing a SASL security layer
From: Sam Hartman <[email-masked]>
Date: Mon, 27 Oct 2003 16:17:27 -0500
Sender: [email-masked]

>>>>> "Alexey" == Alexey Melnikov <[email-masked]> writes:

    >> I wonder if it might be better to not to change the protocol
    >> but, instead, just document the security consideration.
    >> 
    Alexey> I would like to allow new protocols to allow to deinstall
    Alexey> the security layer when none is negotiated. RFC 2222
    Alexey> prohibits this.  

Why do you want this?

Date: Mon, 27 Oct 2003 12:03:50 -0800
From: Nicolas Williams <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: [I-D ACTION:draft-ietf-nfsv4-channel-bindings-00.txt]
Mail-Followup-To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Followups-To: [email-masked]
Sender: [email-masked]

[Apologies for the cross-post; followups should NOT be cross-posted this
 widely.

 Please Cc ONLY the appropriate WG mailing list(s) on any replies.

 Since I am not subscribed to all of the relevant WGs' mailing lists,
 please Cc me in all replies.]

The NFSv4 WG I-D on channel bindings needs review from several IETF WGs.

This I-D, draft-ietf-nfsv4-channel-bindings-00.txt, goes along with the
soon to be published draft-ietf-nfsv4-ccm-03.txt (currently: -02).

We would appreciate feedback from the Cc'ed WGs on several areas as
requested below.  Please cc the appropriate WG lists only in your
replies.

The I-D announcement is included below, including the I-D Abstract.

Thanks,

Nico

Review requests:

 - From all the cc'ed WGs, the security community in general and the
   [concluded] CAT WG mailing list:

    o Please review the generic definition of "channel bindings" in this
      I-D and the concept of "channel bindings" in general.

   (Use the CAT WG list and/or the NFSv4 WG list.)

 - From the IPSEC WG:

    o Please review the IPsec channel construction in this I-D and the
      relevant interface requirements.

    o Please review the IPsec channel bindings construction.

    (Use the IPSEC WG and/or the IPSP WG lists.)

 - From the IPSP WG:

    o Please review the IPsec channel construction in this I-D and the
      relevant interface requirements.

    (Use the IPSEC WG and/or the IPSP WG lists.)

 - From the IPS WG:

    o Please consider the channel bindings concept as a general solution
      to the problems with the iSCSI approach to security ("authenticate
      at iSCSI layer with x, y or z authentication technology, but
      delegate session integrity/confidentiality protection to IPsec").

      See the introduction (section 1) of this I-D for a description of
      the problem with the iSCSI approach to security.

      (I realize that I'm late to the iSCSI party - my goal is not to
       affect the progression of the iSCSI I-Ds to Proposed Standard and
       publication as RFCs, far from it.)

   (Use the IPS WG list.)

 - From the TLS WG:

    o Please review the construction of channel bindings to TLS channels
      given in this I-D.

   (Use the TLS WG list.)

 - From the SECSH WG:

    o Please review the construction of channel bindings to SSHv2
      channels given in this I-D.

   (Use the SECSH WG list.)

 - From the KRB WG:

    o Please review sections 3.3 and 4.5 of this I-D.

   (Use the KRB WG list.)

 - From the SASL WG:

    o Please review section 3.2 of this I-D.

   (Use the SASL WG list.)

----- Forwarded message from [email-masked] -----

Date: Fri, 24 Oct 2003 10:50:50 -0400
From: [email-masked]
Subject: I-D ACTION:draft-ietf-nfsv4-channel-bindings-00.txt
To: IETF-Announce: ;
Cc: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network File System Version 4 Working Group of the IETF.

	Title		: On the Use of Channel Bindings to Secure Channels
	Author(s)	: N. Williams
	Filename	: draft-ietf-nfsv4-channel-bindings-00.txt
	Pages		: 14
	Date		: 2003-10-23
	
This document defines and formalizes the concept of channel bindings
   to secure layers and defines the actual contents of channel bindings
   for several secure channels.

   The concept of channel bindings allows applications to prove that the
   end-points of two secure channels are the same by binding
   authentication at one network layer to the session protection
   negotiation at a lower network layer.  The use of channel bindings
   allows applications to delegate session protection to lower layers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-channel-bindings-00.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-nfsv4-channel-bindings-00.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-nfsv4-channel-bindings-00.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.

----- End forwarded message -----

To: Hallvard B Furuseth <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments
From: Sam Hartman <[email-masked]>
Date: Mon, 27 Oct 2003 15:02:37 -0500
Sender: [email-masked]

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

    Hallvard> Alexey Melnikov writes:
    >> Hallvard B Furuseth wrote:
    >>> Alexey Melnikov writes:
    >>>> Hallvard B Furuseth wrote:
    >>>>>> 4.1.  Authentication protocol exchange

    >>> Anyway, I think I found the answer in section 6.1.  The
    >>> initial auth command from the client is not part of the
    >>> exchange, but the optional "response" in the auth command is.
    >>> 
    >> Sorry, this makes little sense to me.  Semantically the initial
    >> response *is* part of an authentication exchange.

    Hallvard> That's what I wrote.

    >>>>>> 4.2.  Authorization identities and proxy authentication
    >>>>>> 
>>>>> (...)
>>>>> The character encoding scheme used for transmitting an
    >>>>>> authorization
>>>>> identity over protocol is specified in each authentication
    >>>>>> mechanism
>>>>> (with the authentication mechanism's blob being further
    >>>>> ^^^^
    >>>>> 
    >>>>> What's a blob?  I don't think it's 'something ill-defined or
    >>>>> amorphous', like the dictionary says:-)
    >>>>> 
    >>>> I've changed this to "data".
    >>>  I still don't know _which_ data you are talking about.
    >>> 
    >> Data is defined (and specific to) by each SASL mechanism.

    Hallvard> Is the text in the ()'s just saying that the SASL
    Hallvard> mechanism restricts the data sent between client and
    Hallvard> server to more than just being random strings in the
    Hallvard> character encoding scheme?  Well, of course.  Why
    Hallvard> mention that at all?  If not, I still don't understand
    Hallvard> what this () is saying.

Because you want to make it clear to application protocol designers
and SASL library implementers that mechanisms will be expected to
restrict this data.

To: Alexey Melnikov <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments
From: Sam Hartman <[email-masked]>
Date: Mon, 27 Oct 2003 14:49:10 -0500
Sender: [email-masked]

>>>>> "Alexey" == Alexey Melnikov <[email-masked]> writes:

    Alexey> IMHO, as a server writer, I would do (2) anyway. But of
    Alexey> course this is my personal opinion.

This needs to be left up to individual mechanisms.  The server
definitely should not do this.  I can think of mechanisms where doing
(2) will break signatures of data, etc.

For plain, I would probably do all three as you suggest.

From: Hallvard B Furuseth <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: rfc2831bis: A2 when qop-value=token
Date: Mon, 27 Oct 2003 20:25:07 +0100
Sender: [email-masked]

Alexey Melnikov writes:
>Hallvard B Furuseth wrote:
> 
>>rfc2831bis 2.1.1 "Step One" says:
>>
>>        qop-options       = "qop" "=" <"> qop-list <">
>>        qop-list          = 1#qop-value
>>        qop-value         = "auth" | "auth-int" | "auth-conf" |
>>                             token
>>
>>2.1.2.1 "Response-value" and 2.1.3 "Step Three" define A2 when qop is
>>"auth", "auth-int" and "auth-conf", but not when it is <token>.
> 
> Token is specifically for future extensions, if you see a qop value you 
> don't recognize - you have to ignore it.
> If you recognize nothing, you have to fail the authentication exchange.
> 
> Do you want any clarifications on this to be added to the document.

Not sure.  I think it would be good to mention that 'token is for future
extensions' somewhere.  And perhaps that these extensions must define
A2, since rfc2831bis does not.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: rfc2222bis: re-negotiating SASL security layer
Date: Mon, 27 Oct 2003 20:23:12 +0100
Sender: [email-masked]

Alexey Melnikov writes:
>Hallvard B Furuseth wrote:
> 
>>rfc2222bis section 6.3 "Multiple authentications" says:
>>
>>   If a security layer is in effect
>>   and a subsequent SASL negotiation selects a second security layer,
>>   then the second security layer replaces the first. If a security
>>   layer is in effect and a subsequent SASL negotiation selects no
>>   security layer, the original security layer must be removed.
>>
>>Exactly when is the old layer canceled?
>>
>>If an old layer is active and the client starts to negotiate a new
>>layer, it may not know when to expect the response from the server.
>>So the layer can't be canceled by starting a new negotiation.
>>
> No, the layer can only be cancelled/replaced after a subsequent 
> authentication completes successfully.

OK.  Please mention that explicitly.

> Each profile document must document exactly when this takes place.

'this' = 'it completed successfully', I take it.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments
Date: Mon, 27 Oct 2003 20:21:02 +0100
Sender: [email-masked]

Alexey Melnikov writes:
>Hallvard B Furuseth wrote:
>>Alexey Melnikov writes:
>>>Hallvard B Furuseth wrote:
>>>
>>>>>4.1.  Authentication protocol exchange

>>Anyway, I think I found the answer in section 6.1.  The initial auth
>>command from the client is not part of the exchange, but the optional
>>"response" in the auth command is.
>>
> Sorry, this makes little sense to me.
> Semantically the initial response *is* part of an authentication 
> exchange.

That's what I wrote.

>>>>>4.2.  Authorization identities and proxy authentication
>>>>>
>>>>>  (...)
>>>>>  The character encoding scheme used for transmitting an authorization
>>>>>  identity over protocol is specified in each authentication mechanism
>>>>>  (with the authentication mechanism's blob being further
>>>>                                        ^^^^
>>>>
>>>>What's a blob?  I don't think it's 'something ill-defined or amorphous',
>>>>like the dictionary says:-)
>>>>
>>>I've changed this to "data".
>>
>>I still don't know _which_ data you are talking about.
>>
> Data is defined (and specific to) by each SASL mechanism.

Is the text in the ()'s just saying that the SASL mechanism restricts
the data sent between client and server to more than just being random
strings in the character encoding scheme?  Well, of course.  Why mention
that at all?  If not, I still don't understand what this () is saying.

>>>>And, as I mentioned, there should be an 'Obsoletes: rfc 2222' at the
>>>>top.
>>>>
>>>I've added a sentence about this in the introduction section.
>>
>>I'm pretty sure you will still need to insert the words "Obsoletes: rfc
>>2222" in the header sometime, though I don't remember where this is
>>stated.
>>
> I think this is going to be added by a RFC editor.
> 
> I couldn't find anything saying so.  I did find rfc2223 (Instructions
> to RFC Authors) section 4, which lists 'Obsoletes:' as things it asks
> you to insert.  rfc2223 does say that the RFC Editor may make some
> changes, but preferably as few as possible, and it doesn't mention
> that one.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments
Date: Mon, 27 Oct 2003 20:15:19 +0100
Sender: [email-masked]

Alexey Melnikov writes:
> >>>>> In
> >>>>> order to avoid noninteroperability due to differing normalizations,
> >>>>> when a mechanism specifies that a string authentication identity or
> >>>>> password used as input to a cryptographic function (or used for
> >>>>> comparison) it SHOULD specify that the string first be prepared using
> >>>>> the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm
> >>>>> [StringPrep].
> >>>>
> The new text after that reads:
> 
> There are three entities that has to deal with this issue: a client
> (upon getting user input or retrieving a value from configuration), a server
> (upon receiving the value from the client) and a utility that is able to 
> store
> passwords/hashes in a database that can be later used by the server.
> The preparation must be done by the client and the utility and may be 
> done by the
> server. If preparation fails or results in an empty string, the entity doing
> the preparation SHALL fail the authentication exchange.

I like Kurt's suggestion better: The mechanism must define where
preparation is done.  That way clients using mechanisms like PLAIN can
leave as much work as possible to the server.

>>> Alexey, the current text suggests that client (1) prep the
>>> value before sending, the server then preps it (2) again
>>> (before comparing it to the store value, which also should
>>> be prep'ed (3) either before storing it or before each compare).
>>
>> Ok, I am with you now.
>>
>> IMHO, as a server writer, I would do (2) anyway. But of course this is
>> my personal opinion.

I see no reason to prepare a string which we know already has been
prepared (if the client works correctly).  I guess it doesn't hurt to
allow that, but what you are saying is that if the client sends
incorrect data (it doesn't prepare when it should do so), auth on your
server would succeed anyway.  Put that way, I'm not sure if that is a
bug or a feature.

BTW, the server can't do (2) with mechanisms like DIGEST-MD5, where it
never sees the plain password from the client.  I got that wrong too
in my original message.

>>> We should not suggest that mechanisms should do both (1) and
>>> (2).  (1) and (3) OR (2) or (3) are sufficient to ensure
>>> proper matching.
>>
>> IMHO, this is a responsibility of the client,

Disagree.  It's the responsibility of the mechanism defintion to say
where it should happen.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: rfc2831bis issues
Date: Mon, 27 Oct 2003 20:03:47 +0100
Sender: [email-masked]

Alexey Melnikov writes:
>Hallvard B Furuseth wrote:
> 
>>>1.1  Conventions and Notation
>>>
>>>   This specification uses the same ABNF notation and lexical
>>>   conventions as HTTP/1.1 specification; see section 7.
>>
>>...as well as some named rules defined there (section 7.2).
>>
> 7 implies 7.2.

True.  Please add '...and named rules', though.  Those are not notation
or lexical conventions.

>>>   The value of a quoted string constant as an octet string does not
>>>   include any terminating null character
>>
>>...which the C language adds.
>>
>>[For readers who don't know C, if any.]
>>  
> IMHO, readers who don't know C will not care about this comment anyway, 
> because it doesn't add any additional information.

Disagree.  For such readers, this comment adds a confusing reference to
a null character which they can't find elsewhere in the draft.
It might be better to just delete the sentence, though.

>>>2.1.1  Step One
>>>
>>>   The server starts by sending a challenge.
>>
>>How does it know that it should do that?
>>
> The client always starts first (according to SASL). If the client 
> doesn't includes an initial response, the server will know.
> 
> Can you suggest any clarification text here?

'The server starts by sending a challenge after the client indicates
that SASL negotiatin should start'?

>>>2.1.2  Step Two

>>>   authzid
>>>    
>>>
>>>      The server SHOULD verify the correctness of an authzid as
>>>      specified by the corresponding SASL protocol profile.
>>>    
>>>
>>
>>Which corresponding SASL profile?
>>
> I meant that any protocol using SASL should verify authorization 
> identity as specified in the SASL profile for the protocol. Any 
> suggestion how to make this clear?

Using your words,

         The server SHOULD verify the correctness of an authzid as
         specified by the SASL profile for the protocol.

>>>2.2  Subsequent Authentication
>>>
>>>   If the client has previously authenticated to the server, and
>>>   remembers the values of username, realm, nonce, nonce-count, cnonce,
>>                            ^^^^^^^^
>>>   and qop that it used in that authentication, and the SASL profile for
>>>   a protocol permits an initial client response, then it MAY perform
>>>   "subsequent authentication", as defined in this section.
>>
>>What's the point of authenticating again with the same username?  Auth
>>with a _different_ username would be more interesting.
>>
> This is a case of fast reauthentication using a different TCP 
> connection. This is similar to resuming a TLS session.

Oh.  Could you add 'even after closing the connection and reopening a
new one' in section 2.2?

>>>2.2.2  Step Two
>>>    
>>>   If the response is valid, (...)
>>
>>I don't understand the text starting with "or from any o".
>>
> The text in my copy says:
> 
> (...)

Thanks.

> So I am not sure where have you found this.

It's in
http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2831bis-02.txt.

>>>   Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the
>>>   received value; the message is discarded if they differ.
>>> (...)
>>
> This whole section talks about protecting data when authentication is 
> already complete.

Not in the published draft.  There, this sentence occurs in section
2.2.2.  But there is no section between 2.2.2 and 2.4, so I guess this
part of the published draft got garbled.

>>>7.2   Basic Rules
>>
>>>       OCTET          = <any 8-bit character>
>>
>>s/character/byte/, I think.
>>
> I actually disagree in this case. A byte has 8 bits by definition.

No it hasn't.  That's why the term 'octet' was invented.  A byte is an
addressable machine unit, which is _usually_ 8 bits nowadays.

>>  A byte in a multi-byte UTF-8 character
>>is not normally considered a character.
>>
> I am not talking about Unicode characters here.

A 'character' is part of a character set.  Which character set is it
supposed to be part of here, if not UTF-8?

Maybe you are thinking of C, where the 'byte' type is called (unsigned)
char?

-- 
Hallvard

Date: Sun, 26 Oct 2003 20:31:46 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: rfc2831bis issues
Sender: [email-masked]

Hallvard B Furuseth wrote:

>Here are various editorial and non-editorial comments for
>draft-ietf-sasl-rfc2831bis-02.txt.
>  
>
>>Table of Contents
>>    
>>
>>    3.8 CBC MODE ATTACKS.............................................
>>    
>>
>
>Missing page number.
>
Yes, I was lazy.
I was changing text a lot, so I had to spend a lot of time fixing page 
numbers when doing each revision. So I just gave up.

>>1.1  Conventions and Notation
>>    
>>
>>   This specification uses the same ABNF notation and lexical
>>   conventions as HTTP/1.1 specification; see section 7.
>>    
>>
>
>...as well as some named rules defined there (section 7.2).
>
7 implies 7.2.

>>   The value of a quoted string constant as an octet string does not
>>   include any terminating null character
>>    
>>
>
>...which the C language adds.
>
>[For readers who don't know C, if any.]
>  
>
IMHO, readers who don't know C will not care about this comment anyway, 
because it doesn't add any additional information.

>>2.1.1  Step One
>>
>>   The server starts by sending a challenge.
>>    
>>
>
>How does it know that it should do that?
>
The client always starts first (according to SASL). If the client 
doesn't includes an initial response, the server will  know.

Can you suggest any clarification text here?

>>   nonce
>>      Note
>>      that since the string is passed as a quoted string, the
>>      double-quote
>>    
>>
>
>and backslash?
>
Actually, I've changed ABNF to disallow double-quotes or backslashes.
So, this should be removed.

>>      character is not allowed unless escaped (see section
>>      7.2).
>>    
>>
>
>I think this applies to other quoted strings than the nonce.
>
Yes, but it is especially problematic for nonces, as people just 
generate binary data and than forget to quote it.

>>   server_maxbuf ("maximal ciphertext buffer size")
>>    
>>
>
>  
>
>>      Let call "maximal cleartext buffer size" (or "maximal sender
>>      size") the maximal size of a cleartext buffer that, after being
>>    
>>
>
>"Let call"?  Should be "Call", or "Let .... be", I think.
>
Ok.

>>   charset
>>      This directive, if present, specifies that the server supports
>>      UTF-8 [UTF-8] encoding for the username, realm and password. If
>>      present, the username, realm and password are in Unicode, prepared
>>      using the "SASLPrep" profile [SASLPrep] of the "stringprep"
>>      algorithm [StringPrep] and than encoded as UTF-8 [UTF-8].  If not
>>      present, the username, realm and password MUST be encoded in ISO
>>      8859-1 [ISO-8859] (of which US-ASCII [USASCII] is a subset).
>>    
>>
>
>There is no username and password sent by the server.  Do you mean the
>_client_ MUST send them in UTF-8 if "charset" is given by the server?
>
Yes.

>>   cipher-opts
>>    
>>
>>      "qop-options" directive, in which case the "3des" cipher is
>>      mandatory-to-implement.
>>    
>>
>
>I suggest you remove the "-"s in mandatory-to-implement.
>
This is a term used in SASL. By using "-" I am trying to emphasize this.

>>2.1.2  Step Two
>>    
>>
>>   digest-uri
>>      Indicates the principal name of the service with which the client
>>      wishes to connect, formed from the serv-type, host, and serv-name.
>>      For example, the FTP service on "ftp.example.com" would have a
>>      "digest-uri" value of "ftp/ftp.example.com"; the SMTP server from
>>      the example above would have a "digest-uri" value of
>>      "SMTP/mail3.example.com/example.com".
>>
>>   Servers SHOULD check that the supplied value is correct. This will
>>   detect accidental connection to the incorrect server, as well as some
>>   redirection attacks. It is also so that clients will be trained to
>>   provide values that will work with implementations that use a shared
>>   back-end authentication service that can provide server
>>   authentication.
>>
>>   The serv-type component should match the service being offered. The
>>   host component should match one of the host names of the host on
>>   which the service is running, or it's IP address. Servers SHOULD NOT
>>   normally support the IP address form, because server authentication
>>   by IP address is not very useful; they should only do so if the DNS
>>   is unavailable or unreliable. The serv-name component should match
>>   one of the service's configured service names.
>>
>>   This directive may appear at most once; if multiple instances are
>>   present, the client should abort the authentication exchange.
>>
>>   Note: In the HTTP use of Digest authentication, the digest-uri is the
>>   URI (usually a URL) of the resource requested -- hence the name of
>>   the directive.
>>    
>>
>
>Is this entire section about digest-uri?  If so, most of it should be
>indented.
>  
>
>>   authzid
>>    
>>
>>      The server SHOULD verify the correctness of an authzid as
>>      specified by the corresponding SASL protocol profile.
>>    
>>
>
>Which corresponding SASL profile?
>
I meant that any protocol using SASL should verify authorization 
identity as specified in the SASL profile for the protocol. Any 
suggestion how to make this clear?

>>2.2  Subsequent Authentication
>>
>>   If the client has previously authenticated to the server, and
>>   remembers the values of username, realm, nonce, nonce-count, cnonce,
>>    
>>
>                             ^^^^^^^^
>  
>
>>   and qop that it used in that authentication, and the SASL profile for
>>   a protocol permits an initial client response, then it MAY perform
>>   "subsequent authentication", as defined in this section.
>>    
>>
>
>What's the point of authenticating again with the same username?  Auth
>with a _different_ username would be more interesting.
>
This is a case of fast reauthentication using a different TCP 
connection. This is similar to resuming a TLS session.

>>2.2.2  Step Two
>>    
>>
>>   If the response is valid, the server MAY choose to deem that
>>   authentication has succeeded. However, if it has been too long since
>>   the previous authentication, or for any o including the next
>>   subsequent authentication, between the client and the server MUST be
>>   integrity protected.
>>    
>>
>
>I don't understand the text starting with "or from any o".
>
The text in my copy says:

If the response is valid, the server MAY choose to deem that
authentication has succeeded. However, if it has been too long since the
previous authentication, or for any other reason, the server MAY send a
new "digest-challenge" with a new value for nonce. The challenge MAY
contain a "stale" directive with value "true", which says that the
client may respond to the challenge using the password it used in the
previous response; otherwise, the client must solicit the password anew
from the user. This permits the server to make sure that the user has
presented their password recently. (The directive name refers to the
previous nonce being stale, not to the last use of the password.) Except
for the handling of "stale", after sending the "digest-challenge"
authentication proceeds as in the case of initial authentication.

So I am not sure where have you found this.

>>   Using as a base session key the value of H(A1)
>>   as defined above
>>    
>>
>
>need a "," here
>
Ok.

>>   Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the
>>   received value; the message is discarded if they differ.
>>
>> The
>>   receiver's sequence counter is incremented if they match.
>>    
>>
>
>Doesn't the server send a response?  How does the client know that the
>authentication is completed?
>
This whole section talks about protecting data when authentication is 
already complete.

> ...
>
>>5.1   Normative references
>>    
>>
>>   [RFC 2222] Myers, J., "Simple Authentication and Security Layer
>>              (SASL)", RFC 2222, October 1997.
>>    
>>
>
>Should be [SASL] draft-ietf-sasl-rfc2222bis-02.txt.
>
Fixed, thanks.

>... 
>
>>        ( *LWS element *( *LWS "," *LWS element ))
>>    
>>
>
>Should this really be asymmetric, or should it be
>          (      element *( *LWS "," *LWS element ))
>or
>          ( *LWS element *( *LWS "," *LWS element ) *LWS )
>
I can go for the last proposal. At least it seems to be the original intent.

>?
>
>  
>
>>7.2   Basic Rules
>>    
>>
>
>  
>
>>       OCTET          = <any 8-bit character>
>>    
>>
>
>s/character/byte/, I think.
>
I actually disagree in this case. A byte has 8 bits by definition.

>  A byte in a multi-byte UTF-8 character
>is not normally considered a character.
>
I am not talking about Unicode characters here.

Thank you for your comments. In the meantime I will work (and think 
more) on the rest of them.

Regards,

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-nystrom-http-sasl-08.txt
Date: Thu, 23 Oct 2003 09:14:01 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: SASL in HTTP/1.1
	Author(s)	: M. Nystrom, A. Melnikov
	Filename	: draft-nystrom-http-sasl-08.txt
	Pages		: 37
	Date		: 2003-10-22
	
This memo suggest the use of SASL [RFC2222] as a framework to enable
the use of strong authentication mechanisms in http/1.1 [RFC2616],
and defines one approach to accomplish this.
Please send comments on this document to the relevant mailing lists,
e.g. [email-masked].

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

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

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

--OtherAccess--

--NextPart--

Date: Sat, 18 Oct 2003 21:10:36 +0100
From: Alexey Melnikov <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
CC: [email-masked]
Subject: Re: malformed messages (Re: draft-ietf-sasl-anon-01.txt)
Sender: [email-masked]

Kurt D. Zeilenga wrote:

>Simon raised this issue to me privately... but I think it needs
>broader discussion (given that it is a technical issue).
>
>At 02:19 PM 10/2/2003, Simon Josefsson wrote:
>  
>
>>* The document doesn't mandate any specific action when the client
>> send an invalid string (e.g., one that is rejected by string
>> processing).
>>    
>>
>
>That is, what should the implementation do if the message it receives
>is malformed?
>
>I note that this issue is likely not unique to ANONYMOUS.  So, maybe
>it should be dealt with in base SASL specification.
>
>I'm thinking a malformed message should be treated as a protocol
>error in the application protocol.
>
I agree. However, can you be more specific what do you want me to add to 
the base spec.

Alexey

Date: Sat, 18 Oct 2003 21:06:44 +0100
From: Alexey Melnikov <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
CC: Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments
Sender: [email-masked]

>
>
>>>>> In
>>>>> order to avoid noninteroperability due to differing normalizations,
>>>>> when a mechanism specifies that a string authentication identity or
>>>>> password used as input to a cryptographic function (or used for
>>>>> comparison) it SHOULD specify that the string first be prepared using
>>>>> the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm
>>>>> [StringPrep].
>>>>
The new text after that reads:

There are three entities that has to deal with this issue: a client
(upon getting user input or retrieving a value from configuration), a server
(upon receiving the value from the client) and a utility that is able to 
store
passwords/hashes in a database that can be later used by the server.
The preparation must be done by the client and the utility and may be 
done by the
server. If preparation fails or results in an empty string, the entity doing
the preparation SHALL fail the authentication exchange.

>>>>> This should be done by both the client (upon getting
>>>>> user input or retrieving a value from configuration) and by the
>>>>> server (upon receiving the value from the client). 
>>>>>       
>>>>
>>>> What's the point of this duplicate preparation?  Why not do it only
>>>> at the server side?
>>>
>>> Because if the client doesn't do that, the hash calculated on the 
>>> server will not match the one calculated on the client.    
>>
>> Alexey, the current text suggests that client (1) prep the
>> value before sending, the server then preps it (2) again
>> (before comparing it to the store value, which also should
>> be prep'ed (3) either before storing it or before each compare).
>
> Ok, I am with you now.
>
> IMHO, as a server writer, I would do (2) anyway. But of course this is 
> my personal opinion.
>
> However there is one case when all three may make sense. Imagine that 
> there are two clients that use PLAIN.
> One of the prepares username/password, the other one doesn't. If the 
> server also does preparation, it will be able to interoperate with 
> both clients.
>
>> We need to REQUIRE that mechanisms specify how character strings
>> are to be prepared for comparison and RECOMMEND that they use
>> SASLprep for simple user names and passwords.
>>
>> We should not suggest that mechanisms should do both (1) and
>> (2).  (1) and (3) OR (2) or (3) are sufficient to ensure
>> proper matching.
>
> IMHO, this is a responsibility of the client, so I will clarify that. 
> But I will add that the server "MAY prepare".

Alexey

Date: Sat, 18 Oct 2003 20:56:55 +0100
From: Alexey Melnikov <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
CC: Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments
Sender: [email-masked]

Kurt D. Zeilenga wrote:

>At 04:52 AM 10/8/2003, Alexey Melnikov wrote:
>  
>
>>>> In
>>>> order to avoid noninteroperability due to differing normalizations,
>>>> when a mechanism specifies that a string authentication identity or
>>>> password used as input to a cryptographic function (or used for
>>>> comparison) it SHOULD specify that the string first be prepared using
>>>> the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm
>>>> [StringPrep].  This should be done by both the client (upon getting
>>>> user input or retrieving a value from configuration) and by the
>>>> server (upon receiving the value from the client).
>>>>  
>>>>        
>>>>
>>>What's the point of this duplicate preparation?  Why not do it only
>>>at the server side?
>>>
>>>      
>>>
>>Because if the client doesn't do that, the hash calculated on the server will not match the one calculated on the client.     
>>
>
>Alexey, the current text suggests that client (1) prep the
>value before sending, the server then preps it (2) again
>(before comparing it to the store value, which also should
>be prep'ed (3) either before storing it or before each compare).
>
Ok, I am with you now.

IMHO, as a server writer, I would do (2) anyway. But of course this is 
my personal opinion.

However there is one case when all three may make sense. Imagine that 
there are two clients that use PLAIN.
One of the prepares username/password, the other one doesn't. If the 
server also does preparation, it will be able to interoperate with both 
clients.

>
>We need to REQUIRE that mechanisms specify how character strings
>are to be prepared for comparison and RECOMMEND that they use
>SASLprep for simple user names and passwords.
>
>We should not suggest that mechanisms should do both (1) and
>(2).  (1) and (3) OR (2) or (3) are sufficient to ensure
>proper matching.
>
IMHO, this is a responsibility of the client, so I will clarify that. 
But I will add that the server "MAY prepare".

Alexey

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

Cell: +44 7753759732

IETF standard related pages:
http://orthanc.ab.ca/mel/devel/Links.html

Personal Home Page: http://orthanc.ab.ca/mel
__________________________________________

Date: Sat, 18 Oct 2003 15:50:45 +0100
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments
Sender: [email-masked]

Hallvard B Furuseth wrote:

>Alexey Melnikov writes:
>  
>
>>Hallvard B Furuseth wrote:
>>    
>>
>>>>4.1.  Authentication protocol exchange
>>>>
>>>>  A SASL mechanism is responsible for conducting an authentication
>>>>  protocol exchange.  This consists of a series of server challenges
>>>>  and client responses,    
>>>>
>>>>        
>>>>
>>>Does this mean that the initial auth command from the client is not
>>>considered part of the authentication protocol exchange?
>>>
>>>      
>>>
>>Does it matter in this section?    
>>
>
>Well, that's where "authentication protocol exchange" seems to be
>defined.  It matters if other documents refer to "the authentication
>protocol exchange".
>
>Anyway, I think I found the answer in section 6.1.  The initial auth
>command from the client is not part of the exchange, but the optional
>"response" in the auth command is.
>
Sorry, this makes little sense to me.
Semantically the initial response *is* part of an authentication 
exchange. It is just an optimization to avoid a round trip.

>>>>4.2.  Authorization identities and proxy authentication
>>>>
>>>>  (...)
>>>>  The character encoding scheme used for transmitting an authorization
>>>>  identity over protocol is specified in each authentication mechanism
>>>>  (with the authentication mechanism's blob being further
>>>>        
>>>>
>>>                                        ^^^^
>>>
>>>What's a blob?  I don't think it's 'something ill-defined or amorphous',
>>>like the dictionary says:-)
>>>      
>>>
>>I've changed this to "data".
>>    
>>
>
>I still don't know _which_ data you are talking about.
>  
>
Data is defined (and specific to) by each SASL mechanism.

>>>And, as I mentioned, there should be an 'Obsoletes: rfc 2222' at the
>>>top.
>>>
>>>      
>>>
>>I've added a sentence about this in the introduction section.
>>    
>>
>
>I'm pretty sure you will still need to insert the words "Obsoletes: rfc
>2222" in the header sometime, though I don't remember where this is
>stated.
>
I think this is going to be added by a RFC editor.

Regards,
Alexey

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

Cell: +44 7753759732

IETF standard related pages:
http://orthanc.ab.ca/mel/devel/Links.html

Personal Home Page: http://orthanc.ab.ca/mel
__________________________________________

Date: Wed, 15 Oct 2003 12:52:04 +0100
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: rfc2222bis: re-negotiating SASL security layer
Sender: [email-masked]

Hallvard B Furuseth wrote:

>rfc2222bis section 6.3 "Multiple authentications" says:
>
>   If a security layer is in effect
>   and a subsequent SASL negotiation selects a second security layer,
>   then the second security layer replaces the first. If a security
>   layer is in effect and a subsequent SASL negotiation selects no
>   security layer, the original security layer must be removed.
>
>Exactly when is the old layer canceled?
>
>If an old layer is active and the client starts to negotiate a new
>layer, it may not know when to expect the response from the server.
>So the layer can't be canceled by starting a new negotiation.
>
No, the layer can only be cancelled/replaced after a subsequent 
authentication completes successfully.
Each profile document must document exactly when this takes place.

A subsuquent authentication takes place while an old security layer is 
still in effect.

>It could be canceled after receipt of the first response from the
>server.  Or after the completed SASL negotiation, which would be
>performed with the old layer in effect.  I don't know how easy that
>would be to implement, or if it would interfere with the definitions of
>some SASL mechanisms to have two mechanisms active at the same time.
>
>Another way would for the layers themselves contain a 'cancel layer'
>operation, which may only be used just before negotiating a new layer
>and before closing the connection.  Then the SASL negotiation could be
>performed without mixing the old and the new SASL mechanism, and the
>layer could only be re-negotiated if the old layer had such a 'cancel
>layer' operation.
>  
>
Alexey
__________________________________________
Isode Limited, http://www.isode.com

Cell: +44 7753759732

IETF standard related pages:
http://orthanc.ab.ca/mel/devel/Links.html

Personal Home Page: http://orthanc.ab.ca/mel
__________________________________________

Date: Wed, 15 Oct 2003 12:33:31 +0100
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: rfc2831bis: A2 when qop-value=token
Sender: [email-masked]

Hallvard B Furuseth wrote:

>rfc2831bis 2.1.1 "Step One" says:
>
>        qop-options       = "qop" "=" <"> qop-list <">
>        qop-list          = 1#qop-value
>        qop-value         = "auth" | "auth-int" | "auth-conf" |
>                             token
>
>2.1.2.1 "Response-value" and 2.1.3 "Step Three" define A2 when qop is
>"auth", "auth-int" and "auth-conf", but not when it is <token>.
>
Hi Hallvard,

Token is specifically for future extensions, if you see a qop value you 
don't recognize - you have to ignore it.
If you recognize nothing, you have to fail the authentication exchange.

Do you want any clarifications on this to be added to the document.

(I will go through your big message over weekend).

Cheers,
Alexey
__________________________________________
Isode Limited, http://www.isode.com

Cell: +44 7753759732

IETF standard related pages:
http://orthanc.ab.ca/mel/devel/Links.html

Personal Home Page: http://orthanc.ab.ca/mel
__________________________________________

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: rfc2222bis: re-negotiating SASL security layer
Date: Wed, 15 Oct 2003 13:31:17 +0200
Sender: [email-masked]

rfc2222bis section 6.3 "Multiple authentications" says:

   If a security layer is in effect
   and a subsequent SASL negotiation selects a second security layer,
   then the second security layer replaces the first. If a security
   layer is in effect and a subsequent SASL negotiation selects no
   security layer, the original security layer must be removed.

Exactly when is the old layer canceled?

If an old layer is active and the client starts to negotiate a new
layer, it may not know when to expect the response from the server.
So the layer can't be canceled by starting a new negotiation.

It could be canceled after receipt of the first response from the
server.  Or after the completed SASL negotiation, which would be
performed with the old layer in effect.  I don't know how easy that
would be to implement, or if it would interfere with the definitions of
some SASL mechanisms to have two mechanisms active at the same time.

Another way would for the layers themselves contain a 'cancel layer'
operation, which may only be used just before negotiating a new layer
and before closing the connection.  Then the SASL negotiation could be
performed without mixing the old and the new SASL mechanism, and the
layer could only be re-negotiated if the old layer had such a 'cancel
layer' operation.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: rfc2831bis: A2 when qop-value=token
Date: Wed, 15 Oct 2003 12:58:19 +0200
Sender: [email-masked]

rfc2831bis 2.1.1 "Step One" says:

        qop-options       = "qop" "=" <"> qop-list <">
        qop-list          = 1#qop-value
        qop-value         = "auth" | "auth-int" | "auth-conf" |
                             token

2.1.2.1 "Response-value" and 2.1.3 "Step Three" define A2 when qop is
"auth", "auth-int" and "auth-conf", but not when it is <token>.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: rfc2831bis issues
Date: Tue, 14 Oct 2003 22:41:33 +0200
Sender: [email-masked]

Here are various editorial and non-editorial comments for
draft-ietf-sasl-rfc2831bis-02.txt.

> Table of Contents

>     3.8 CBC MODE ATTACKS.............................................

Missing page number.

> 1.1  Conventions and Notation

>    This specification uses the same ABNF notation and lexical
>    conventions as HTTP/1.1 specification; see section 7.

...as well as some named rules defined there (section 7.2).

>    The value of a quoted string constant as an octet string does not
>    include any terminating null character

...which the C language adds.

[For readers who don't know C, if any.]

> 2.1.1  Step One
>
>    The server starts by sending a challenge.

How does it know that it should do that?

>    nonce
>       Note
>       that since the string is passed as a quoted string, the
>       double-quote

and backslash?

>       character is not allowed unless escaped (see section
>       7.2).

I think this applies to other quoted strings than the nonce.

>    server_maxbuf ("maximal ciphertext buffer size")

>       Let call "maximal cleartext buffer size" (or "maximal sender
>       size") the maximal size of a cleartext buffer that, after being

"Let call"?  Should be "Call", or "Let .... be", I think.

>    charset
>       This directive, if present, specifies that the server supports
>       UTF-8 [UTF-8] encoding for the username, realm and password. If
>       present, the username, realm and password are in Unicode, prepared
>       using the "SASLPrep" profile [SASLPrep] of the "stringprep"
>       algorithm [StringPrep] and than encoded as UTF-8 [UTF-8].  If not
>       present, the username, realm and password MUST be encoded in ISO
>       8859-1 [ISO-8859] (of which US-ASCII [USASCII] is a subset).

There is no username and password sent by the server.  Do you mean the
_client_ MUST send them in UTF-8 if "charset" is given by the server?

>    cipher-opts

>       "qop-options" directive, in which case the "3des" cipher is
>       mandatory-to-implement.

I suggest you remove the "-"s in mandatory-to-implement.

> 2.1.2  Step Two

>    digest-uri
>       Indicates the principal name of the service with which the client
>       wishes to connect, formed from the serv-type, host, and serv-name.
>       For example, the FTP service on "ftp.example.com" would have a
>       "digest-uri" value of "ftp/ftp.example.com"; the SMTP server from
>       the example above would have a "digest-uri" value of
>       "SMTP/mail3.example.com/example.com".
>
>    Servers SHOULD check that the supplied value is correct. This will
>    detect accidental connection to the incorrect server, as well as some
>    redirection attacks. It is also so that clients will be trained to
>    provide values that will work with implementations that use a shared
>    back-end authentication service that can provide server
>    authentication.
>
>    The serv-type component should match the service being offered. The
>    host component should match one of the host names of the host on
>    which the service is running, or it's IP address. Servers SHOULD NOT
>    normally support the IP address form, because server authentication
>    by IP address is not very useful; they should only do so if the DNS
>    is unavailable or unreliable. The serv-name component should match
>    one of the service's configured service names.
>
>    This directive may appear at most once; if multiple instances are
>    present, the client should abort the authentication exchange.
>
>    Note: In the HTTP use of Digest authentication, the digest-uri is the
>    URI (usually a URL) of the resource requested -- hence the name of
>    the directive.

Is this entire section about digest-uri?  If so, most of it should be
indented.

>    authzid

>       The server SHOULD verify the correctness of an authzid as
>       specified by the corresponding SASL protocol profile.

Which corresponding SASL profile?

> 2.2  Subsequent Authentication
>
>    If the client has previously authenticated to the server, and
>    remembers the values of username, realm, nonce, nonce-count, cnonce,
                             ^^^^^^^^
>    and qop that it used in that authentication, and the SASL profile for
>    a protocol permits an initial client response, then it MAY perform
>    "subsequent authentication", as defined in this section.

What's the point of authenticating again with the same username?  Auth
with a _different_ username would be more interesting.

> 2.2.2  Step Two

>    If the response is valid, the server MAY choose to deem that
>    authentication has succeeded. However, if it has been too long since
>    the previous authentication, or for any o including the next
>    subsequent authentication, between the client and the server MUST be
>    integrity protected.

I don't understand the text starting with "or from any o".

>    Using as a base session key the value of H(A1)
>    as defined above

need a "," here

>    Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the
>    received value; the message is discarded if they differ. The
>    receiver's sequence counter is incremented if they match.

Doesn't the server send a response?  How does the client know that the
authentication is completed?

> 2.4   Confidentiality Protection
>
>    If the server sent a "cipher-opts" directive and the client responded
>    with a "cipher" directive, then subsequent messages between the
>    client and the server MUST be confidentiality protected.

What is confidentiality protection?

>    The IV used to send/receive the initial buffer

You might say "Initialization Vector (IV)" again here, it's been a while
since you mentined what an IV is.

>    SEAL(Ki, Kc, SeqNum, msg) =
>          {CIPHER(Kc, {msg, pad, HMAC(Ki, {SeqNum, msg})[0..9]}), 0x0001,
>           SeqNum}

SEAL?  That is never used in this document.

> 5.1   Normative references

>    [RFC 2222] Myers, J., "Simple Authentication and Security Layer
>               (SASL)", RFC 2222, October 1997.

Should be [SASL] draft-ietf-sasl-rfc2222bis-02.txt.

>    [Unicode] The Unicode Consortium, "The Unicode Standard, Version

Indent "The".

>    [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646", RFC
>               2279, Janyary 1998.

Indent "Yergeau".

>    [RFC 2732]  Hinden, R., Carpenter, B., Masinter, L., "Format for

Unindent "Hinden".

>    [FIPS] National Institute of Standards and Technology, "DES Modes of

Indent "National".

>    [AES] Daemen, J., Rijmen, V., "The Rijndael Block Cipher",

Indent "Daemen".

> 5.2   Informative references

>    [MD5]  Kaliski, B.,Robshaw, M., "Message Authentication with MD5",

Indent "Kaliski".

>    [TLS-CBC] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:

Indent "Moeller".

> 7.1   Augmented BNF

Since <"> means to enclose a literal, you might replace other <">s with
<'>s in this section.  E.g.

>    rule1 | rule2
>       Elements separated by a bar ("|") are alternatives, e.g., "yes |
>       no" will accept yes or no.

        Elements separated by a bar ('|') are alternatives, e.g., 'yes |
        no' will accept yes or no.

>    #rule

>         ( *LWS element *( *LWS "," *LWS element ))

Should this really be asymmetric, or should it be
          (      element *( *LWS "," *LWS element ))
or
          ( *LWS element *( *LWS "," *LWS element ) *LWS )
?

> 7.2   Basic Rules

>        OCTET          = <any 8-bit character>

s/character/byte/, I think.  A byte in a multi-byte UTF-8 character
is not normally considered a character.

> 8  Sample Code

>         for (scan = base; scan < end; ++scan) {
>             if (*scan > 0xC3) break; /* abort if outside 8859-1 */
>             if (*scan >= 0xC0 && *scan <= 0xC3) {
>                 if (++scan == end || *scan < 0x80 || *scan > 0xBF)
>                     break;

                  /*
                   * Handle invalid UTF-8-like sequences, e.g. '\0'
                   * encoded as "\xC0\x80".   Accepting such sequences
                   * is a security risk, according to [UTF-8].
                   */
                  if (*scan < 0xC2)
                      return an error or something;

Error return also requires the return type of the function to be
changed, and a 'return success' at the end.  Maybe another way is to
simply not translate invalid UTF-8 strings to iso8859-1.

This should also be discussed in the section which says that UTF-8
should be converted to iso8859-1 when possible.

>             }
>         }

-- 
Hallvard

Content-class: urn:content-classes:message
Subject: RE: Some implementor's notes
Date: Tue, 14 Oct 2003 11:55:33 -0700
From: "Paul Leach" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>, "Greg Hudson" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00A0_01C3924A.12E99900
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

SASL's version of Digest has that clunky syntax so that it is possible to
share an implementation with HTTP digest. HTTP digest couldn't get cleaned
up when HTTP 1.1 was being worked on because some people claimed there were
significant deployments of an earlier version.

The "subsequent auth" feature was a request from client authors of apps
where reconnects are frequent and the desire was to make them efficient.
(POP3 clients are or used to be typical examples.)

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alexey Melnikov
> Sent: Tuesday, October 14, 2003 3:37 AM
> To: Greg Hudson
> Cc: [email-masked]
> Subject: Re: Some implementor's notes
> 
> 
> Greg Hudson wrote:
> 
> >...
> >
> >First, I looked into CRAM-MD5.  It doesn't authenticate the 
> server and 
> >it doesn't leave the window open for stream protection, but those 
> >issues aren't critical.  I found the following sources of hidden
> >complexity:
> >
> >...
> >
> >  * The current draft mandates the use of RFC 3454, a 91-page RFC I
> >    don't understand and which does not look trivial to implement.
> >    I'm sure there are real issues with internationalized usernames
> >    and passwords, but the blow-up in complexity seems astounding.
> >
> I have to disappoint you, but DIGEST-MD5 requires RFC 3454 as 
> well (at least it will when I publish a new revision)
> 
> >
> >Faced with these problems and a general sense of guilt at 
> the idea of 
> >implementing a weak system, I turned to DIGEST-MD5.  I found 
> that while 
> >DIGEST-MD5 is much more elegant than CRAM-MD5 in how it computes the 
> >digests, it comes with a burdensome level of complexity which is 
> >unrelated to its conceptual security properties.  In particular:
> >
> >  * It introduces the concepts of realms, subsequent authentication,
> >    and authorization IDs, none of which seem to be important
> >    functionality for a generic shared-secret authentication scheme,
> >    and all of which could (I think) be handled out of band.
> >    Fortunately, it's not too difficult to avoid supporting those
> >    features.
> >
> >  * Messages are composed of key-value pairs which do not obey a
> >    consistent syntax for the value, so parsing them is hard.  (I'm
> >    not convinced that Cyrus's implementation is correct, 
> particularly
> >    for skipping over auth-param values.)
> >
> I suggest you try to find a case that breaks stuff. It is 
> more constructive than saying that something doesn't (or may 
> not) work.
> 
> >  * Length-counted strings would be easier to parse than quoted
> >    strings while remaining human-readable.
> >
> >  * Implicit allowance for linear whitespace has no intrinsic value
> >    and renders implementations more complicated and error-prone.
> >
> Yes. There are historical reasons why this happened.
> It was a compromise between design and something that could 
> have been implemented by one big vendor.
> It was supposed to become a replacement for another seriously 
> broken SASL mechanism NTLM.
> 
> >  * It is not specified whether the serv-type, host, and digest-uri
> >    values are required.
> >
> They are required to be sent, but the receiver SHOULD (but 
> not required
> to) verify it. If the text is not clear, let me know and I 
> will try to fix it.
> 
> >  (Cyrus treats digest-uri as required but not
> >    the other two, probably because it's not specified what 
> you should
> >    do with an unspecified digest-uri when computing the 
> digests.)  It
> >    is not made clear what security value, if any, these parameters
> >    have; to "detect accidental connection to the incorrect 
> server" is
> >    not an important function for an authentication scheme.
> >
> >  * The UTF-8 to ISO 8859-1 recoding of usernames and passwords seems
> >    like a very burdensome requirement to place on the protocol for
> >    the sake of a very implementation-specific convenience.  One can
> >    avoid this complexity by not supporting UTF-8, but that in itself
> >    is unfortunate.
> >
> >Most of this complexity is there to provide wire similarity between
> >DIGEST-MD5 as used in SASL and in HTTP, but that's not a compelling 
> >justification for requiring a tenfold expansion in code size 
> over what 
> >would be required to compute the digests and do basic parsing.
> >  
> >
> See above.
> 
> >Because of this complexity, I am likely to go back to CRAM-MD5, 
> >ignoring the RFC 3454 requirement in the current draft.  I'm 
> not sure 
> >what SASL can do at this point to reduce the implementation burdens, 
> >but I have to say that I am sorely disappointed.  When one 
> is designing 
> >a security system, one should compromise simplicity only in 
> the name of 
> >security.
> >
> SASL has nothing to do with your problem (well, very little to do).
> SASL is just a framework. If you don't like mechanisms that 
> are currently available, you can write a new one and try to 
> make it deployed.
> 
> >As promised, here are my major issues with the Cyrus SASL
> >implementation:
> >
> >  * As I've discussed before, if you're a library invoking the SASL
> >    library, there's no way to ensure thread-safety while remaining
> >    compatible with other libraries invoking SASL.
> >
> >  * The getopt interface seems to be a barrier to successfully
> >    documenting or internationalizing an application's configuration
> >    system.
> >
> Why?
> 
> >  * The API does not successfully hide the complexity of the
> >    underlying mechanisms, such as digest-md5's realms.  (By "hide"
> >    here I don't mean the API shouldn't support them, but that you
> >    should have to go to extra effort to use them, instead of having
> >    to go to extra effort to ignore them.)
> >
> Yes, this is a bit unfortunate, but I had exactly the same 
> problem trying to write a different SASL implementation.
> 
> >
> >  * The secrets database is kept in a database format which 
> depends on
> >    the build of the library.
> >
> Shouldn't really. Secrets are usually stored in sasldb 
> backend, the format is quite stable at this point and 
> shouldn't change very much over the time.
> 
> >  If you go from one build to another
> >    (say, by upgrading versions of Red Hat) and the new build uses a
> >    different database, your server stops working and you get a
> >    cryptic error.  That seems totally unacceptable, and I wonder how
> >    existing users of the library are dealing with it.
> >
> >  * The secrets database keeps secrets in plain text, which I find
> >    unacceptable due to the amount of password-sharing users do.
> >  
> >
> Alexey
> 
> 
> 
> 

------=_NextPart_000_00A0_01C3924A.12E99900
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_00A0_01C3924A.12E99900--

Date: Tue, 14 Oct 2003 09:44:46 -0700
To: Hallvard B Furuseth <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: WG Last Call on draft-ietf-sasl-rfc2222bis-02
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

At 08:33 AM 10/14/2003, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>>> 3). Realm
>> 
>> I have not yet heard any arguments to keep the realm text.
>
>I found it useful, since I had no clear idea what a realm was.
>The text is just too demanding.  How about making the text purely
>informational, without any SHOULD or MUST?

I think the primary concern is that the text introduces a
concept with is particular to one or more mechanisms and
hence is out of place.   Seems better to move the text
into the DIGEST-MD5 specification as it seems to following
the DIGEST-MD5 concept of a realm.  Other mechanisms also
have realm concepts, but it's not clear to me that they
are the same as DIGEST-MD5's.

Kurt

Date: Tue, 14 Oct 2003 08:52:24 -0700
To: Hallvard B Furuseth <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: empty authzid in draft-ietf-sasl-plain-02.txt
Cc: [email-masked]
Sender: [email-masked]

At 08:01 AM 10/14/2003, Hallvard B Furuseth wrote:

>Kurt D. Zeilenga writes:
>>At 06:49 AM 10/1/2003, Hallvard B Furuseth wrote:
>>> draft-ietf-sasl-plain-02.txt says that
>>> 
>>>   The client leaves
>>>   the authorization identity empty if it wishes the server to derive the
>>>   authorization identity from the provided authentication identity.
>>>
>>> and
>>>
>>>   Note that the parameters provided to the Authorize function are not
>>>   prepared.
>>>
>>> so I think the pseudo-code for empty authzid should say
>>>           authzid = DeriveAuthzid(authcid);
>>> and not
>>>           authzid = DeriveAuthzid(pAuthcid);
>> 
>> I think the current psuedo-code is correct, the first
>> quoted text is misleading.
>
>I don't feel strongly about this, but the original wording seems
>right to me.  authzid is not prepared,

No, the psuedo-code does not prepare the authzid.  The
authzid is prepared, it's just prepared by other code.
I'll qualify the note with "by this code".

>so neither does it
>use the prepared version of authcid.

The authzid is derived from the prepared authcid to ensure
that all representations of the authentication identity
produce the same authzid.  This, I think, is important.

>And that way,
>PLAIN(authzid = "", authcid = X, password) does the same as
>PLAIN(authzid = X,  authcid = X, password).

These are not necessarily equivalent.  That is, authzid may
not be in the same form as the authcid and may require
different preparation.  The psuedo code (and notes) are
intended to reflect this.

Kurt 

From: Hallvard B Furuseth <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: WG Last Call on draft-ietf-sasl-rfc2222bis-02
Date: Tue, 14 Oct 2003 17:33:05 +0200
Sender: [email-masked]

Kurt D. Zeilenga writes:
>> 3). Realm
> 
> I have not yet heard any arguments to keep the realm text.

I found it useful, since I had no clear idea what a realm was.
The text is just too demanding.  How about making the text purely
informational, without any SHOULD or MUST?

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
Subject: Re: empty authzid in draft-ietf-sasl-plain-02.txt
Date: Tue, 14 Oct 2003 17:01:30 +0200
Sender: [email-masked]

Kurt D. Zeilenga writes:
>At 06:49 AM 10/1/2003, Hallvard B Furuseth wrote:
>> draft-ietf-sasl-plain-02.txt says that
>> 
>>   The client leaves
>>   the authorization identity empty if it wishes the server to derive the
>>   authorization identity from the provided authentication identity.
>>
>> and
>>
>>   Note that the parameters provided to the Authorize function are not
>>   prepared.
>>
>> so I think the pseudo-code for empty authzid should say
>>           authzid = DeriveAuthzid(authcid);
>> and not
>>           authzid = DeriveAuthzid(pAuthcid);
> 
> I think the current psuedo-code is correct, the first
> quoted text is misleading.

I don't feel strongly about this, but the original wording seems
right to me.  authzid is not prepared, so neither does it
use the prepared version of authcid.  And that way,
PLAIN(authzid = "", authcid = X, password) does the same as
PLAIN(authzid = X,  authcid = X, password).  Your way, it does not.
That seems wrong to me.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments
Date: Tue, 14 Oct 2003 16:52:21 +0200
Sender: [email-masked]

Alexey Melnikov writes:
>Hallvard B Furuseth wrote:
> 
>>>4.1.  Authentication protocol exchange
>>>
>>>   A SASL mechanism is responsible for conducting an authentication
>>>   protocol exchange.  This consists of a series of server challenges
>>>   and client responses,    
>>>
>>
>>Does this mean that the initial auth command from the client is not
>>considered part of the authentication protocol exchange?
>>
> Does it matter in this section?

Well, that's where "authentication protocol exchange" seems to be
defined.  It matters if other documents refer to "the authentication
protocol exchange".

Anyway, I think I found the answer in section 6.1.  The initial auth
command from the client is not part of the exchange, but the optional
"response" in the auth command is.

>>>4.2.  Authorization identities and proxy authentication
>>>
>>>   (...)
>>>   The character encoding scheme used for transmitting an authorization
>>>   identity over protocol is specified in each authentication mechanism
>>>   (with the authentication mechanism's blob being further
>>                                         ^^^^
>>
>>What's a blob?  I don't think it's 'something ill-defined or amorphous',
>>like the dictionary says:-)
>>
> I've changed this to "data".

I still don't know _which_ data you are talking about.

>>>   A protocol profile MAY further refine the definition of an
>>>   authorization identity by adding additional syntactic restrictions
>>>   and protocol-specific semantics.
>>
>>Add a paragraph break here, since the following is a new item.  Remove
>>"A protocol profile MUST specify" to just make the following a new item
>>in the list of things that must be specified.
>>
>>>   A protocol profile MUST specify the
>>>   form of the authorization identity (as it is protocol specific, as
>>>
> I would rather not do this, as this is a single logic item.

OK.

>>And, as I mentioned, there should be an 'Obsoletes: rfc 2222' at the
>>top.
>>
> I've added a sentence about this in the introduction section.

I'm pretty sure you will still need to insert the words "Obsoletes: rfc
2222" in the header sometime, though I don't remember where this is
stated.

-- 
Hallvard

Date: Tue, 14 Oct 2003 11:36:47 +0100
From: Alexey Melnikov <[email-masked]>
To: Greg Hudson <[email-masked]>
CC: [email-masked]
Subject: Re: Some implementor's notes
Sender: [email-masked]

Greg Hudson wrote:

>...
>
>First, I looked into CRAM-MD5.  It doesn't authenticate the server and
>it doesn't leave the window open for stream protection, but those
>issues aren't critical.  I found the following sources of hidden
>complexity:
>
>...
>
>  * The current draft mandates the use of RFC 3454, a 91-page RFC I
>    don't understand and which does not look trivial to implement.
>    I'm sure there are real issues with internationalized usernames
>    and passwords, but the blow-up in complexity seems astounding.
>
I have to disappoint you, but DIGEST-MD5 requires RFC 3454 as well (at 
least it will when I publish a new revision)

>
>Faced with these problems and a general sense of guilt at the idea of
>implementing a weak system, I turned to DIGEST-MD5.  I found that
>while DIGEST-MD5 is much more elegant than CRAM-MD5 in how it computes
>the digests, it comes with a burdensome level of complexity which is
>unrelated to its conceptual security properties.  In particular:
>
>  * It introduces the concepts of realms, subsequent authentication,
>    and authorization IDs, none of which seem to be important
>    functionality for a generic shared-secret authentication scheme,
>    and all of which could (I think) be handled out of band.
>    Fortunately, it's not too difficult to avoid supporting those
>    features.
>
>  * Messages are composed of key-value pairs which do not obey a
>    consistent syntax for the value, so parsing them is hard.  (I'm
>    not convinced that Cyrus's implementation is correct, particularly
>    for skipping over auth-param values.)
>
I suggest you try to find a case that breaks stuff. It is more 
constructive than saying that something doesn't (or may not) work.

>  * Length-counted strings would be easier to parse than quoted
>    strings while remaining human-readable.
>
>  * Implicit allowance for linear whitespace has no intrinsic value
>    and renders implementations more complicated and error-prone.
>
Yes. There are historical reasons why this happened.
It was a compromise between design and something that could have been 
implemented by one big vendor.
It was supposed to become a replacement for another seriously broken 
SASL mechanism NTLM.

>  * It is not specified whether the serv-type, host, and digest-uri
>    values are required.
>
They are required to be sent, but the receiver SHOULD (but not required 
to) verify it. If the text is not clear, let me know and I will try to 
fix it.

>  (Cyrus treats digest-uri as required but not
>    the other two, probably because it's not specified what you should
>    do with an unspecified digest-uri when computing the digests.)  It
>    is not made clear what security value, if any, these parameters
>    have; to "detect accidental connection to the incorrect server" is
>    not an important function for an authentication scheme.
>
>  * The UTF-8 to ISO 8859-1 recoding of usernames and passwords seems
>    like a very burdensome requirement to place on the protocol for
>    the sake of a very implementation-specific convenience.  One can
>    avoid this complexity by not supporting UTF-8, but that in itself
>    is unfortunate.
>
>Most of this complexity is there to provide wire similarity between
>DIGEST-MD5 as used in SASL and in HTTP, but that's not a compelling
>justification for requiring a tenfold expansion in code size over what
>would be required to compute the digests and do basic parsing.
>  
>
See above.

>Because of this complexity, I am likely to go back to CRAM-MD5,
>ignoring the RFC 3454 requirement in the current draft.  I'm not sure
>what SASL can do at this point to reduce the implementation burdens,
>but I have to say that I am sorely disappointed.  When one is
>designing a security system, one should compromise simplicity only in
>the name of security.
>
SASL has nothing to do with your problem (well, very little to do).
SASL is just a framework. If you don't like mechanisms that are 
currently available, you can write a new one and try to make it deployed.

>As promised, here are my major issues with the Cyrus SASL
>implementation:
>
>  * As I've discussed before, if you're a library invoking the SASL
>    library, there's no way to ensure thread-safety while remaining
>    compatible with other libraries invoking SASL.
>
>  * The getopt interface seems to be a barrier to successfully
>    documenting or internationalizing an application's configuration
>    system.
>
Why?

>  * The API does not successfully hide the complexity of the
>    underlying mechanisms, such as digest-md5's realms.  (By "hide"
>    here I don't mean the API shouldn't support them, but that you
>    should have to go to extra effort to use them, instead of having
>    to go to extra effort to ignore them.)
>
Yes, this is a bit unfortunate, but I had exactly the same problem 
trying to write a different SASL implementation.

>
>  * The secrets database is kept in a database format which depends on
>    the build of the library.
>
Shouldn't really. Secrets are usually stored in sasldb backend, the 
format is quite stable at this point and shouldn't change very much over 
the time.

>  If you go from one build to another
>    (say, by upgrading versions of Red Hat) and the new build uses a
>    different database, your server stops working and you get a
>    cryptic error.  That seems totally unacceptable, and I wonder how
>    existing users of the library are dealing with it.
>
>  * The secrets database keeps secrets in plain text, which I find
>    unacceptable due to the amount of password-sharing users do.
>  
>
Alexey

Subject: Re: Some implementor's notes
From: Greg Hudson <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
Cc: [email-masked]
Date: Mon, 13 Oct 2003 17:11:57 -0400
Sender: [email-masked]

On Mon, 2003-10-13 at 16:41, Lyndon Nerenberg wrote:
> >   * The secrets database keeps secrets in plain text, which I find
> >     unacceptable due to the amount of password-sharing users do.
> 
> If you don't trust the OS to protect this data then your only option is 
> to use a SASL mechanism that doesn't require plain text equivalent 
> secrets. This is SASL mechanism specific, and not an artifact of the 
> Cyrus implementation.

The issue is not how much the OS can be trusted; it's how much the owner
of the server can be trusted.  Ideally, the user should be able to
provide the secret to the server owner in such a way that the server
owner cannot reuse it with other services.

On further consideration, even if CRAM-MD5 secrets are kept in
intermediate form, that form can be reused with other CRAM-MD5 services,
so that's maybe not so useful.  However, a DIGEST-MD5 password in
intermediate form can only be used with another DIGEST-MD5 service if
the username and realm matches.  I'm not really sure what the common
practice is for realm names, but if they're commonly related to the
server hostname then the secret shouldn't be reusable in practice.

Date: Mon, 13 Oct 2003 14:41:00 -0600
From: Lyndon Nerenberg <[email-masked]>
To: Greg Hudson <[email-masked]>, [email-masked]
Subject: Re: Some implementor's notes
Sender: [email-masked]

>   * I find it important to avoid storing passwords in clear text,
>     since people often use the same password for multiple systems.  To
>     accomplish this, you need an MD5 implementation which supports
>     saving intermediate states.

That's an implementation issue, and not a CRAM-MD5 problem. [More on this 
below.]

>   * The current draft mandates the use of RFC 3454, a 91-page RFC I
>     don't understand and which does not look trivial to implement.
>     I'm sure there are real issues with internationalized usernames
>     and passwords, but the blow-up in complexity seems astounding.

3454 is a bit verbose, but from an implementation standpoint it's really 
not that complicated. There's no getting away from stringprep. The 
alternative solution of restricting everything to US-ASCII is a 
non-starter. With the IETF heavily leaning towards stringprep for all new 
protocol work, you shouldn't have any trouble finding libraries that will 
assist with the UTF coding issues.

> Because of this complexity, I am likely to go back to CRAM-MD5,
> ignoring the RFC 3454 requirement in the current draft.

Please don't. We have enough trouble as it is with implementations 
sending non-ASCII strings in CRAM-MD5. Without the ability to specify the 
character set in use, interoperability suffers greatly. stringprep solves 
this problem.

>   * The secrets database keeps secrets in plain text, which I find
>     unacceptable due to the amount of password-sharing users do.

If you don't trust the OS to protect this data then your only option is 
to use a SASL mechanism that doesn't require plain text equivalent 
secrets. This is SASL mechanism specific, and not an artifact of the 
Cyrus implementation.

--lyndon

Subject: Re: Some implementor's notes
From: Greg Hudson <[email-masked]>
To: [email-masked]
Date: Mon, 13 Oct 2003 13:59:53 -0400
Sender: [email-masked]

On Mon, 2003-10-13 at 13:19, Greg Hudson wrote:
>   * Messages are composed of key-value pairs which do not obey a
>     consistent syntax for the value, so parsing them is hard.  (I'm
>     not convinced that Cyrus's implementation is correct, particularly
>     for skipping over auth-param values.)

Whoops, this was based on a misreading of the syntax for auth-param (I
read it as being "auth-param=token=value" instead of just
"token=value").  So, ignore that point.

Date: Mon, 13 Oct 2003 13:19:19 -0400
From: Greg Hudson <[email-masked]>
To: [email-masked]
Subject: Some implementor's notes
Sender: [email-masked]

I'm writing these notes in hopes that they will provide insight on
possible barriers to SASL's adoption.

When I created the custom Subversion protocol, I decided to use SASL
for authentication because I liked the concept and because I dislike
the properties of X.509 certificates, which (via TLS) are the only
real alternative that I know of.  I started out by implementing
ANONYMOUS and EXTERNAL myself, since those are trivial.

I figured for the real meat, I would use a library, since in an ideal
world applications have no business implementing authentication
systems.  Unfortunately, I'm finding the Cyrus library unsuitable
(I'll detail the reasons for this at the end, since it's
implementation-specific) and I can't use the gsasl library in
Subversion since it is covered by the GPL.  So, since there have been
a lot of calls for password authentication, I thought maybe I would
implement one of the shared-secret systems without stream protection;
Subversion's utility libraries already include an MD5 implementation,
so I figured I wouldn't need to introduce any complicated pieces of
code.

First, I looked into CRAM-MD5.  It doesn't authenticate the server and
it doesn't leave the window open for stream protection, but those
issues aren't critical.  I found the following sources of hidden
complexity:

  * The processing of the secret (pad to 64 bytes or digest and then
    pad to 64 bytes) is clunky and has no value in an MD5 context as
    far as I know.

  * I find it important to avoid storing passwords in clear text,
    since people often use the same password for multiple systems.  To
    accomplish this, you need an MD5 implementation which supports
    saving intermediate states.

  * The current draft mandates the use of RFC 3454, a 91-page RFC I
    don't understand and which does not look trivial to implement.
    I'm sure there are real issues with internationalized usernames
    and passwords, but the blow-up in complexity seems astounding.

Faced with these problems and a general sense of guilt at the idea of
implementing a weak system, I turned to DIGEST-MD5.  I found that
while DIGEST-MD5 is much more elegant than CRAM-MD5 in how it computes
the digests, it comes with a burdensome level of complexity which is
unrelated to its conceptual security properties.  In particular:

  * It introduces the concepts of realms, subsequent authentication,
    and authorization IDs, none of which seem to be important
    functionality for a generic shared-secret authentication scheme,
    and all of which could (I think) be handled out of band.
    Fortunately, it's not too difficult to avoid supporting those
    features.

  * Messages are composed of key-value pairs which do not obey a
    consistent syntax for the value, so parsing them is hard.  (I'm
    not convinced that Cyrus's implementation is correct, particularly
    for skipping over auth-param values.)

  * Length-counted strings would be easier to parse than quoted
    strings while remaining human-readable.

  * Implicit allowance for linear whitespace has no intrinsic value
    and renders implementations more complicated and error-prone.

  * It is not specified whether the serv-type, host, and digest-uri
    values are required.  (Cyrus treats digest-uri as required but not
    the other two, probably because it's not specified what you should
    do with an unspecified digest-uri when computing the digests.)  It
    is not made clear what security value, if any, these parameters
    have; to "detect accidental connection to the incorrect server" is
    not an important function for an authentication scheme.

  * The UTF-8 to ISO 8859-1 recoding of usernames and passwords seems
    like a very burdensome requirement to place on the protocol for
    the sake of a very implementation-specific convenience.  One can
    avoid this complexity by not supporting UTF-8, but that in itself
    is unfortunate.

Most of this complexity is there to provide wire similarity between
DIGEST-MD5 as used in SASL and in HTTP, but that's not a compelling
justification for requiring a tenfold expansion in code size over what
would be required to compute the digests and do basic parsing.

Because of this complexity, I am likely to go back to CRAM-MD5,
ignoring the RFC 3454 requirement in the current draft.  I'm not sure
what SASL can do at this point to reduce the implementation burdens,
but I have to say that I am sorely disappointed.  When one is
designing a security system, one should compromise simplicity only in
the name of security.

As promised, here are my major issues with the Cyrus SASL
implementation:

  * As I've discussed before, if you're a library invoking the SASL
    library, there's no way to ensure thread-safety while remaining
    compatible with other libraries invoking SASL.

  * The getopt interface seems to be a barrier to successfully
    documenting or internationalizing an application's configuration
    system.

  * The API does not successfully hide the complexity of the
    underlying mechanisms, such as digest-md5's realms.  (By "hide"
    here I don't mean the API shouldn't support them, but that you
    should have to go to extra effort to use them, instead of having
    to go to extra effort to ignore them.)

  * The secrets database is kept in a database format which depends on
    the build of the library.  If you go from one build to another
    (say, by upgrading versions of Red Hat) and the new build uses a
    different database, your server stops working and you get a
    cryptic error.  That seems totally unacceptable, and I wonder how
    existing users of the library are dealing with it.

  * The secrets database keeps secrets in plain text, which I find
    unacceptable due to the amount of password-sharing users do.

Date: Mon, 13 Oct 2003 11:45:17 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: rfc2254bis/rfc2554bis
Sender: [email-masked]

I'd like to point members of this working group at the following two
documents which are intended as revisions to the SMTP/POP3 SASL profiles:

draft-siemborski-rfc1734bis-00.txt
draft-siemborski-rfc2554bis-00.txt

The aims here are to clarify the specifications to result in fewer
interoperability problems.  The two big concerns that I am aware of being
how implementations deal with client-send-first and (in the case of SMTP)
servers rejecting the AUTH= parameter to MAIL FROM when the session is not
authenticated.

I will be updating these drafts to point at rfc2222bis in their first
revision.  I'd also like to hear any other comments.

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

From: Alexey Melnikov <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Cc: [email-masked], Jeremie Miller <[email-masked]>, [email-masked], SASL WG <[email-masked]>
Subject: Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard)
Reply-To: [email-masked]
Date: Wed, 08 Oct 2003 20:31:34 +0100
Sender: [email-masked]

Peter Saint-Andre wrote:

>>1).
>>    
>>
>>>  7.  The initiating entity MUST provide an authzid during SASL
>>>      negotiation. The authzid-value MUST be a valid JID of the form
>>>      <domain> (i.e., a domain identifier only) for servers and of the
>>>      form <user@domain/resource> (i.e., node identifier, domain
>>>      identifier, and resource identifier) for clients. The initiating
>>>      entity MAY process the authzid-value in accordance with the rules
>>>      defined in Addressing Scheme (Section 3) before providing it to
>>>      the receiving entity, but is NOT REQUIRED to do so; however, the
>>>      receiving entity MUST verify that the authzid-value provided by
>>>      the initiating entity conforms to the rules defined therein.
>>>      
>>>
>>Not all SASL mechanisms are capable of transmitting authorization 
>>identity, so this requirement might be problematic.
>>
>>Also, the revision of RFC 2222 says that the client must not specify 
>>authorization-id unless it wants to impersonate some other entity:
>>
>>  As a client might not have the same information as the server,
>>  clients SHOULD NOT themselves try to derive authorization identities
>>  from authentication identities when clients could instead transmit an
>>  authorization identity of the empty string.
>>
>>So, the text should be reworded reflect that an authorization identity 
>>is optional and that if one is provided, it is in the form described above.
>>    
>>
>
>My understanding from an earlier thread on the XMPP WG list was that
>providing the authorization identity in this manner was the approach
>preferred by the SASL community. I think the fundamental issue here is
>that for XMPP clients, the authorization identity is a "full JID" (i.e.,
>node@host/resource) that is asserted by the connecting client, not
>derived by the server. Perhaps this usage is not consistent with the
>definition of authorization identity in RFC 2222? We'd have to look at
>the implications of this for client assertion of a full JID (perhaps
>this should be defined only in draft-ietf-xmpp-im).
>
There are two issues here:
1). Format of an authorization identity - your document has to define it
2). Requirement to always specify authorization identity.

Short answer to the second issue is probably "you can't do that".
But here I will try to give a long answer to explain that you probably 
don't need 2 anyway.

This is a bit tricky. SASL defines two types of identities. 
Authentication identity is derived from your authentication credentials 
and its format is SASL mechanism specific. Authorization identity is 
protocol specific. If authorization identity is not specified ("empty 
authorization identity"), it is derived from the authentication 
identity. This is the usual case ("just act as yourself").

However is authorization identity is specified, additional authorization 
checks take place. The server has to verify that the authentication 
identity can act as the authorization identity.  Authorization identity 
is useful, for example, when an administrator (or proxy server) wants to 
authenticate as himself, but act as the user.
In XMPP case I can also imagine a client that tries to authenticate as 
"node@host", but act as "node@host/resource".

So, what does this means for a server implementor? The text below 
describes my implementation experience and doesn't specify a standard of 
any kind.

Usually deployed SASL mechanisms (PLAIN/CRAM-MD5/DIGEST-MD5) don't put 
any restrictions on how an authentication identity looks like.
So, in most cases "node@host/resource" (for the client-to-server) or 
"host" (for the server-to-server) format will be used.

For Kerberos mechanisms (KERBEROS_V4, GSSAPI), authentication identity 
has the format dictated by Kerberos (usually user@realm or 
service@realm). An XMPP implementation will have to internally map 
Kerberos principals to XMPP JID format (or host), before verifying an 
authorization identity, if the one was provided.

Of course, there is also SASL EXTERNAL that can be used together with 
TLS. In this case authentication identity will have syntax of a DN.

The bottom line is that the syntax used for authorization identities for 
a protocol is [most likely] the syntax that is going to be used 
internally by the server and is the same syntax that is used by the user 
in the "enter your username" dialog for the protocol.

(Hopefully this makes sense ;-)).

So, the paragraph should probable read:

 7.  An authorization identity used in SASL is a valid JID of the form
      <domain> (i.e., a domain identifier only) for servers and of the
      form <user@domain/resource> (i.e., node identifier, domain
      identifier, and resource identifier) for clients. ...

Regards,
Alexey
__________________________________________
Isode Limited, http://www.isode.com

Cell: +44 7753759732

IETF standard related pages:
http://orthanc.ab.ca/mel/devel/Links.html

Personal Home Page: http://orthanc.ab.ca/mel
__________________________________________

_______________________________________________
xmppwg mailing list
[email-masked]
http://jabber.org/cgi-bin/mailman/listinfo/xmppwg

To: "Joseph Salowey" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "'SASL WG'" <[email-masked]>
Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard
From: Eric Rescorla <[email-masked]>
Lines: 41
Reply-To: [email-masked]
Date: 08 Oct 2003 22:16:31 -0700
Sender: [email-masked]

"Joseph Salowey" <[email-masked]> writes:
> > How's that again? Please explain the network topology you're 
> > considering here.
> > 
> 
> Ok. I might be misunderstanding something, here is a summary:
> 
> A client C that is willing to use SASL mechanism X both inside and
> outside a TLS tunnel.
> A server S that supports a server authenticated TLS tunnel and then
> authenticates the client using SASL mechanism X within the tunnel.
> An attacker M who can act as a TLS client and a SASL server for
> mechanism X.
> 
> The network topology/deployment must allow for M to trick C into trying
> to authenticate to him using SASL Mechanism X (without TLS) while M
> simultaneously establishes a TLS connection with S. 
> 
> M establishes a TLS session with S 
> M tricks C into trying to authenticate to him using SASL mechanism X
> without TLS protection (these first steps could happen in the reverse
> order)
> M forwards the SASL exchange from C to S and vice versa.  
> The SASL authentication will succeed and S will believe that the
> endpoint of the TLS tunnel is C instead of M (For some mechanisms M may
> have to spoof S's address in order for the authentication to complete).
> M can disconnect from C and continue sending messages to S.  
> S thinks the messages from M originate from C. 

Yes, this will work. But here's the thing:

This only works if the client would have been prepared to do this weak
mechanism over a non-TLS connection.  Generally the client knows when
it expects to do TLS and when it doesn't. 

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/
_______________________________________________
xmppwg mailing list
[email-masked]
http://jabber.org/cgi-bin/mailman/listinfo/xmppwg

Date: Fri, 10 Oct 2003 10:45:37 +0100
From: Alexey Melnikov <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
CC: Jeffrey Hutzelman <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Replacing a SASL security layer
Sender: [email-masked]

Kurt D. Zeilenga wrote:

>A concern here is that a number of application profiles
>specify (and developers have implemented) SASL layers such
>that established layers cannot be deinstalled except to install
>new layers.
>
I am only aware of one protocol that might do that: LDAP.

>  Changing this now will naturally introduce some
>interoperability, so we need to be sure that the change is well
>justified.
>
I don't believe anybody implements this right anyway (please, do let me 
know if I am right).

>  I wonder if it might be better to not to change the
>protocol but, instead, just document the security consideration.
>
I would like to allow new protocols to allow to deinstall the security 
layer when none is negotiated. RFC 2222 prohibits this.
IMHO, it is fine if an existing protocol doesn't do that (and documents 
the issue in Security considerations), but there is no point of forcing 
brokeness on new protocols.

Cheers,
Alexey
__________________________________________
Isode Limited, http://www.isode.com

Cell: +44 7753759732

IETF standard related pages:
http://orthanc.ab.ca/mel/devel/Links.html

Personal Home Page: http://orthanc.ab.ca/mel
__________________________________________

Date: Thu, 09 Oct 2003 19:52:29 -0700
To: Alexey Melnikov <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Replacing a SASL security layer
Cc: Jeffrey Hutzelman <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

A concern here is that a number of application profiles
specify (and developers have implemented) SASL layers such
that established layers cannot be deinstalled except to install
new layers.  Changing this now will naturally introduce some
interoperability, so we need to be sure that the change is well
justified.  I wonder if it might be better to not to change the
protocol but, instead, just document the security consideration.

Kurt

Date: Thu, 09 Oct 2003 19:55:56 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Dick Kniep <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: Sasl problems
Sender: [email-masked]

Wrong list.  This list is for discussion of the design of SASL and its 
mechanisms, not the implementations.  Try:

[email-masked] and/or [email-masked]

Dick Kniep wrote:

> Hi List,
> 
> This is my first post on the sasl list, I am no guru on SASl, so please
> be gentle.
> 
> We have installed a Kolab server (groupware with Sasl, postfix, cyrus
> imap etc.) Install went smoothly, but we cannot log on. I have posted to
> the kolab mailinglist, but got no answer whatsoever. So, next is my
> original post to the kolab mailinglist. If anyone can help, please do
> so.
> 
> Since the original occurrance of the error, I have tried to remove the
> user 'dick' completely from the system, defining it again etc. All to no
> avail.
> 
> ++++ Original message to Kolab mailinglist ++++
> 
> We have a strange phenomenon where we cannot get access to the server. 
> 
> We have entered a userid in the management module. This works OK (or so
> it seems) Next we try to login, but then we get a message that the
> userid is not authorized. The password is correct. When we look in the
> logs of SASL the following messages are shown:
> 
> --------------------------
> 
> Oct 02 18:58:15 LinServ01 <debug> saslauthd[962]: Entry not found or
> more than one entries found ((|(uid=dick)(mail=dick)(alias=dick))).
> Oct 02 18:58:15 LinServ01 <info> saslauthd[962]: do_auth         : auth
> failure: [user=dick] [service=imap] [realm=] [mech=ldap]
> 
> --------------------------
> 
> It says that there are more definitions of the user 'dick'. 
> If that is the case how can we verify that?
> If not what could be the problem than????
> 
> Please help
> 
> Kind regards,
> D. Kniep
> 
> 
> 
> 
> 
> 
> 

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Thu, 09 Oct 2003 16:41:32 -0700
To: Dick Kniep <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Sasl problems
Cc: SASL WG <[email-masked]>
Sender: [email-masked]

Dick,

As list is reserved for discussions regarding standardization
of SASL, your post is off-topic.  You should instead direct
your post to a forum which supports the particular software
you are using.  I note that Cyrus SASL mailing list information
can be found at <http://asg.web.cmu.edu/sasl/#mailinglists>.

Thanks, Kurt (SASL WG co-chair)
 
At 03:22 PM 10/9/2003, Dick Kniep wrote:

>Hi List,
>
>This is my first post on the sasl list, I am no guru on SASl, so please
>be gentle.
>
>We have installed a Kolab server (groupware with Sasl, postfix, cyrus
>imap etc.) Install went smoothly, but we cannot log on. I have posted to
>the kolab mailinglist, but got no answer whatsoever. So, next is my
>original post to the kolab mailinglist. If anyone can help, please do
>so.
>
>Since the original occurrance of the error, I have tried to remove the
>user 'dick' completely from the system, defining it again etc. All to no
>avail.
>
>++++ Original message to Kolab mailinglist ++++
>
>We have a strange phenomenon where we cannot get access to the server. 
>
>We have entered a userid in the management module. This works OK (or so
>it seems) Next we try to login, but then we get a message that the
>userid is not authorized. The password is correct. When we look in the
>logs of SASL the following messages are shown:
>
>--------------------------
>
>Oct 02 18:58:15 LinServ01 <debug> saslauthd[962]: Entry not found or
>more than one entries found ((|(uid=dick)(mail=dick)(alias=dick))).
>Oct 02 18:58:15 LinServ01 <info> saslauthd[962]: do_auth         : auth
>failure: [user=dick] [service=imap] [realm=] [mech=ldap]
>
>--------------------------
>
>It says that there are more definitions of the user 'dick'. 
>If that is the case how can we verify that?
>If not what could be the problem than????
>
>Please help
>
>Kind regards,
>D. Kniep

To: Joseph Salowey <[email-masked]>
Cc: "'EKR'" <[email-masked]>, [email-masked], [email-masked], "'SASL WG'" <[email-masked]>
Subject: Re: SASL channel bindings
From: Sam Hartman <[email-masked]>
Date: Thu, 09 Oct 2003 18:38:03 -0400
Sender: [email-masked]

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Wed, Oct 08, 2003 at 08:40:43PM -0700, Joseph Salowey
    Nicolas> wrote:
    >> If the TLS tunnel is only server authenticated and the client
    >> supports a particular SASL method (perhaps even in a different
    >> protocol)that provides mutual authentication both inside and
    >> outside a TLS tunnel there is a vulnerability.  In this case if
    >> only the message protection of TLS is used you cannot be sure
    >> that the client endpoint of the TLS tunnel is the same client
    >> endpoint that the server authenticated with SASL.
    >> 
    >> To mitigate this problem you can:
    >> 
    >> - Use the protection from the inner SASL method - Have the SASL
    >> authentication mechanism authenticate the TLS Session ID or
    >> some similar parameter - Require different credentials be used
    >> by a SASL mechanism when operating inside or outside a TLS
    >> tunnel.

    Nicolas> Why does this sound really familiar?  Ah, because one
    Nicolas> solution is to "bind" one layer (SASL) to the key
    Nicolas> exchange and negotiation of the other (TLS) to prove that
    Nicolas> there's no MITM at the lower layer (TLS) - which, of
    Nicolas> course, relies on an MITM's inability to make the key
    Nicolas> exchange/nego look the same on both side of the lower
    Nicolas> layer channel.

    Nicolas> In the GSS-API we call this channel bindings.  Perhaps
    Nicolas> SASL should have

I wish SASL had this feature a lot.  It's clearly out of scope for
both the XMPP working group and for the SASL working group.

Subject: Sasl problems
From: Dick Kniep <[email-masked]>
To: SASL WG <[email-masked]>
Date: 10 Oct 2003 00:22:09 +0200
Sender: [email-masked]

Hi List,

This is my first post on the sasl list, I am no guru on SASl, so please
be gentle.

We have installed a Kolab server (groupware with Sasl, postfix, cyrus
imap etc.) Install went smoothly, but we cannot log on. I have posted to
the kolab mailinglist, but got no answer whatsoever. So, next is my
original post to the kolab mailinglist. If anyone can help, please do
so.

Since the original occurrance of the error, I have tried to remove the
user 'dick' completely from the system, defining it again etc. All to no
avail.

++++ Original message to Kolab mailinglist ++++

We have a strange phenomenon where we cannot get access to the server. 

We have entered a userid in the management module. This works OK (or so
it seems) Next we try to login, but then we get a message that the
userid is not authorized. The password is correct. When we look in the
logs of SASL the following messages are shown:

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

Oct 02 18:58:15 LinServ01 <debug> saslauthd[962]: Entry not found or
more than one entries found ((|(uid=dick)(mail=dick)(alias=dick))).
Oct 02 18:58:15 LinServ01 <info> saslauthd[962]: do_auth         : auth
failure: [user=dick] [service=imap] [realm=] [mech=ldap]

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

It says that there are more definitions of the user 'dick'. 
If that is the case how can we verify that?
If not what could be the problem than????

Please help

Kind regards,
D. Kniep

Date: Thu, 9 Oct 2003 09:25:07 -0700
From: Nicolas Williams <[email-masked]>
To: Jeffrey Altman <[email-masked]>
Cc: Joseph Salowey <[email-masked]>, "'EKR'" <[email-masked]>, [email-masked], [email-masked], "'SASL WG'" <[email-masked]>
Subject: Re: SASL channel bindings (was Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard)
Mail-Followup-To: Jeffrey Altman <[email-masked]>, Joseph Salowey <[email-masked]>, 'EKR' <[email-masked]>, [email-masked], [email-masked], 'SASL WG' <[email-masked]>
Sender: [email-masked]

On Thu, Oct 09, 2003 at 11:44:10AM -0400, Jeffrey Altman wrote:
> Nicolas Williams wrote:
> >The second solution you give is an attempt at doing just this sort of
> >binding.
> >
> >Unfortunately, a TLS MITM can make the TLS session ID be the same on
> >both sides of the tunnel - that's because in TLS the server assigns the
> >session ID which, in turn, is not bound or required to be bound in any
> >way to the TLS key exchange / negotiation.  So you can't use TLS session
> >IDs as channel bindings.
> 
> The channel binding would be made utilizing the TLS Client and Server 
> Finished Messages.  If both the client and server concatenate those 
> messages in a well defined order, they can then attempt to verify that 
> both the client and server have the same bytes.  This is how TELNET AUTH 
> binds to TLS when STARTTLS is used.  The benefit of this is that we 
> would get mutual authentication from SASL which would allow TLS to be 
> used in anonymous-DH mode completely removing the need to have or 
> validate X.509 certificates.

Yeah - I offer as much in the post I just followed up with.

This sort of thing is extremely valuable.  The NFSv4 WG is quite
interested in channel bindings as a way to offload session cryptographic
protection from RPCSEC_GSS/GSS-API to IPsec and others.

See:

http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ccm-01.txt

(The I-D will be updated soon, I hope, and will include much improved
 text about binding to IKEv2 IPsec transport-mode IKE_SAs, as well
 nonces and an additional 1/2 round-trip for the CCM-* pseudo-
 mechanisms' context tokens so as to make their context tokens
 un-replayable independently of the underlying, real mechanisms'
 context tokens' replayability.)

> Unfortunately, SASL does not have this functionality at the current 
> time.  I very much think it should.  If it did, this entire discussion 
> of the use of SASL Security Layers on top of TLS could just go away.

The discussion of what to use as channel bindings to TLS would still
have to be had, though you point out that TELNET already solves that
particular problem in a way that others could leverage.  But that still
leaves other channels to discuss (e.g., IPsec) - see my other followup
to Joe.

> I completely understand why the SASL folks want to be able to use a SASL 
> Security Layer on top of TLS when they do not have the ability to bind 
> to lower layers.  Unfortunately, if SASL Security Layers are always to 
> be used then I believe that TLS should never be negotiated.  To do so 
> adds nothing to the strength of the security of the session, increases 
> the complexity, wastes CPU cycles, and spreads FUD regarding the 
> trustworthiness of TLS.  The lack of trust is not caused by TLS, but by 
> the inability of SASL to verify a previously known shared secret between 
> two parties.

I agree.  But note that SASL doesn't have to "verify a previously ..." -
it just has to verify a value, public or not, that could not be made the
same for both parties by an MITM at the lower layer.

Cheers,

Nico
-- 

Date: Thu, 9 Oct 2003 09:14:55 -0700
From: Nicolas Williams <[email-masked]>
To: Joseph Salowey <[email-masked]>
Cc: "'EKR'" <[email-masked]>, [email-masked], [email-masked], "'SASL WG'" <[email-masked]>
Subject: Re: SASL channel bindings (was Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard)
Mail-Followup-To: Joseph Salowey <[email-masked]>, 'EKR' <[email-masked]>, [email-masked], [email-masked], 'SASL WG' <[email-masked]>
Sender: [email-masked]

On Thu, Oct 09, 2003 at 08:37:37AM -0700, Joseph Salowey wrote:

Nico> Why does this sound really familiar?  Ah, because one solution is
Nico> to "bind" one layer (SASL) to the key exchange and negotiation of
Nico> the other (TLS) to prove that there's no MITM at the lower layer
Nico> (TLS) - which, of course, relies on an MITM's inability to make
Nico> the key exchange/nego look the same on both side of the lower
Nico> layer channel.

> [Joe] Yes, this is all too familiar
> 
> > 
Nico> In the GSS-API we call this channel bindings.  Perhaps SASL should
Nico> have

[I meant to say "Perhaps SASL should have a channel bindings facility."]

Nico> Unfortunately, a TLS MITM can make the TLS session ID be the same
Nico> on both sides of the tunnel - that's because in TLS the server
Nico> assigns the session ID which, in turn, is not bound or required to
Nico> be bound in any way to the TLS key exchange / negotiation.  So you
Nico> can't use TLS session IDs as channel bindings.

> [Joe] Yes, I agree the Session ID is probably not the best choice
> (although in would probably work in the case outlined, it will fail if
> the attacker can trick the client into accepting it as a valid TLS
> endpoint, but this is a different problem).  
> 
> In any case SASL might benefit from channel bindings, although one has
> to be careful with channel bindings (for example binding to addresses
> tends to cause problems).  Maybe it is possible to temporarily turn on
> SASL integrity services to authenticate binding information.  I don't
> think that SASL intends for the security layer to be removed after it
> starts, but I didn't find a place in the draft where it explicitly
> forbids it.  If it is allowed then applications which negotiate TLS can
> use this binding technique.

It's probably not possible to add a channel bindings facility to SASL at
this point, but it should be possible to describe how applications
should do channel binding with SASL, more or less as you describe.

And as you point out, the traditional use of GSS-API channel bindings to
bind to network addresses causes problems, and, I might add, isn't
really secure.

Therefore we need to generally address channel bindings for the channels
one might like to bind to:

 - What to use as channel bindings for SSHv2?

   Easy, the SSHv2 session ID!

 - What to use as channel bindings for TLS?

   TLS defines no suitable value.  So one may have to be constructed
   (e.g., hash of all TLS session setup messages).

 - What to use as channel bindings for IKEv1 IPsec?

   Don't.  IKEv1 rekeying isn't like SSHv2 rekeying - there's no binding
   to the previous or original IKE_SA - so that when the IKE_SA expires
   so do the bindings.

 - What to use as channel bindings for IKEv2 IPsec?

   IKEv2 rekeying does bind the new SA to the previous one, so binding
   to IPsec SAs negotiated with IKEv2 is ok, but we need to define the
   what to use as the channel bindings.

   I've asked the IPSEC WG to define a value for use as channel
   bindings, but so far they are ignoring me.

   Ultimately, the same octets of which signatures are exchanged in the
   AUTH part of the IKEv2 exchange (see section 2.15 of the IKEv2 draft)
   can be used as channel bindings, or, rather, a hash thereof.

 - What to use as channel bindings for Kerberos V-protected tunnels?

   Again, nothing useful for this is provided in RFC1510.  But who wants
   this?  :)  Still something could be defined (e.g., a hash of the AP
   exchange messages).

 - What to use as channel bindings for GSS-API-protected tunnels?

   Same thing.  I'd propose: the ret_flags of the context and a hash of
   the byte-wise concatenation of the context tokens used to initialize
   the context, in order.

 - What to use as channel bindings for SASL-protected tunnels?

   Again, same thing...

Cheers,

Nico
-- 

Date: Thu, 09 Oct 2003 11:44:10 -0400
From: Jeffrey Altman <[email-masked]>
Organization: Columbia University in the City of New York
To: Nicolas Williams <[email-masked]>
CC: Joseph Salowey <[email-masked]>, "'EKR'" <[email-masked]>, [email-masked], [email-masked], "'SASL WG'" <[email-masked]>
Subject: Re: SASL channel bindings (was Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard)
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms000703080003050300080103
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Nicolas Williams wrote:

>On Wed, Oct 08, 2003 at 08:40:43PM -0700, Joseph Salowey wrote:
>  
>
>>If the TLS tunnel is only server authenticated and the client supports a
>>particular SASL method (perhaps even in a different protocol)that
>>provides mutual authentication both inside and outside a TLS tunnel
>>there is a vulnerability.  In this case if only the message protection
>>of TLS is used you cannot be sure that the client endpoint of the TLS
>>tunnel is the same client endpoint that the server authenticated with
>>SASL.  
>>
>>To mitigate this problem you can: 
>>
>>- Use the protection from the inner SASL method
>>- Have the SASL authentication mechanism authenticate the TLS Session ID
>>or some similar parameter 
>>- Require different credentials be used by a SASL mechanism when
>>operating inside or outside a TLS tunnel.   
>>    
>>
>
>Why does this sound really familiar?  Ah, because one solution is to
>"bind" one layer (SASL) to the key exchange and negotiation of the other
>(TLS) to prove that there's no MITM at the lower layer (TLS) - which, of
>course, relies on an MITM's inability to make the key exchange/nego look
>the same on both side of the lower layer channel.
>
>In the GSS-API we call this channel bindings.  Perhaps SASL should have
>
>The second solution you give is an attempt at doing just this sort of
>binding.
>
>Unfortunately, a TLS MITM can make the TLS session ID be the same on
>both sides of the tunnel - that's because in TLS the server assigns the
>session ID which, in turn, is not bound or required to be bound in any
>way to the TLS key exchange / negotiation.  So you can't use TLS session
>IDs as channel bindings.
>
>Cheers,
>
>Nico
>  
>

The channel binding would be made utilizing the TLS Client and Server 
Finished Messages.  If both the client and server concatenate those 
messages in a well defined order, they can then attempt to verify that 
both the client and server have the same bytes.  This is how TELNET AUTH 
binds to TLS when STARTTLS is used.  The benefit of this is that we 
would get mutual authentication from SASL which would allow TLS to be 
used in anonymous-DH mode completely removing the need to have or 
validate X.509 certificates.

Unfortunately, SASL does not have this functionality at the current 
time.  I very much think it should.  If it did, this entire discussion 
of the use of SASL Security Layers on top of TLS could just go away.

I completely understand why the SASL folks want to be able to use a SASL 
Security Layer on top of TLS when they do not have the ability to bind 
to lower layers.  Unfortunately, if SASL Security Layers are always to 
be used then I believe that TLS should never be negotiated.  To do so 
adds nothing to the strength of the security of the session, increases 
the complexity, wastes CPU cycles, and spreads FUD regarding the 
trustworthiness of TLS.  The lack of trust is not caused by TLS, but by 
the inability of SASL to verify a previously known shared secret between 
two parties.

Jeffrey Altman

Jeffrey Altman

--------------ms000703080003050300080103
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms000703080003050300080103--

From: "Joseph Salowey" <[email-masked]>
To: "'Nicolas Williams'" <[email-masked]>
Cc: "'EKR'" <[email-masked]>, <[email-masked]>, <[email-masked]>, "'SASL WG'" <[email-masked]>
Subject: RE: SASL channel bindings (was Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard)
Date: Thu, 9 Oct 2003 08:37:37 -0700
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]] 
> Sent: Thursday, October 09, 2003 8:05 AM
> To: Joseph Salowey
> Cc: 'EKR'; [email-masked]; [email-masked]; 'SASL WG'
> Subject: SASL channel bindings (was Re: [xmppwg] Last Call: 
> 'XMPP Core' to Proposed Standard)
> 
> 
> On Wed, Oct 08, 2003 at 08:40:43PM -0700, Joseph Salowey wrote:
> > If the TLS tunnel is only server authenticated and the 
> client supports 
> > a particular SASL method (perhaps even in a different protocol)that 
> > provides mutual authentication both inside and outside a TLS tunnel 
> > there is a vulnerability.  In this case if only the message 
> protection 
> > of TLS is used you cannot be sure that the client endpoint 
> of the TLS 
> > tunnel is the same client endpoint that the server 
> authenticated with 
> > SASL.
> > 
> > To mitigate this problem you can:
> > 
> > - Use the protection from the inner SASL method
> > - Have the SASL authentication mechanism authenticate the 
> TLS Session 
> > ID or some similar parameter
> > - Require different credentials be used by a SASL mechanism when
> > operating inside or outside a TLS tunnel.   
> 
> Why does this sound really familiar?  Ah, because one 
> solution is to "bind" one layer (SASL) to the key exchange 
> and negotiation of the other
> (TLS) to prove that there's no MITM at the lower layer (TLS) 
> - which, of course, relies on an MITM's inability to make the 
> key exchange/nego look the same on both side of the lower 
> layer channel.

[Joe] Yes, this is all too familiar

> 
> In the GSS-API we call this channel bindings.  Perhaps SASL 
> should have
> 
> The second solution you give is an attempt at doing just this 
> sort of binding.
> 
> Unfortunately, a TLS MITM can make the TLS session ID be the 
> same on both sides of the tunnel - that's because in TLS the 
> server assigns the session ID which, in turn, is not bound or 
> required to be bound in any way to the TLS key exchange / 
> negotiation.  So you can't use TLS session IDs as channel bindings.
> 
[Joe] Yes, I agree the Session ID is probably not the best choice
(although in would probably work in the case outlined, it will fail if
the attacker can trick the client into accepting it as a valid TLS
endpoint, but this is a different problem).  

In any case SASL might benefit from channel bindings, although one has
to be careful with channel bindings (for example binding to addresses
tends to cause problems).  Maybe it is possible to temporarily turn on
SASL integrity services to authenticate binding information.  I don't
think that SASL intends for the security layer to be removed after it
starts, but I didn't find a place in the draft where it explicitly
forbids it.  If it is allowed then applications which negotiate TLS can
use this binding technique.

> Cheers,
> Nico
> -- 

Date: Thu, 9 Oct 2003 08:04:30 -0700
From: Nicolas Williams <[email-masked]>
To: Joseph Salowey <[email-masked]>
Cc: "'EKR'" <[email-masked]>, [email-masked], [email-masked], "'SASL WG'" <[email-masked]>
Subject: SASL channel bindings (was Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard)
Mail-Followup-To: Joseph Salowey <[email-masked]>, 'EKR' <[email-masked]>, [email-masked], [email-masked], 'SASL WG' <[email-masked]>
Sender: [email-masked]

On Wed, Oct 08, 2003 at 08:40:43PM -0700, Joseph Salowey wrote:
> If the TLS tunnel is only server authenticated and the client supports a
> particular SASL method (perhaps even in a different protocol)that
> provides mutual authentication both inside and outside a TLS tunnel
> there is a vulnerability.  In this case if only the message protection
> of TLS is used you cannot be sure that the client endpoint of the TLS
> tunnel is the same client endpoint that the server authenticated with
> SASL.  
> 
> To mitigate this problem you can: 
> 
> - Use the protection from the inner SASL method
> - Have the SASL authentication mechanism authenticate the TLS Session ID
> or some similar parameter 
> - Require different credentials be used by a SASL mechanism when
> operating inside or outside a TLS tunnel.   

Why does this sound really familiar?  Ah, because one solution is to
"bind" one layer (SASL) to the key exchange and negotiation of the other
(TLS) to prove that there's no MITM at the lower layer (TLS) - which, of
course, relies on an MITM's inability to make the key exchange/nego look
the same on both side of the lower layer channel.

In the GSS-API we call this channel bindings.  Perhaps SASL should have

The second solution you give is an attempt at doing just this sort of
binding.

Unfortunately, a TLS MITM can make the TLS session ID be the same on
both sides of the tunnel - that's because in TLS the server assigns the
session ID which, in turn, is not bound or required to be bound in any
way to the TLS key exchange / negotiation.  So you can't use TLS session
IDs as channel bindings.

Cheers,

Nico
-- 

Date: Wed, 08 Oct 2003 23:16:54 +0100
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Replacing a SASL security layer
Sender: [email-masked]

>>>   Below the term "realm" has the meaning as defined in the section 5.
>>>   A security layer that remains in effect when a client, which already
>>>   has authenticated and established the security layer with "Realm A",
>>>   authenticates to "Realm B", without negotiating a new security layer,
>>>   enables "Realm B" to make guesses about previously observed
>>>   ciphertext using the server's SASL engine as an oracle. "Realm B" may
>>>   observe how known cleartext is encrypted.
>>>
>>>              +---------+                   +---------+
>>>              |         |                   |         |
>>>              | Realm B |                   | Realm A |
>>>              |         |                   |         |
>>>              +---------+                   +---------+
>>>                  |  ^                           |
>>>                  |  :      +-----------+        |
>>>     Traffic from |  :      | Encryption|        | Traffic from A
>>>      B to client +-------->| end point |<-------+ to client
>>>                     :      | (SSL/SASL)|
>>>                     :      +-----------+
>>>                     :            |
>>>                     :            |
>>>                     :          +---+
>>>                     :          |   |
>>>                     :          |   |
>>>                     :          |   | Encryption tunnel, e.g. SASL or 
>>> SSL,
>>>                     :          |   | between the server
>>
>>>           encrypted            |   | Separate tunnels to different
>>>           traffic between      |   | clients.
>>>           Realm A and client   +---+
>>>                                  |
>>>                                  |
>>>                                  +-----------> Traffic to clients
>>
>
> This discussion is confusing and makes no sense to me.  SASL doesn't 
> protect traffic between "realms" and clients; it protects traffic 
> between _servers_ and clients.  This needs to be reworded so it makes 
> sense, in terms of entities known to the SASL framework.  A "realm" is 
> not such an entity; it is no more than part of the autentication 
> identities used by some mechanisms, and has no place outside the 
> mechainsm specification.
>
> Put another way, and ignoring the issue of "realms"; the above 
> description makes so little sense to me that I cannot evaluate its 
> validity or understand what attack we are trying to avoid. 

Ignore for a moment any relationship of realm to DIGEST-MD5, GSSAPI or 
any other SASL mechanism. Let's use the definition I have in the document:

Conceptually, realm is the name of a collection of user's accounts.
Realms allow the protected resources on a server to be partitioned into
a set of protection spaces, each with its own authentication mechanisms
and/or authorization database. For example, a proxy/frontend can use
different realms for different servers/backends it represents.

So, each "realm" ("a protection space") is served by a separate server 
(proxy example above) or a separate process/plugin (frontend-backend 
example). Does it make more sense now?

Alexey

Date: Wed, 08 Oct 2003 23:05:14 +0100
From: Alexey Melnikov <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, Hallvard B Furuseth <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: SASL Realms
Sender: [email-masked]

Hallvard B Furuseth wrote:

>>   Certain SASL mechanisms, e.g. DIGEST-MD5 [SASL-DIGEST], use a concept
>>   of realm. (...)  The realm value is a case-
>>   insensitive string, generally assigned by the origin server, which
>>    
>>
> It seems to me it is not rfc2222bis' business to define realms as 
> case-insensitive. The mechanism definitions can do that. I think 
> rfc2222bis should only say that it usually is case-insensitive, or 
> maybe say that it "SHOULD" be. As it is, a mechanism can define a 
> "case- sensitive realm" if it wants to anyway, provided it confuses 
> the issue by calling it something else than a "realm".

Kurt D. Zeilenga wrote:

>>  A protocol profile SHOULD provide a guidance how realms are to be
>>  constructed and used in the protocol and MAY further restrict its
>>  syntax and protocol-specific semantics.
>>    
>>
>
>I think this SHOULD is not appropriate.  First, interoperability is
>not harmed by protocol profiles not providing such guidance.  Secondly,
>realms should be viewed as part of multi-component authentication
>identity form.  That is, in DIGEST-MD5, the authentication identity
>is composed of two parts, the user's name (username) and the user's
>realm (realm).   Having profiles overload the semantics of the
>any component of the authentication identity breaks the separation
>of mechanism and profile.
>  
>
Jeffrey Hutzelman wrote:

>>>   Certain SASL mechanisms, e.g. DIGEST-MD5 [SASL-DIGEST], use a concept
>>>   of realm.
>>
>>
>> I think it unwise to enter into a discussion of realms here.
>> Realm syntax and semantics are, for mechanisms which have realms,
>> mechanism specific.  The mechanism specification should state how
>> they are to be compared.  The mechanism specification should state
>> how they are to constructed and used in the mechanism and, where
>> appropriate, state any protocol profiling requirements.  (Note:
>> I'd likely doubt any mechanism attempt to state protocol profiling
>> requirements as this breaks SASL's separation of profile and
>> mechanism).
>
> I agree.  A realm is just part of the authentication identities used 
> by certain mechanisms.  It is mechanism-specific, and a discussion of 
> realms is irrelevant to protocol profiling.

Ok, the reason why I've added this text in the first place is because a 
lot of protocol implementors misunderstand what the realm is and is not.
Unfortunately the original text in the DIGEST-MD5 document is too vague 
to be useful. Recent discussion on LDAP mailing list proves this.
I was trying to clarify this, but your are right that the text doesn't 
belong to the base SASL specification.

I will be adding a section to DIGEST-MD5 that tries to give some 
examples of realm usage.

>>>   A protocol profile SHOULD provide a guidance how realms are to be
>>>   constructed and used in the protocol and MAY further restrict its
>>>   syntax and protocol-specific semantics.
>>
> Absolutely not.  Protocols may decide to include some concept of realm 
> in their authorization identities, but they have no business 
> whatsoever defining the semantics of authentication identities.  That 
> is the responsibility of the mechanism. 

Alexey

Date: Thu, 09 Oct 2003 11:35:29 +0100
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Altman <[email-masked]>
CC: [email-masked], "Kurt D. Zeilenga" <[email-masked]>, [email-masked], SASL WG <[email-masked]>
Subject: Re: [xmppwg] Re: Last Call: 'XMPP Core' to Proposed Standard
Sender: [email-masked]

Jeffrey Altman wrote:

>> The requirement that initiating receiving entity drop all knowledge
>> it learned before negotiating SASL layers (rule 5) is too broad.
>> This could be viewed as requiring the implement to forget knowledge
>> it gained previously in a secure manner (such as an externally
>> established lower level (IPSEC or TLS) identity information).
>> Likewise for rule 6.
>
> Rules 5 and 6 are specific to the use of SASL mechanisms which are 
> actively providing encryption/integrity protection.  In this 
> situation, it is known that TLS is not in use. I doubt it is known 
> whether or not IPSec is in use for the entire communication path.  
> Therefore, all information obtained prior to the establishment of 
> encryption/integrity protection must be considered suspect.
>
> I believe the problem is one of language.  Can we replace all 
> references to "security layer" to read "data protection layer"? 

"security layer" is a SASL term, so changing it to something else will 
cause additional confusion.

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

Cell: +44 7753759732

IETF standard related pages:
http://orthanc.ab.ca/mel/devel/Links.html

Personal Home Page: http://orthanc.ab.ca/mel
__________________________________________

Date: Thu, 09 Oct 2003 10:50:53 +0100
From: Alexey Melnikov <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: WG Last Call on draft-ietf-sasl-rfc2222bis-02
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------030505020004070308000607
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Kurt D. Zeilenga wrote:

>>2). Clarification on replacing a security layer
>>    
>>
>
>I would like to hear folks comments on the appropriateness of
>uninstalling layers after a failed subsequent exchange.
>
This is not the issue. What you are talking about violates SASL spec.

The issues is whether to keep the old security layer or remove it
a). in protocols that allow for reauthentication (e.g. LDAP and HTTP)
b). after a second or subsequent successful reauthentication.

Alexey

--------------030505020004070308000607
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Kurt D. Zeilenga wrote:<br>
<blockquote type="cite"
 cite="[email-masked]">
  <blockquote type="cite">
    <pre wrap="">2). Clarification on replacing a security layer
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I would like to hear folks comments on the appropriateness of
uninstalling layers after a failed subsequent exchange.</pre>
</blockquote>
This is not the issue. What you are talking about violates SASL spec.<br>
<br>
The issues is whether to keep the old security layer or remove it<br>
a). in protocols that allow for reauthentication (e.g. LDAP and HTTP)<br>
b). after a second or subsequent successful reauthentication.<br>
<br>
Alexey<br>
<br>
</body>
</html>

--------------030505020004070308000607--

To: "Joseph Salowey" <[email-masked]>
From: Philip Guenther <[email-masked]>
Cc: [email-masked], [email-masked], SASL WG <[email-masked]>
Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard 
Date: Wed, 08 Oct 2003 23:22:20 -0700
Sender: [email-masked]

"Joseph Salowey" <[email-masked]> writes:
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On 
...
>> This only works if the client would have been prepared to do 
>> this weak mechanism over a non-TLS connection.  Generally the 
>> client knows when it expects to do TLS and when it doesn't. 
>
>Agreed.  If the client only uses this mechanism over TLS then this is
>not a problem. How easy this is to enforce depends upon the deployment
>environment, it may be reasonable to assume for XMPP (I'm not very
>familiar with XMPP).  I'm not completely sure, but with some mechanisms
>using the same mechanism without TLS in a different protocol may lead to
>the same problem (If the mechanism does not authenticate the
>protocol/service context).  

For those who don't watch the ietf-announce list or didn't have
their interest perked by the announcement, a discussion of this
problem in the context of EAP can be found in:

http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-03.txt

            The Compound Authentication Binding Problem
...
Abstract

There are several motivations for using compound authentication methods
using tunnels, but man-in-the-middle attacks are possible in certain 
circumstances when they are used, without cryptographically binding the 
methods together. At the time of writing this document, several 
protocols being proposed within the IETF are vulnerable to these 
attacks, including IKE with XAUTH, PIC, PANA over TLS, EAP TTLS and 
PEAP. This document studies the problems and suggests potential 
solutions to mitigate them.

(I have nothing to do with this document; it just seems extremely
relevant and fairly thorough on the point under discussion.  Perhaps
SASL over TLS should be added to the list in the quoted abstract?)

Philip Guenther
[email-masked]

From: "Joseph Salowey" <[email-masked]>
To: "'EKR'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "'SASL WG'" <[email-masked]>
Subject: RE: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard
Date: Wed, 8 Oct 2003 22:19:47 -0700
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eric Rescorla
> Sent: Wednesday, October 08, 2003 10:17 PM
> To: Joseph Salowey
> Cc: [email-masked]; [email-masked]; 'SASL WG'
> Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard
> 
> 
> "Joseph Salowey" <[email-masked]> writes:
> > > How's that again? Please explain the network topology you're
> > > considering here.
> > > 
> > 
> > Ok. I might be misunderstanding something, here is a summary:
> > 
> > A client C that is willing to use SASL mechanism X both inside and 
> > outside a TLS tunnel. A server S that supports a server 
> authenticated 
> > TLS tunnel and then authenticates the client using SASL mechanism X 
> > within the tunnel. An attacker M who can act as a TLS client and a 
> > SASL server for mechanism X.
> > 
> > The network topology/deployment must allow for M to trick C into 
> > trying to authenticate to him using SASL Mechanism X (without TLS) 
> > while M simultaneously establishes a TLS connection with S.
> > 
> > M establishes a TLS session with S
> > M tricks C into trying to authenticate to him using SASL mechanism X
> > without TLS protection (these first steps could happen in 
> the reverse
> > order)
> > M forwards the SASL exchange from C to S and vice versa.  
> > The SASL authentication will succeed and S will believe that the
> > endpoint of the TLS tunnel is C instead of M (For some 
> mechanisms M may
> > have to spoof S's address in order for the authentication 
> to complete).
> > M can disconnect from C and continue sending messages to S.  
> > S thinks the messages from M originate from C. 
> 
> Yes, this will work. But here's the thing:
> 
> This only works if the client would have been prepared to do 
> this weak mechanism over a non-TLS connection.  Generally the 
> client knows when it expects to do TLS and when it doesn't. 
> 

Agreed.  If the client only uses this mechanism over TLS then this is
not a problem. How easy this is to enforce depends upon the deployment
environment, it may be reasonable to assume for XMPP (I'm not very
familiar with XMPP).  I'm not completely sure, but with some mechanisms
using the same mechanism without TLS in a different protocol may lead to
the same problem (If the mechanism does not authenticate the
protocol/service context).  

Joe

Date: Thu, 09 Oct 2003 01:10:06 -0400
From: Jeffrey Altman <[email-masked]>
Organization: Columbia University in the City of New York
To: Joseph Salowey <[email-masked]>
CC: "'EKR'" <[email-masked]>, [email-masked], [email-masked], "'SASL WG'" <[email-masked]>
Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms060502010409050807070001
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Joseph Salowey wrote:

>
>Ok. I might be misunderstanding something, here is a summary:
>
>A client C that is willing to use SASL mechanism X both inside and
>outside a TLS tunnel.
>A server S that supports a server authenticated TLS tunnel and then
>authenticates the client using SASL mechanism X within the tunnel.
>An attacker M who can act as a TLS client and a SASL server for
>mechanism X.
>
>The network topology/deployment must allow for M to trick C into trying
>to authenticate to him using SASL Mechanism X (without TLS) while M
>simultaneously establishes a TLS connection with S. 
>
>M establishes a TLS session with S 
>M tricks C into trying to authenticate to him using SASL mechanism X
>without TLS protection (these first steps could happen in the reverse
>order)
>M forwards the SASL exchange from C to S and vice versa.  
>The SASL authentication will succeed and S will believe that the
>endpoint of the TLS tunnel is C instead of M (For some mechanisms M may
>have to spoof S's address in order for the authentication to complete).
>M can disconnect from C and continue sending messages to S.  
>S thinks the messages from M originate from C. 
>
>Joe
> 
>  
>
As far as I am aware, the endpoints negotiating the TLS tunnel are 
identical to
endpoints negotiating SASL.  Both TLS and SASL are negotiated as part of 
the
same connect/accept operation.

Jeffrey Altman

--------------ms060502010409050807070001
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms060502010409050807070001--

To: "Joseph Salowey" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "'SASL WG'" <[email-masked]>
Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard
Reply-To: EKR <[email-masked]>
From: Eric Rescorla <[email-masked]>
Date: 08 Oct 2003 22:16:31 -0700
Lines: 41
Sender: [email-masked]

"Joseph Salowey" <[email-masked]> writes:
> > How's that again? Please explain the network topology you're 
> > considering here.
> > 
> 
> Ok. I might be misunderstanding something, here is a summary:
> 
> A client C that is willing to use SASL mechanism X both inside and
> outside a TLS tunnel.
> A server S that supports a server authenticated TLS tunnel and then
> authenticates the client using SASL mechanism X within the tunnel.
> An attacker M who can act as a TLS client and a SASL server for
> mechanism X.
> 
> The network topology/deployment must allow for M to trick C into trying
> to authenticate to him using SASL Mechanism X (without TLS) while M
> simultaneously establishes a TLS connection with S. 
> 
> M establishes a TLS session with S 
> M tricks C into trying to authenticate to him using SASL mechanism X
> without TLS protection (these first steps could happen in the reverse
> order)
> M forwards the SASL exchange from C to S and vice versa.  
> The SASL authentication will succeed and S will believe that the
> endpoint of the TLS tunnel is C instead of M (For some mechanisms M may
> have to spoof S's address in order for the authentication to complete).
> M can disconnect from C and continue sending messages to S.  
> S thinks the messages from M originate from C. 

Yes, this will work. But here's the thing:

This only works if the client would have been prepared to do this weak
mechanism over a non-TLS connection.  Generally the client knows when
it expects to do TLS and when it doesn't. 

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

From: "Joseph Salowey" <[email-masked]>
To: "'EKR'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "'SASL WG'" <[email-masked]>
Subject: RE: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard
Date: Wed, 8 Oct 2003 21:53:32 -0700
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eric Rescorla
> Sent: Wednesday, October 08, 2003 9:21 PM
> To: Joseph Salowey
> Cc: [email-masked]; [email-masked]; 'SASL WG'
> Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard
> 
> 
> "Joseph Salowey" <[email-masked]> writes:
> 
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Eric Rescorla
> > > Sent: Wednesday, October 08, 2003 1:28 PM
> > > To: [email-masked]
> > > Cc: [email-masked]; SASL WG
> > > Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard
> > > 
> > > 
> > > 
> > > "Kurt D. Zeilenga" <[email-masked]> writes:
> > > > I concur with Alexey's recent comments regarding XMPP's
> > > SASL Profile.
> > > > I have a few addition concerns regarding this profile. The
> > > scope of my
> > > > review was, due to time constraints, was limited to the profile.
> > > > 
> > > > I not sure why the documents says that SASL and TLS security 
> > > > layers
> > > > SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), 
> > > but this
> > > > recommendation is, I believe, flawed.  There are numerous use 
> > > > cases
> > > > where implementations SHOULD establish additional layers. 
> > > For example,
> > > > establishing additional SASL layers may prevent certain kinds of
> > > > tunneling man-in-the-middle attacks.
> > > Could you describe some of them?
> > > 
> > 
> > If the TLS tunnel is only server authenticated and the 
> client supports 
> > a particular SASL method (perhaps even in a different protocol)that 
> > provides mutual authentication both inside and outside a TLS tunnel 
> > there is a vulnerability.  In this case if only the message 
> protection 
> > of TLS is used you cannot be sure that the client endpoint 
> of the TLS 
> > tunnel is the same client endpoint that the server 
> authenticated with 
> > SASL.
> 
> How's that again? Please explain the network topology you're 
> considering here.
> 

Ok. I might be misunderstanding something, here is a summary:

A client C that is willing to use SASL mechanism X both inside and
outside a TLS tunnel.
A server S that supports a server authenticated TLS tunnel and then
authenticates the client using SASL mechanism X within the tunnel.
An attacker M who can act as a TLS client and a SASL server for
mechanism X.

The network topology/deployment must allow for M to trick C into trying
to authenticate to him using SASL Mechanism X (without TLS) while M
simultaneously establishes a TLS connection with S. 

M establishes a TLS session with S 
M tricks C into trying to authenticate to him using SASL mechanism X
without TLS protection (these first steps could happen in the reverse
order)
M forwards the SASL exchange from C to S and vice versa.  
The SASL authentication will succeed and S will believe that the
endpoint of the TLS tunnel is C instead of M (For some mechanisms M may
have to spoof S's address in order for the authentication to complete).
M can disconnect from C and continue sending messages to S.  
S thinks the messages from M originate from C. 

Joe

To: "Joseph Salowey" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "'SASL WG'" <[email-masked]>
Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard
Reply-To: EKR <[email-masked]>
From: Eric Rescorla <[email-masked]>
Date: 08 Oct 2003 21:20:35 -0700
Lines: 46
Sender: [email-masked]

"Joseph Salowey" <[email-masked]> writes:

> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Eric Rescorla
> > Sent: Wednesday, October 08, 2003 1:28 PM
> > To: [email-masked]
> > Cc: [email-masked]; SASL WG
> > Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard
> > 
> > 
> > 
> > "Kurt D. Zeilenga" <[email-masked]> writes:
> > > I concur with Alexey's recent comments regarding XMPP's 
> > SASL Profile.  
> > > I have a few addition concerns regarding this profile. The 
> > scope of my 
> > > review was, due to time constraints, was limited to the profile.
> > > 
> > > I not sure why the documents says that SASL and TLS security layers 
> > > SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), 
> > but this 
> > > recommendation is, I believe, flawed.  There are numerous use cases 
> > > where implementations SHOULD establish additional layers. 
> > For example, 
> > > establishing additional SASL layers may prevent certain kinds of 
> > > tunneling man-in-the-middle attacks.
> > Could you describe some of them?
> > 
> 
> If the TLS tunnel is only server authenticated and the client supports a
> particular SASL method (perhaps even in a different protocol)that
> provides mutual authentication both inside and outside a TLS tunnel
> there is a vulnerability.  In this case if only the message protection
> of TLS is used you cannot be sure that the client endpoint of the TLS
> tunnel is the same client endpoint that the server authenticated with
> SASL.  

How's that again? Please explain the network topology you're considering
here.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

From: "Joseph Salowey" <[email-masked]>
To: "'EKR'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "'SASL WG'" <[email-masked]>
Subject: RE: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard
Date: Wed, 8 Oct 2003 20:40:43 -0700
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eric Rescorla
> Sent: Wednesday, October 08, 2003 1:28 PM
> To: [email-masked]
> Cc: [email-masked]; SASL WG
> Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard
> 
> 
> 
> "Kurt D. Zeilenga" <[email-masked]> writes:
> > I concur with Alexey's recent comments regarding XMPP's 
> SASL Profile.  
> > I have a few addition concerns regarding this profile. The 
> scope of my 
> > review was, due to time constraints, was limited to the profile.
> > 
> > I not sure why the documents says that SASL and TLS security layers 
> > SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), 
> but this 
> > recommendation is, I believe, flawed.  There are numerous use cases 
> > where implementations SHOULD establish additional layers. 
> For example, 
> > establishing additional SASL layers may prevent certain kinds of 
> > tunneling man-in-the-middle attacks.
> Could you describe some of them?
> 

If the TLS tunnel is only server authenticated and the client supports a
particular SASL method (perhaps even in a different protocol)that
provides mutual authentication both inside and outside a TLS tunnel
there is a vulnerability.  In this case if only the message protection
of TLS is used you cannot be sure that the client endpoint of the TLS
tunnel is the same client endpoint that the server authenticated with
SASL.  

To mitigate this problem you can: 

- Use the protection from the inner SASL method
- Have the SASL authentication mechanism authenticate the TLS Session ID
or some similar parameter 
- Require different credentials be used by a SASL mechanism when
operating inside or outside a TLS tunnel.   

Joe

> -Ekr
> 
> -- 
> [Eric Rescorla                                   [email-masked]]
>                 http://www.rtfm.com/
> 

To: [email-masked]
Cc: "Kurt D. Zeilenga" <[email-masked]>, [email-masked], SASL WG <[email-masked]>
Subject: Re: [xmppwg] Re: Last Call: 'XMPP Core' to Proposed Standard
From: Sam Hartman <[email-masked]>
Date: Wed, 08 Oct 2003 20:47:49 -0400
Sender: [email-masked]

Do we actually need to have this argument here?  I tend to agree with
Kurt but it's not clear that having this discussion will actually
influence the draft.

Jeff, do you see anything wrong with allowing a SASL security layer
and TLS to be used in conjunction?  If I'm reading your argument
right, you have not actually presented any argument against this
configuration, you have just argued that Kurt's reason for wanting to
do so is not correct.

Date: Wed, 08 Oct 2003 17:24:30 -0700
To: Jeffrey Altman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard
Cc: EKR <[email-masked]>, [email-masked], [email-masked], SASL WG <[email-masked]>
Sender: [email-masked]

At 04:37 PM 10/8/2003, Jeffrey Altman wrote:
>Kurt D. Zeilenga wrote:
>
>>At 01:28 PM 10/8/2003, Eric Rescorla wrote:
>> 
>>
>>>"Kurt D. Zeilenga" <[email-masked]> writes:
>>>   
>>>
>>>>I concur with Alexey's recent comments regarding XMPP's SASL
>>>>Profile.  I have a few addition concerns regarding this profile.
>>>>The scope of my review was, due to time constraints, was limited
>>>>to the profile.
>>>>
>>>>I not sure why the documents says that SASL and TLS security
>>>>layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2),
>>>>but this recommendation is, I believe, flawed.  There are numerous use
>>>>cases where implementations SHOULD establish additional layers.
>>>>For example, establishing additional SASL layers may prevent
>>>>certain kinds of tunneling man-in-the-middle attacks.
>>>>     
>>>Could you describe some of them?
>>>   
>>
>>XMPP's TLS profile allows establishment of TLS even though the
>>implementation's certificate verification has failed:
>> If the above methods fail, the certificate SHOULD be presented
>> to a human (e.g., an end user or server administrator) for
>> approval; if presented, the receiver MUST deliver the entire
>> certificate chain to the human, who SHOULD be given the option
>> to store the Root CA certificate (not the service or End Entity
>> certificate) and to not be queried again regarding acceptance of
>> the certificate for some reasonable period of time.
>>
>>Given the likelihood that the end user will inappropriately
>>accept the certificate, attackers can easily insert a
>>TLS-protected machine in the middle.  Given this, it is quite
>>reasonable for implementors to offer (and deployers to demand)
>>additional safeguards.
>>
>>Kurt  
>If the policy requirement of the deployers is to not accept the risk
>that the end user will accept certificate chains which cannot be verified
>by algorithmic means,

The policy might be to mitigate the risk that users won't do the
appropriate checks by requiring an additional layer of security.

>There is zero benefit to negotiating both TLS and SASL encryption/integrity
>protection.

I disagree.  Multiple layer defenses have benefits.

Kurt 

Date: Wed, 08 Oct 2003 19:37:37 -0400
From: Jeffrey Altman <[email-masked]>
Organization: Columbia University in the City of New York
To: "Kurt D. Zeilenga" <[email-masked]>
CC: EKR <[email-masked]>, [email-masked], [email-masked], SASL WG <[email-masked]>
Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms050600070607010700010909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Kurt D. Zeilenga wrote:

>At 01:28 PM 10/8/2003, Eric Rescorla wrote:
>  
>
>>"Kurt D. Zeilenga" <[email-masked]> writes:
>>    
>>
>>>I concur with Alexey's recent comments regarding XMPP's SASL
>>>Profile.  I have a few addition concerns regarding this profile.
>>>The scope of my review was, due to time constraints, was limited
>>>to the profile.
>>>
>>>I not sure why the documents says that SASL and TLS security
>>>layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2),
>>>but this recommendation is, I believe, flawed.  There are numerous use
>>>cases where implementations SHOULD establish additional layers.
>>>For example, establishing additional SASL layers may prevent
>>>certain kinds of tunneling man-in-the-middle attacks.
>>>      
>>>
>>Could you describe some of them?
>>    
>>
>
>XMPP's TLS profile allows establishment of TLS even though the
>implementation's certificate verification has failed:
>  If the above methods fail, the certificate SHOULD be presented
>  to a human (e.g., an end user or server administrator) for
>  approval; if presented, the receiver MUST deliver the entire
>  certificate chain to the human, who SHOULD be given the option
>  to store the Root CA certificate (not the service or End Entity
>  certificate) and to not be queried again regarding acceptance of
>  the certificate for some reasonable period of time.
>
>Given the likelihood that the end user will inappropriately
>accept the certificate, attackers can easily insert a
>TLS-protected machine in the middle.  Given this, it is quite
>reasonable for implementors to offer (and deployers to demand)
>additional safeguards.
>
>Kurt 
>  
>
If the policy requirement of the deployers is to not accept the risk
that the end user will accept certificate chains which cannot be verified
by algorithmic means, then the policy should fail the certificate validation
without presenting the certificates to the end user.  The TLS session at
that point must be aborted.  At this point the TCP session must be closed.

When XMPP attempts to reconnect, it must not attempt to establish a TLS 
session
and in turn must attempt to negotiate a SASL mechanism which provides
encryption/integrity protection. 

There is zero benefit to negotiating both TLS and SASL encryption/integrity
protection.

Btw, if it is possible for SASL to validate the TLS Client and Server 
Finished
messages as computed by both the client and server, this can be 
performed during
SASL authentication to detect a man-in-the-middle attack.  This is the 
process
which is used in TELNET START-TLS when combined with TELNET AUTH. 

Jeffrey Altman

--------------ms050600070607010700010909
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms050600070607010700010909--

Date: Wed, 08 Oct 2003 19:14:11 -0400
From: Jeffrey Altman <[email-masked]>
Organization: Columbia University in the City of New York
To: "Kurt D. Zeilenga" <[email-masked]>
CC: [email-masked], [email-masked], SASL WG <[email-masked]>
Subject: Re: Last Call: 'XMPP Core' to Proposed Standard
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms090408090503010507000209
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Kurt D. Zeilenga wrote:

>To the IESG,
>
>I concur with Alexey's recent comments regarding XMPP's SASL
>Profile.  I have a few addition concerns regarding this profile.
>The scope of my review was, due to time constraints, was limited
>to the profile.
>
>I not sure why the documents says that SASL and TLS security
>layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2),
>but this recommendation is, I believe, flawed.  There are numerous use
>cases where implementations SHOULD establish additional layers.
>For example, establishing additional SASL layers may prevent
>certain kinds of tunneling man-in-the-middle attacks.
>  
>
The "security" is specific to the SASL encryption and integrity 
protection; not authentication.  Clearly, SASL authentication might be 
used to help detect a man-in-the-middle attack.  If you are arguing that 
SASL encryption/integrity protection should be used on top of TLS 
encryption/integrity protection, the only reason for doing so is that 
you do not trust the TLS encryption/integrity protection.  I do not see 
where the man-in-the-middle attack would be coming from?

>The requirement that initiating receiving entity drop all knowledge
>it learned before negotiating SASL layers (rule 5) is too broad.
>This could be viewed as requiring the implement to forget knowledge
>it gained previously in a secure manner (such as an externally
>established lower level (IPSEC or TLS) identity information).
>Likewise for rule 6.
>  
>
Rules 5 and 6 are specific to the use of SASL mechanisms which are 
actively providing encryption/integrity protection.  In this situation, 
it is known that TLS is not in use.  I doubt it is known whether or not 
IPSec is in use for the entire communication path.  Therefore, all 
information obtained prior to the establishment of encryption/integrity 
protection must be considered suspect.

I believe the problem is one of language.  Can we replace all references 
to "security layer" to read "data protection layer"?

>I am also concerned by the use of the term "stream encryption"
>in the document as this doesn't imply, in my eyes, "stream
>integrity".   It's unclear to me which imperatives imply when
>encryption, integrity, and/or in combination with other security
>services which TLS provides.
>  
>

I agree.  We are not concerned with Stream Encryption but Data 
Protection.  Replace "Stream Encryption" with "Data Protection" throughout.

I have not completed a security review of these documents as yet.  I am 
simply responding to Kurt's comments.

Jeffrey Altman

--------------ms090408090503010507000209
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms090408090503010507000209--

Date: Thu, 09 Oct 2003 03:41:49 -0700
To: EKR <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard
Cc: [email-masked], [email-masked], SASL WG <[email-masked]>
Sender: [email-masked]

At 01:28 PM 10/8/2003, Eric Rescorla wrote:
>"Kurt D. Zeilenga" <[email-masked]> writes:
>> I concur with Alexey's recent comments regarding XMPP's SASL
>> Profile.  I have a few addition concerns regarding this profile.
>> The scope of my review was, due to time constraints, was limited
>> to the profile.
>> 
>> I not sure why the documents says that SASL and TLS security
>> layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2),
>> but this recommendation is, I believe, flawed.  There are numerous use
>> cases where implementations SHOULD establish additional layers.
>> For example, establishing additional SASL layers may prevent
>> certain kinds of tunneling man-in-the-middle attacks.
>Could you describe some of them?

XMPP's TLS profile allows establishment of TLS even though the
implementation's certificate verification has failed:
  If the above methods fail, the certificate SHOULD be presented
  to a human (e.g., an end user or server administrator) for
  approval; if presented, the receiver MUST deliver the entire
  certificate chain to the human, who SHOULD be given the option
  to store the Root CA certificate (not the service or End Entity
  certificate) and to not be queried again regarding acceptance of
  the certificate for some reasonable period of time.

Given the likelihood that the end user will inappropriately
accept the certificate, attackers can easily insert a
TLS-protected machine in the middle.  Given this, it is quite
reasonable for implementors to offer (and deployers to demand)
additional safeguards.

Kurt 

Date: Thu, 09 Oct 2003 03:04:16 -0700
To: Jeffrey Hutzelman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

At 07:19 AM 10/8/2003, Jeffrey Hutzelman wrote:
>>Would you rather reference the SASL WG as the Change Controller?
>
>No, especially since the SASL WG will likely conclude within the foreseeable future. 

The IESG should have change control mechanisms registered by
Standards Action.

Kurt 

Date: Thu, 09 Oct 2003 02:01:48 -0700
To: Alexey Melnikov <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: WG Last Call on draft-ietf-sasl-rfc2222bis-02
Cc: SASL WG <[email-masked]>
Sender: [email-masked]

At 06:58 AM 10/8/2003, Alexey Melnikov wrote:
>I have an impression that there are two many little things to change so that we will need a new Last Call anyway.
>Is my perception correct?

Yes.  Given the large number of issues, I prefer to give you
as fairly wide latitude to make the changes you believe are
appropriate.  Once a new I-D is ready, we'll then ask the
WG to review the I-D to see consensus supports the changes
made and the document as a whole.

>If it is, I will issue a new revision shortly.

Great!

>Below is the list of open issues I still have to deal with (read this: I am planning to either update the document or send my comments):
>1). IANA considerations and registering a familily of SASL mechanisms.

You might look at BCP 64 (RFC 3383) guidelines for OID
descriptors and families of OID descriptors as an example.

>2). Clarification on replacing a security layer

I would like to hear folks comments on the appropriateness of
uninstalling layers after a failed subsequent exchange.

>3). Realm

I have not yet heard any arguments to keep the realm text.

Kurt 

Date: Wed, 08 Oct 2003 16:52:59 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
CC: [email-masked], SASL WG <[email-masked]>
Subject: Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard)
Sender: [email-masked]

White space and CRLFs were specifically allowed in the original MIME base64 
specification because of:

	line length limitations in the underlying protocols

	gateways that would add or subtract white space willy-nilly

	it was useful being able to work with base64 data in small chunks when
	doing development and debugging

The first two issues don't apply here, but the last one certainly still does.

So I'd recommend that whitespace and CRLFs be ignored.

	Tony Hansen
	[email-masked]

Alexey Melnikov wrote:
> The IESG wrote:
> 
>> The IESG has received a request from the Extensible Messaging and 
>> Presence Protocol WG to consider the following document:
>>
>> - 'XMPP Core '
>>   <draft-ietf-xmpp-core-18.txt> as a Proposed Standard
> 
> 4). There was a recent discussion on the bugtraq mailing list about 
> handling invalid base64 data. It turned out that different 
> implementations handle
> this differently, for example:
> 1). Ignore invalid characters
> 2). Treat an invalid character as the end of the base64 encoded data 
> (and ignore the rest)
> 3). Truncate base64 encoded data before the invalid character.
> 
> In particular there was a discussion regarding the padding character 
> ('=') in the middle of a base64 data.
> 
> I suggest that some text about this be added to the Security 
> considerations sections. For example:
> 
> Both the client and the server should verify the received base64 data 
> and reject (and not ignore) any characters not explicitly allowed by the 
> base64 alphabet
> [BASE64] and should reject any sequence of base64 characters that 
> contains the pad ('=') character not as the last
> character of the (e.g. "=AAA" or "BBBB=CCC").
> 
> [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 
> RFC 3548, July 2003.
> 
> (You might decide to relax this for XMPP and to allow spaces and/or 
> CRLFs anywhere in the data.)

Date: Thu, 09 Oct 2003 01:45:45 -0700
To: Alexey Melnikov <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments
Cc: Hallvard B Furuseth <[email-masked]>, [email-masked]
Sender: [email-masked]

At 04:52 AM 10/8/2003, Alexey Melnikov wrote:
>>>  In
>>>  order to avoid noninteroperability due to differing normalizations,
>>>  when a mechanism specifies that a string authentication identity or
>>>  password used as input to a cryptographic function (or used for
>>>  comparison) it SHOULD specify that the string first be prepared using
>>>  the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm
>>>  [StringPrep].  This should be done by both the client (upon getting
>>>  user input or retrieving a value from configuration) and by the
>>>  server (upon receiving the value from the client).
>>>   
>>
>>What's the point of this duplicate preparation?  Why not do it only
>>at the server side?
>> 
>Because if the client doesn't do that, the hash calculated on the server will not match the one calculated on the client. 

Alexey, the current text suggests that client (1) prep the
value before sending, the server then preps it (2) again
(before comparing it to the store value, which also should
be prep'ed (3) either before storing it or before each compare).

We need to REQUIRE that mechanisms specify how character strings
are to be prepared for comparison and RECOMMEND that they use
SASLprep for simple user names and passwords.

We should not suggest that mechanisms should do both (1) and
(2).  (1) and (3) OR (2) or (3) are sufficient to ensure
proper matching.

Kurt

To: [email-masked]
Cc: [email-masked], SASL WG <[email-masked]>
Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard
Reply-To: EKR <[email-masked]>
From: Eric Rescorla <[email-masked]>
Date: 08 Oct 2003 13:28:14 -0700
Lines: 19
Sender: [email-masked]

"Kurt D. Zeilenga" <[email-masked]> writes:
> I concur with Alexey's recent comments regarding XMPP's SASL
> Profile.  I have a few addition concerns regarding this profile.
> The scope of my review was, due to time constraints, was limited
> to the profile.
> 
> I not sure why the documents says that SASL and TLS security
> layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2),
> but this recommendation is, I believe, flawed.  There are numerous use
> cases where implementations SHOULD establish additional layers.
> For example, establishing additional SASL layers may prevent
> certain kinds of tunneling man-in-the-middle attacks.
Could you describe some of them?

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

Date: Wed, 08 Oct 2003 20:31:34 +0100
From: Alexey Melnikov <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
CC: [email-masked], Jeremie Miller <[email-masked]>, [email-masked], SASL WG <[email-masked]>
Subject: Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard)
Sender: [email-masked]

Peter Saint-Andre wrote:

>>1).
>>    
>>
>>>  7.  The initiating entity MUST provide an authzid during SASL
>>>      negotiation. The authzid-value MUST be a valid JID of the form
>>>      <domain> (i.e., a domain identifier only) for servers and of the
>>>      form <user@domain/resource> (i.e., node identifier, domain
>>>      identifier, and resource identifier) for clients. The initiating
>>>      entity MAY process the authzid-value in accordance with the rules
>>>      defined in Addressing Scheme (Section 3) before providing it to
>>>      the receiving entity, but is NOT REQUIRED to do so; however, the
>>>      receiving entity MUST verify that the authzid-value provided by
>>>      the initiating entity conforms to the rules defined therein.
>>>      
>>>
>>Not all SASL mechanisms are capable of transmitting authorization 
>>identity, so this requirement might be problematic.
>>
>>Also, the revision of RFC 2222 says that the client must not specify 
>>authorization-id unless it wants to impersonate some other entity:
>>
>>  As a client might not have the same information as the server,
>>  clients SHOULD NOT themselves try to derive authorization identities
>>  from authentication identities when clients could instead transmit an
>>  authorization identity of the empty string.
>>
>>So, the text should be reworded reflect that an authorization identity 
>>is optional and that if one is provided, it is in the form described above.
>>    
>>
>
>My understanding from an earlier thread on the XMPP WG list was that
>providing the authorization identity in this manner was the approach
>preferred by the SASL community. I think the fundamental issue here is
>that for XMPP clients, the authorization identity is a "full JID" (i.e.,
>node@host/resource) that is asserted by the connecting client, not
>derived by the server. Perhaps this usage is not consistent with the
>definition of authorization identity in RFC 2222? We'd have to look at
>the implications of this for client assertion of a full JID (perhaps
>this should be defined only in draft-ietf-xmpp-im).
>
There are two issues here:
1). Format of an authorization identity - your document has to define it
2). Requirement to always specify authorization identity.

Short answer to the second issue is probably "you can't do that".
But here I will try to give a long answer to explain that you probably 
don't need 2 anyway.

This is a bit tricky. SASL defines two types of identities. 
Authentication identity is derived from your authentication credentials 
and its format is SASL mechanism specific. Authorization identity is 
protocol specific. If authorization identity is not specified ("empty 
authorization identity"), it is derived from the authentication 
identity. This is the usual case ("just act as yourself").

However is authorization identity is specified, additional authorization 
checks take place. The server has to verify that the authentication 
identity can act as the authorization identity.  Authorization identity 
is useful, for example, when an administrator (or proxy server) wants to 
authenticate as himself, but act as the user.
In XMPP case I can also imagine a client that tries to authenticate as 
"node@host", but act as "node@host/resource".

So, what does this means for a server implementor? The text below 
describes my implementation experience and doesn't specify a standard of 
any kind.

Usually deployed SASL mechanisms (PLAIN/CRAM-MD5/DIGEST-MD5) don't put 
any restrictions on how an authentication identity looks like.
So, in most cases "node@host/resource" (for the client-to-server) or 
"host" (for the server-to-server) format will be used.

For Kerberos mechanisms (KERBEROS_V4, GSSAPI), authentication identity 
has the format dictated by Kerberos (usually user@realm or 
service@realm). An XMPP implementation will have to internally map 
Kerberos principals to XMPP JID format (or host), before verifying an 
authorization identity, if the one was provided.

Of course, there is also SASL EXTERNAL that can be used together with 
TLS. In this case authentication identity will have syntax of a DN.

The bottom line is that the syntax used for authorization identities for 
a protocol is [most likely] the syntax that is going to be used 
internally by the server and is the same syntax that is used by the user 
in the "enter your username" dialog for the protocol.

(Hopefully this makes sense ;-)).

So, the paragraph should probable read:

 7.  An authorization identity used in SASL is a valid JID of the form
      <domain> (i.e., a domain identifier only) for servers and of the
      form <user@domain/resource> (i.e., node identifier, domain
      identifier, and resource identifier) for clients. ...

Regards,
Alexey
__________________________________________
Isode Limited, http://www.isode.com

Cell: +44 7753759732

IETF standard related pages:
http://orthanc.ab.ca/mel/devel/Links.html

Personal Home Page: http://orthanc.ab.ca/mel
__________________________________________

Date: Wed, 08 Oct 2003 20:10:23 +0100
From: Alexey Melnikov <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
CC: [email-masked], Jeremie Miller <[email-masked]>, [email-masked], SASL WG <[email-masked]>
Subject: Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard)
Sender: [email-masked]

Peter Saint-Andre wrote:

>>2).
>>    
>>
>>>  This series of challenge/response pairs continues until one of three
>>>  things happens:
>>>
>>>  1.  The initiating entity aborts the handshake by sending an <abort/>
>>>      element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl'
>>>      namespace to the receiving entity. Upon receiving the <abort/>
>>>      element, the receiving entity MUST terminate the TCP connection.
>>>      
>>>
>>I think the requirement to drop TCP connection is unreasonable here.
>>There are several valid reasons why the client may retry failed 
>>authentication:
>>1). User typed in a wrong password, the client should retry the same 
>>SASL mechanism a reasonable number of times.
>>2). The client invoked a SASL mechanism that reported that it can't be 
>>used because of misconfiguration (e.g. kerberos configuration file is 
>>missing). The client than sends <abort/> to the server and tries another 
>>mechanism.
>>    
>>
>
>This seems reasonable. I think we were attempting to ensure that the
>connecting entity could not abuse the opened TCP connection for an
>unspecified period of time.
>
Closing connection or refusing to perform any tasks after a certain 
number of failures are two common implementation practice in SMTP and 
other protocols.
I think you should mention them, but don't require everyone to implement 
them.

>>3).
>>    
>>
>>>  3.  The receiving entity reports success of the handshake by sending
>>>      a <success/> element qualified by the
>>>      'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating
>>>      entity; this element MAY optionally contain character data (in
>>>      SASL terminology "additional data with success"). Upon receiving
>>>      the <success/> element, the initiating entity MUST initiate a new
>>>      stream by sending an opening XML stream header to the receiving
>>>      entity (it is not necessary to send a closing </stream:stream>
>>>      element first, since the receiving entity and initiating entity
>>>      MUST consider the original stream to be closed upon sending or
>>>      receiving the <success/> element). Upon receiving the new stream
>>>      header from the initiating entity, the receiving entity MUST
>>>      respond by sending a new XML stream header to the initiating
>>>      entity, along with any remaining available features (but NOT
>>>      including the STARTTLS feature or any authentication mechanisms)
>>>      or an empty features element (to signify that no additional
>>>      features are available); note that any such additional features
>>>      are not defined herein, and MUST be defined by the relevant
>>>      extension to XMPP.
>>>      
>>>
>>Other protocols (IMAP/SMTP/POP) list available SASL mechanisms after a 
>>successful SASL authentication.
>>Some of them require that the client compares the list of the advertised 
>>mechanism with the one before the authentication.
>>This is done to prevent man-in-the-middle attacks when an attacker 
>>removes strong SASL mechanisms from the list of supported mechanisms.
>>(Whether this check is useful in practice is another matter. I am not 
>>sure whether anybody implements it).
>>    
>>
>
>OK, I'll look at what those other protocols require, and how they word
>the requirement. It seems good to have this check in place. 
>
I don't have a strong feeling about this. I am just emphasizing the 
difference between other protocols and XMPP in this case.

A security person should comment on this.

>>4). There was a recent discussion on the bugtraq mailing list about 
>>handling invalid base64 data. It turned out that different 
>>implementations handle
>>this differently, for example:
>>...
>>
>>(You might decide to relax this for XMPP and to allow spaces and/or 
>>CRLFs anywhere in the data.)
>>    
>>
>
>I see no strong reason to relax the requirement just for XMPP.
>
This is fine. I was just thinking about a base64 encoder that enforces a 
line length limit and will insert CRLF automatically.

>>5).
>>    
>>
>>>6.3 SASL Errors
>>>
>>>  o  <bad-protocol/> -- The data provided by the initiating entity
>>>     could not be processed, e.g. because does not adhere to the
>>>     protocol for the requested mechanism; sent in response to the
>>>     <response/> element.
>>>      
>>>
>>Do you mean invalid base64 encoding here or something else?
>>    
>>
>
>It could be invalid base64 encoding, but we were thinking especially
>that the decoded response is not consistent with the challenge format
>required by the selected SASL mechanism.
>  
>
Challenge format is specific to a SASL mechanism. As far as the protocol 
using SASL is concerned, invalid SASL mechanism format is not different 
from "authentication failure".
An error from a SASL mechanism is different from an error resulting in 
inability to decode base64 data.
These errors happen at different layers, so they should have different 
error tags.

Regards,
Alexey
__________________________________________
Isode Limited, http://www.isode.com

Cell: +44 7753759732

IETF standard related pages:
http://orthanc.ab.ca/mel/devel/Links.html

Personal Home Page: http://orthanc.ab.ca/mel
__________________________________________

Date: Wed, 8 Oct 2003 14:24:40 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
cc: [email-masked], Jeremie Miller <[email-masked]>, [email-masked], SASL WG <[email-masked]>
Subject: Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard)
Sender: [email-masked]

On Wed, 8 Oct 2003, Peter Saint-Andre wrote:

> > Other protocols (IMAP/SMTP/POP) list available SASL mechanisms after a
> > successful SASL authentication.
> > Some of them require that the client compares the list of the advertised
> > mechanism with the one before the authentication.

This claim isn't true.  SMTP has a MAY for this, the other protocols don't
express an opinion one way or the other.  I know some IMAP and POP
implementations remove the capability after a successful authentication
(to indicate that the AUTHENTICATE/AUTH command is no longer valid)

> > This is done to prevent man-in-the-middle attacks when an attacker
> > removes strong SASL mechanisms from the list of supported mechanisms.
> > (Whether this check is useful in practice is another matter. I am not
> > sure whether anybody implements it).
>
> OK, I'll look at what those other protocols require, and how they word
> the requirement. It seems good to have this check in place.

I'm not sure its terribly useful, since the real way to prevent this MitM
attack is that a client should not use a mechanism that does not support
its minimum security requirements, not find out after the fact that you
have an active attacker.

I will also be posting IDs within the next few days that are revisions to
RFC 1734 (and the SASL bits of RFC 2449) and RFC 2554, which may also be
useful to look at (hopefully they will be clearer).

-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, 08 Oct 2003 22:56:38 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Last Call: 'XMPP Core' to Proposed Standard
Cc: [email-masked], SASL WG <[email-masked]>
Sender: [email-masked]

To the IESG,

I concur with Alexey's recent comments regarding XMPP's SASL
Profile.  I have a few addition concerns regarding this profile.
The scope of my review was, due to time constraints, was limited
to the profile.

I not sure why the documents says that SASL and TLS security
layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2),
but this recommendation is, I believe, flawed.  There are numerous use
cases where implementations SHOULD establish additional layers.
For example, establishing additional SASL layers may prevent
certain kinds of tunneling man-in-the-middle attacks.

The requirement that initiating receiving entity drop all knowledge
it learned before negotiating SASL layers (rule 5) is too broad.
This could be viewed as requiring the implement to forget knowledge
it gained previously in a secure manner (such as an externally
established lower level (IPSEC or TLS) identity information).
Likewise for rule 6.

For rule 8, a normative reference to the base64 encoding algorithm
should be provided.

I am also concerned by the use of the term "stream encryption"
in the document as this doesn't imply, in my eyes, "stream
integrity".   It's unclear to me which imperatives imply when
encryption, integrity, and/or in combination with other security
services which TLS provides.

Additionally, I would like to note that the document suffers
from a number of nits.  As I only did a casual scan, this
list is likely no where near complete.  I suggest that XMMP
WG members be asked to do a more careful review for nits.

	Acronym not spelled out in title: XMMP
	Citiation in abstract
	Used old citation style (numeric tags instead of mnemonic tags)
	Acronyms not spelled out on first use in Abstract: XML
	Table of contents too long
	Acronyms not spelled out on first use in body: XML, JID
	Confusing upper casing of words: COULD
	Odd use of 2119 keywords: "MAY optionally"

To: Ken Murchison <[email-masked]>, "Kurt D. Zeilenga" <[email-masked]>, Steven F Siirila <[email-masked]>, SASL mailing list <[email-masked]>
Subject: Re: draft-murchison-sasl-login-00  Last Call
From: Sam Hartman <[email-masked]>
Date: Wed, 08 Oct 2003 13:49:38 -0400
Sender: [email-masked]

It seems like you may want to document clearly the interoperability
concern.  Mention specific products as examples if it makes your text
more clear.  Just make sure your claims are accurate.

Date: Wed, 8 Oct 2003 12:40:46 -0500
From: Peter Saint-Andre <[email-masked]>
To: [email-masked]
Cc: Jeremie Miller <[email-masked]>, [email-masked], SASL WG <[email-masked]>
Subject: Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard)
Sender: [email-masked]

On Tue, Oct 07, 2003 at 10:49:33PM +0100, Alexey Melnikov wrote:

> I would like to raise several SASL related issues in XMPP document.
> (Sorry for crosspost and sorry for being late with reviewing this.)

No apologies necessary -- your feedback is appreciated.

> 1).
> >   7.  The initiating entity MUST provide an authzid during SASL
> >       negotiation. The authzid-value MUST be a valid JID of the form
> >       <domain> (i.e., a domain identifier only) for servers and of the
> >       form <user@domain/resource> (i.e., node identifier, domain
> >       identifier, and resource identifier) for clients. The initiating
> >       entity MAY process the authzid-value in accordance with the rules
> >       defined in Addressing Scheme (Section 3) before providing it to
> >       the receiving entity, but is NOT REQUIRED to do so; however, the
> >       receiving entity MUST verify that the authzid-value provided by
> >       the initiating entity conforms to the rules defined therein.
> 
> Not all SASL mechanisms are capable of transmitting authorization 
> identity, so this requirement might be problematic.
> 
> Also, the revision of RFC 2222 says that the client must not specify 
> authorization-id unless it wants to impersonate some other entity:
> 
>   As a client might not have the same information as the server,
>   clients SHOULD NOT themselves try to derive authorization identities
>   from authentication identities when clients could instead transmit an
>   authorization identity of the empty string.
> 
> So, the text should be reworded reflect that an authorization identity 
> is optional and that if one is provided, it is in the form described above.

My understanding from an earlier thread on the XMPP WG list was that
providing the authorization identity in this manner was the approach
preferred by the SASL community. I think the fundamental issue here is
that for XMPP clients, the authorization identity is a "full JID" (i.e.,
node@host/resource) that is asserted by the connecting client, not
derived by the server. Perhaps this usage is not consistent with the
definition of authorization identity in RFC 2222? We'd have to look at
the implications of this for client assertion of a full JID (perhaps
this should be defined only in draft-ietf-xmpp-im).

> 2).
> 
> >   This series of challenge/response pairs continues until one of three
> >   things happens:
> >
> >   1.  The initiating entity aborts the handshake by sending an <abort/>
> >       element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl'
> >       namespace to the receiving entity. Upon receiving the <abort/>
> >       element, the receiving entity MUST terminate the TCP connection.
> 
> I think the requirement to drop TCP connection is unreasonable here.
> There are several valid reasons why the client may retry failed 
> authentication:
> 1). User typed in a wrong password, the client should retry the same 
> SASL mechanism a reasonable number of times.
> 2). The client invoked a SASL mechanism that reported that it can't be 
> used because of misconfiguration (e.g. kerberos configuration file is 
> missing). The client than sends <abort/> to the server and tries another 
> mechanism.

This seems reasonable. I think we were attempting to ensure that the
connecting entity could not abuse the opened TCP connection for an
unspecified period of time.

> 3).
> 
> >   3.  The receiving entity reports success of the handshake by sending
> >       a <success/> element qualified by the
> >       'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating
> >       entity; this element MAY optionally contain character data (in
> >       SASL terminology "additional data with success"). Upon receiving
> >       the <success/> element, the initiating entity MUST initiate a new
> >       stream by sending an opening XML stream header to the receiving
> >       entity (it is not necessary to send a closing </stream:stream>
> >       element first, since the receiving entity and initiating entity
> >       MUST consider the original stream to be closed upon sending or
> >       receiving the <success/> element). Upon receiving the new stream
> >       header from the initiating entity, the receiving entity MUST
> >       respond by sending a new XML stream header to the initiating
> >       entity, along with any remaining available features (but NOT
> >       including the STARTTLS feature or any authentication mechanisms)
> >       or an empty features element (to signify that no additional
> >       features are available); note that any such additional features
> >       are not defined herein, and MUST be defined by the relevant
> >       extension to XMPP.
> 
> Other protocols (IMAP/SMTP/POP) list available SASL mechanisms after a 
> successful SASL authentication.
> Some of them require that the client compares the list of the advertised 
> mechanism with the one before the authentication.
> This is done to prevent man-in-the-middle attacks when an attacker 
> removes strong SASL mechanisms from the list of supported mechanisms.
> (Whether this check is useful in practice is another matter. I am not 
> sure whether anybody implements it).

OK, I'll look at what those other protocols require, and how they word
the requirement. It seems good to have this check in place. 

> 4). There was a recent discussion on the bugtraq mailing list about 
> handling invalid base64 data. It turned out that different 
> implementations handle
> this differently, for example:
> 1). Ignore invalid characters
> 2). Treat an invalid character as the end of the base64 encoded data 
> (and ignore the rest)
> 3). Truncate base64 encoded data before the invalid character.
> 
> In particular there was a discussion regarding the padding character 
> ('=') in the middle of a base64 data.
> 
> I suggest that some text about this be added to the Security 
> considerations sections. For example:
> 
> Both the client and the server should verify the received base64 data 
> and reject (and not ignore) any characters not explicitly allowed by the 
> base64 alphabet
> [BASE64] and should reject any sequence of base64 characters that 
> contains the pad ('=') character not as the last
> character of the (e.g. "=AAA" or "BBBB=CCC").
> 
> [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 
> RFC 3548, July 2003.

Thanks for the suggested text.

> (You might decide to relax this for XMPP and to allow spaces and/or 
> CRLFs anywhere in the data.)

I see no strong reason to relax the requirement just for XMPP.

> 5).
> >6.3 SASL Errors
> >
> >   o  <bad-protocol/> -- The data provided by the initiating entity
> >      could not be processed, e.g. because does not adhere to the
> >      protocol for the requested mechanism; sent in response to the
> >      <response/> element.
> 
> Do you mean invalid base64 encoding here or something else?

It could be invalid base64 encoding, but we were thinking especially
that the decoded response is not consistent with the challenge format
required by the selected SASL mechanism.

> 6).
> 
> >6.3 SASL Errors
> >
> >   The following SASL-related error conditions are defined:
> >
> >   o  <aborted/> -- The receiving entity acknowledges an <abort/>
> >      element sent by the initiating entity; sent in response to the
> >      <abort/> element.
> >
> >   o  <bad-protocol/> -- The data provided by the initiating entity
> >      could not be processed, e.g. because does not adhere to the
> >      protocol for the requested mechanism; sent in response to the
> >      <response/> element.
> 
> or <auth/> with initial challenge data. Example: SASL PLAIN mechanism.
> 
> >   o  <encryption-required/> -- The mechanism chosen by the initiating
> >      entity may be used only if the stream is already encrypted; sent
> >      in response to the <auth/> element.
> >
> >   o  <invalid-authzid/> -- The authzid provided by the initiating
> >      entity is invalid, either because it is incorrectly formatted or
> >      because the initiating entity does not have permissions to
> >      authorize that ID; sent in response to a <response/> element.
> 
> or <auth/> with initial challenge data.
> 
> >   o  <invalid-mechanism/> -- The initiating entity did not provide a
> >      mechanism or requested a mechanism that is not supported by the
> >      receiving entity; sent in response to the <auth/> element.
> >
> >   o  <invalid-realm/> -- The realm provided by the initiating entity
> >      (in mechanisms that support the concept of a realm) does not match
> >      one of the hostnames served by the receiving entity; sent in
> >      response to a <response/> element.
> 
> or <auth/> with initial challenge data.
> 
> >   o  <mechanism-too-weak/> -- The mechanism requested by the initiating
> >      entity is weaker than server policy permits for that initiating
> >      entity; sent in response to the <response/> element.
> 
> or <auth/> with initial challenge data.
> 
> >   o  <not-authorized/> -- The authentication failed because the
> >      initiating entity did not provide valid credentials (this includes
> >      the case of an unknown username); sent in response to a 
> <response/> element.   
> 
> or <auth/> with initial challenge data.

I've fixed these in my working copy.

> 7).
> 
> >12.4 Order of Layers
> >
> >   The order of layers in which protocols MUST be stacked is as follows:
> >
> >   1.  TCP
> >
> >   2.  TLS
> >
> >   3.  SASL
> >
> >   4.  XMPP
> >
> >   The rationale for this order is that TCP is the base connection layer
> >   used by all of the protocols stacked on top of TCP, TLS is often
> >   provided at the operating system layer, SASL is often provided at the
> >   application layer, and XMPP is the application itself.
> 
> This should be referenced in "6.4 SASL Definition" section, because it 
> is related to the XMPP profile of SASL.

Fixed in my working copy.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.php

Date: Wed, 08 Oct 2003 17:24:56 +0100
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
CC: [email-masked], Peter Saint-Andre <[email-masked]>
Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt
Sender: [email-masked]

Jeffrey Hutzelman wrote:

>>>>>   When using SASL underneath a sufficiently strong Transport Security
>>>>>   service, a SASL security layer would most likely be redundant.  The
>>>>>   client and server would thus probably want to negotiate off the use
>>>>>   of a SASL security layer.
>>>>
>>> Please don't say this without a _lot_ more text explaining when it is
>>> safe. A common configuration is to run SASL under TLS, using SASL for
>>> client authentication and negotation of the authorization identity.
>>> In this configuration, it is _not_ safe to skip using a SASL security
>>> layer if the client did not check the server's certificate (there is a
>>> tunnelling MitM attack), and it's not a particularly good idea even if
>>> the server cert was checked, because the client's authentication is
>>> still not bound to the encryption keys used at the TLS layer.
>>>
>>> We already have problems with people who think it is actively bad to
>>> use a SASL security layer under TLS.  The result is that some insecure
>>> configurations are now widely deployed.  Let's not encourage this any
>>> further.
>>
>> Should I just drop this paragraph?
>
> Yeah, IMHO it would be reasonable to just drop the paragraph starting 
> "When using SASL underneath..." 

Done.

Alexey

Date: Wed, 8 Oct 2003 08:35:11 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: "Kurt D. Zeilenga" <[email-masked]>, Steven F Siirila <[email-masked]>, SASL mailing list <[email-masked]>
Subject: Re: draft-murchison-sasl-login-00  Last Call
Sender: [email-masked]

On Wed, 8 Oct 2003, Ken Murchison wrote:
> > Especially since c-client is the first, reference, and most widely
> > deployed implementation of the LOGIN mechanism; and was written by its
> > inventor.
> I'm not going to argue numbers, but I'm guessing that there are a
> significant number of deployed Outlook clients.  ;)

Even if Outlook may be more widespread, there are millions of deployed
Pine clients (we have the numbers).

c-client is more than just client code; it's also the engine behind UW
imapd and ipop3d.  UW imapd is the most widely deployed IMAP server.

> Your comment seems somewhat self serving,

Well, I could say the same for many comments from ...

Let's not go here.

> but I also find it distasteful
> to have to cater to M$.

> The problem is that LOGIN was never a standard,
> and M$ took it and did their (incorrect) own thing.

LOGIN was not documented because I followed the rules.  IESG said "no more
plaintext password authentication mechanisms."  IESG didn't offer any
wiggle room the way.  Politics allowed PLAIN to be snuck through but not
LOGIN (which preceeded PLAIN by 3 1/2 years).

If you're going to cater to Microsoft's bugs, then much of IMAP needs to
be thrown out because of broken behavior in their software.  Microsoft
should be made to fix their bugs instead.

I would like to see the security people redefine TLS so that that the
maximum payload is 5 bytes less than 16K (rather than 16K), since
Microsoft requires that.

> This is probably because c-client isn't used in any SMTP server code (at
> least AFAIK).  AFAIK, the challenge strings are only an issue with
> Outlook's SMTP AUTH code, so perhaps we can make the M$ strings a
> SHOULD/MUST for SMTP server code only.  I don't think this will make
> c-client noncompliant, will it?

I am working an an SMTP server.  I don't think that an SMTP-only kludge
to accomodate a bug is appropriate when there is another alternative (that
is, PLAIN).

The correct answer is that if Outlook has problems using LOGIN, then it
can always use PLAIN.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Wed, 08 Oct 2003 10:19:29 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt
Sender: [email-masked]

On Wednesday, October 08, 2003 13:38:33 +0100 Alexey Melnikov 
<[email-masked]> wrote:

>>>> 8.3.  Change control
>>>>
>>>>   Once a SASL mechanism registration has been published by IANA, the
>>>>   author may request a change to its definition.  The change request
>>>>   follows the same procedure as the registration request.
>>>
>> This sounds a lot like the stringprep loophole, and it makes me nervous.
>
> Can you be more specific in what do you want to be changed.

No.  Perhaps I'm being paranoid, but the concern is that if mechanism FOO 
gets registered and implemented, no one should be able to come along later 
and change FOO to mean some other, non-compatible mechanism.  Maybe it's 
not worth worrying about..

In any case, no, I can't be more specific; I don't know what change could 
make this better, and I don't think I was really asking for one.  It just 
makes me nervous.

> Would you rather reference the SASL WG as the Change Controller?

No, especially since the SASL WG will likely conclude within the 
foreseeable future.

>>>>   In certain situations, it is reasonable to use SASL underneath one of
>>>>   these Transport Security services.  The transport service would
>>>>   secure the connection, either service would authenticate the client,
>>>>   and SASL would negotiate the authorization identity.  The SASL
>>>>   negotiation would be what moves the protocol from "unauthenticated"
>>>>   to "authenticated" state.  The "EXTERNAL" SASL mechanism is
>>>>   explicitly intended to handle the case where the transport service
>>>>   secures the connection and authenticates the client and SASL
>>>>   negotiates the authorization identity.
>>>>
>>>>   When using SASL underneath a sufficiently strong Transport Security
>>>>   service, a SASL security layer would most likely be redundant.  The
>>>>   client and server would thus probably want to negotiate off the use
>>>>   of a SASL security layer.
>>>
>>
>> Please don't say this without a _lot_ more text explaining when it is
>> safe. A common configuration is to run SASL under TLS, using SASL for
>> client authentication and negotation of the authorization identity.
>> In this configuration, it is _not_ safe to skip using a SASL security
>> layer if the client did not check the server's certificate (there is a
>> tunnelling MitM attack), and it's not a particularly good idea even if
>> the server cert was checked, because the client's authentication is
>> still not bound to the encryption keys used at the TLS layer.
>>
>> We already have problems with people who think it is actively bad to
>> use a SASL security layer under TLS.  The result is that some insecure
>> configurations are now widely deployed.  Let's not encourage this any
>> further.
>
> Should I just drop this paragraph?

Yeah, IMHO it would be reasonable to just drop the paragraph starting "When 
using SASL underneath..."

>> Put the TOC at the _top_ of the document, just after the abstract.
>> See the "Tabel of Contents" section at
>> http://www.rfc-editor.org/policy.html
>
> This is editorial and I don't want to spend time doing this at this stage.
> I am going to sort this out with the RFC editor directly.

Fair enough.

Date: Wed, 08 Oct 2003 14:58:59 +0100
From: Alexey Melnikov <[email-masked]>
To: SASL WG <[email-masked]>
Subject: WG Last Call on draft-ietf-sasl-rfc2222bis-02
Sender: [email-masked]

I have an impression that there are two many little things to change so 
that we will need a new Last Call anyway.
Is my perception correct?

If it is, I will issue a new revision shortly.

Below is the list of open issues I still have to deal with (read this: I 
am planning to either update the document or send my comments):
1). IANA considerations and registering a familily of SASL mechanisms.
2). Clarification on replacing a security layer
3). Realm
4). Other minor editorial issues.

Alexey

Date: Wed, 08 Oct 2003 14:58:08 +0100
From: Alexey Melnikov <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt
Sender: [email-masked]

Kurt D. Zeilenga wrote:

>>7.    The EXTERNAL mechanism
>>
>>  The mechanism name associated with external authentication is
>>  "EXTERNAL".
>>
>>  The client sends an initial response with the UTF-8 encoding of the
>>  authorization identity. The form of the authorization identity is
>>  further restricted by the application-level protocol's SASL profile.
>>
>>  The server uses information, external to SASL, to determine whether
>>  the client is authorized to authenticate as the authorization
>>  identity.
>>    
>>
>
>It may be appropriate to note that the client can make no
>assumptions as what information the server uses in determining
>client authorization.  E.g., just because TLS was established,
>doesn't mean the server will use TLS-provided information.
>  
>
Done. The new text reads:

The system providing this external information may be, for example,
IPSec or TLS. However, the client can make no assumptions as to what
information the server can use in determining client authorization.
E.g., just because TLS was established, doesn't mean that the server
will use the information provided by TLS.

>>7.2.  Example
>>
>>  The following is an example of an EXTERNAL authentication in the SMTP
>>  protocol [SMTP-AUTH].
>>    
>>
>
>Replace [SMTP-AUTH] with an informative reference to the SMTP base
>specification.  Insert [SMTP-AUTH] after the word "profile" below.
>
Done.

Alexey

Date: Wed, 08 Oct 2003 09:46:51 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Mark Crispin <[email-masked]>
CC: "Kurt D. Zeilenga" <[email-masked]>, Steven F Siirila <[email-masked]>, SASL mailing list <[email-masked]>
Subject: Re: draft-murchison-sasl-login-00  Last Call
Sender: [email-masked]

Mark Crispin wrote:
> On Tue, 7 Oct 2003, Ken Murchison wrote:
> 
>>FWIW, I wanted to make the challenge strings used by M$ products a
>>SHOULD and those originally intended by c-client a MAY.  Mark is against
>>making c-client [semi-]uncompliant, which I can also agree with.
> 
> 
> Especially since c-client is the first, reference, and most widely
> deployed implementation of the LOGIN mechanism; and was written by its
> inventor.

I'm not going to argue numbers, but I'm guessing that there are a 
significant number of deployed Outlook clients.  ;)

> I think that c-client's needs are more important that the evil empire's,
> and that it would be reprehensible to change specifications to match a
> broken implementation in evil empireware.

Your comment seems somewhat self serving, but I also find it distasteful 
to have to cater to M$.  The problem is that LOGIN was never a standard, 
and M$ took it and did their (incorrect) own thing.  Since the cat is 
already out of the bag, and I don't think we can get M$ to change their 
code, we have to deal with it.

> I have never encountered the reported problems with evil empireware.

This is probably because c-client isn't used in any SMTP server code (at 
least AFAIK).  AFAIK, the challenge strings are only an issue with 
Outlook's SMTP AUTH code, so perhaps we can make the M$ strings a 
SHOULD/MUST for SMTP server code only.  I don't think this will make 
c-client noncompliant, will it?

We probably need more input from others on the list, since Mark and I 
are just rehashing discussions that we've already had.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Wed, 08 Oct 2003 14:33:04 +0100
From: Alexey Melnikov <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
CC: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: CHARSET-POLICY Re: WG Last Call:  draft-ietf-sasl-rfc2222bis-02.txt
Sender: [email-masked]

Kurt D. Zeilenga wrote:

>My main gripe here is that the I-D implied incorrectly that
>the IETF character set policy RECOMMENDs protocols be able
>to use UTF-8 when the police that protocols are REQUIRED
>to be able to use UTF-8.
>
>I think both these "Per IETF character set policy" statements
>should be deleted.  Inserting a note like shown below might
>be appropriate.
>  
>
>>  The character encoding scheme used 
>>    
>>
>(see [CHARSET-POLICY]for IETF policy regarding character sets in IETF protocols)
>
>  
>
>>  for transmitting an authorization identity over protocol is
>>   specified in each authentication mechanism (with the
>>  authentication mechanism's blob being further
>>  restricted/encoded by the protocol profile).
>>
I've changed the first reference as you suggested, and the last to:

Authentication mechanisms SHOULD encode character strings in UTF-8 [UTF-8]
(see [CHARSET-POLICY] for IETF policy regarding character sets in IETF 
protocols).

>  
>
>>>> Per IETF character set
>>>> policy [CHARSET-POLICY], authentication mechanisms SHOULD encode
>>>> these and other strings in UTF-8 [UTF-8].
>>>>        
>>>>
>>>This seems counter to [CHARSET-POLICY] as it allows a mechanism to
>>>not support UTF-8 transfer of character data.
>>>[CHARSET-POLICY] says:
>>>  Protocols MUST be able to use the UTF-8 charset, which consists of
>>>  the ISO 10646 coded character set combined with the UTF-8 character
>>>  encoding scheme, as defined in [10646] Annex R (published in
>>>  Amendment 2), for all text.
>>>      
>>>
>>It would probably be appropriate to require applications to deal, though the truth is that CHARSET-POLICY already does that without our help.
>>While we can impose requirements on SASL mechanisms, we really can't impose requirements on the authentication technologies upon which they are built.
>>Requiring mechanisms to use UTF-8 might impose an impossible burden on the SASL mechansim designer, forcing them to do transformations between Unicode and some other character set.
>>
>>So, it is appropriate to REQUIRE that authorization identities (which are not really owned by the mechanism anyway) be encoded as UTF-8, and I think we should do so.  But it may not be appropriate for "other strings".
>>    
>>

Date: Wed, 08 Oct 2003 13:38:33 +0100
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt
Sender: [email-masked]

Jeffrey Hutzelman wrote:

>>> 5.    Protocol profile requirements
>>>
>>>   In order to use this specification, a protocol definition MUST supply
>>>   the following information:
>>>
>>>   A service name, to be selected from the IANA registry of "service"
>>>   elements for the GSSAPI host-based service name form. [GSSAPI]  This
>>>   service name is made available to the authentication mechanism.
>>>
>>>   The registry is available at the URL
>>>   "http://www.iana.org/assignments/gssapi-service-names" A definition
>>
> Paragraph break. 

Yes, this is already fixed in my copy.

>>>   A definition of the method by which the authentication protocol
>>>   exchange is carried out, including how the challenges and responses
>>>   are encoded, how the server indicates completion or failure of the
>>>   exchange, how the client aborts an exchange, and how the exchange
>>>   method interacts with any line length limits in the protocol.
>>>
>>>   The command SHOULD have a method for the server to include an
>>>   optional challenge with a success notification.  This allows the
>>>   server to avoid a round trip when using a mechanism which is defined
>>>   to have the server send additional data along with the indication of
>>>   successful completion.  See section 6.2 of this document for further
>>>   information.
>>
> What command?  Who says "the method by which the authentication 
> protocol exchange is carried out" is a command?  s/The command/The 
> exchange method/ 

Yes.

>>> 8.3.  Change control
>>>
>>>   Once a SASL mechanism registration has been published by IANA, the
>>>   author may request a change to its definition.  The change request
>>>   follows the same procedure as the registration request.
>>
> This sounds a lot like the stringprep loophole, and it makes me nervous. 

Can you be more specific in what do you want to be changed.
Would you rather reference the SASL WG as the Change Controller?

>>>   In certain situations, it is reasonable to use SASL underneath one of
>>>   these Transport Security services.  The transport service would
>>>   secure the connection, either service would authenticate the client,
>>>   and SASL would negotiate the authorization identity.  The SASL
>>>   negotiation would be what moves the protocol from "unauthenticated"
>>>   to "authenticated" state.  The "EXTERNAL" SASL mechanism is
>>>   explicitly intended to handle the case where the transport service
>>>   secures the connection and authenticates the client and SASL
>>>   negotiates the authorization identity.
>>>
>>>   When using SASL underneath a sufficiently strong Transport Security
>>>   service, a SASL security layer would most likely be redundant.  The
>>>   client and server would thus probably want to negotiate off the use
>>>   of a SASL security layer.
>>
>
> Please don't say this without a _lot_ more text explaining when it is 
> safe. A common configuration is to run SASL under TLS, using SASL for 
> client authentication and negotation of the authorization identity.  
> In this configuration, it is _not_ safe to skip using a SASL security 
> layer if the client did not check the server's certificate (there is a 
> tunnelling MitM attack), and it's not a particularly good idea even if 
> the server cert was checked, because the client's authentication is 
> still not bound to the encryption keys used at the TLS layer.
>
> We already have problems with people who think it is actively bad to 
> use a SASL security layer under TLS.  The result is that some insecure 
> configurations are now widely deployed.  Let's not encourage this any 
> further. 

Should I just drop this paragraph?

>>>   The IANA is directed to modify the SASL mechanisms registry as
>>>   follows:
>>
>>
>> Please reword this to be not so demanding.  For example,
>>     It is requested that IANA update the SASL mechanisms registry
>>     as follows:
>
>
> It's not demanting; it's perfectly reasonable usage.  The IANA works 
> for the IETF; it is appropriate for the IETF, in the form of a 
> standards-track document, to direct it to make changes to a registry.  
> It is also common usage. 

I've already changed this to be "nicer" to IANA ;-).

> Put the TOC at the _top_ of the document, just after the abstract.  
> See the "Tabel of Contents" section at 
> http://www.rfc-editor.org/policy.html 

This is editorial and I don't want to spend time doing this at this stage.
I am going to sort this out with the RFC editor directly.

Alexey

Date: Wed, 08 Oct 2003 13:06:19 +0100
From: Alexey Melnikov <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
CC: [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Proxy authentication (was WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt)
Sender: [email-masked]

[Because there are too many issues raised I will be starting a separate 
thread for each]

Kurt D. Zeilenga wrote:

>>  During the authentication protocol exchange, the mechanism performs
>>  authentication, transmits an authorization identity (frequently known
>>  as a userid) from the client to server, and negotiates the use of a
>>  mechanism-specific security layer.  If the use of a security layer is
>>  agreed upon, then the mechanism must also define or negotiate the
>>  maximum security layer buffer size that each side is able to receive.
>>
>>4.2.  Authorization identities and proxy authentication    
>>
>
>
>See note below regarding the term "proxy authentication".
>
>  
>
...

>>  The identity derived from the client's authentication credentials is
>>  known as the "authentication identity".  With any mechanism,
>>  transmitting an authorization identity of the empty string directs
>>  the server to derive an authorization identity from the client's
>>  authentication identity.
>>
>>  If the authorization identity transmitted during the authentication
>>  protocol exchange is not the empty string, this is typically referred
>>  to as "proxy authentication".
>>    
>>
>
>Personally, I refer to this as "proxy authorization".  Proxy
>authentication makes it sound like the feature can be used by a
>proxy to authenticate its users.
>
>  
>
Jeffrey Hutzelman wrote:

>>>   If the authorization identity transmitted during the authentication
>>>   protocol exchange is not the empty string, this is typically referred
>>>   to as "proxy authentication".
>>
>> Personally, I refer to this as "proxy authorization".  Proxy
>> authentication makes it sound like the feature can be used by a
>> proxy to authenticate its users.
>
> The same argument can be made for "proxy authorization".  We are 
> talking about "authentication by proxy", not "authentication to a 
> proxy".  And yes, we're really talking about authorization, not 
> authentication, but it's not really "authorization by proxy"; it's 
> just authorization.
>
> The terminology is pretty bad.  It's not clear to me that we need a 
> name for this at all.  But I'm pretty sure the phrase "proxy 
> authentication" has been in use for a while, and to change it might 
> cause more confusion than leaving it alone.

So, I will leave it as is.

Alexey

Date: Wed, 08 Oct 2003 12:52:13 +0100
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments
Sender: [email-masked]

Hallvard B Furuseth wrote:

>Sorry about coming with these comments so late.  I have just discovered
>the SASL list, and there was a lot to read:-)
>Feel free to ignore comments that have already been discussed.  
>
>>4.    Authentication mechanisms
>>
>>   SASL mechanisms are named by
>>    
>>
>
>ASCII
>
>  
>
>>   strings,
>>   (...)
>>   mech-char    = %x41-5A / DIGIT / "-" / "_"
>>                  ; mech names restricted to uppercase
>>    
>>
>
>ASCII
>
Ok.

>>letters,
>>                  ; digits, "-" and "_"    
>>
>>   SASL mechanism names must be registered with the IANA.
>>   IETF Standards Track documents may override this registration
>>   requirement by reserving a portion of the SASL mechanism namespace
>>   for their own use;
>>    
>>
>
>Huh?  So I must search through all Standards Track RFCs as well as the
>IANA registry in order to find out if a mechanism name is reserved?
>Why not register these name reservations with IANA too?
>
IMHO, this was the intent. I will try to clarify this.

>>4.1.  Authentication protocol exchange
>>
>>   A SASL mechanism is responsible for conducting an authentication
>>   protocol exchange.  This consists of a series of server challenges
>>   and client responses,    
>>
>
>Does this mean that the initial auth command from the client is not
>considered part of the authentication protocol exchange?
>
Does it matter in this section?

>>4.2.  Authorization identities and proxy authentication
>>
>>   (...)
>>   The character encoding scheme used for transmitting an authorization
>>   identity over protocol is specified in each authentication mechanism
>>   (with the authentication mechanism's blob being further
>>    
>>
>                                          ^^^^
>
>What's a blob?  I don't think it's 'something ill-defined or amorphous',
>like the dictionary says:-)
>
I've changed this to "data".

>>4.3.  Security layers
>>
>>   If use of a security layer is negotiated by the authentication
>>   protocol exchange, the security layer is applied to all subsequent
>>   data sent over the connection    
>>
>
>... until another security layer or no security layer is negotiated.
>
>[Added according to section 6.3.]
>
>  
>
Done.

>>   In
>>   order to avoid noninteroperability due to differing normalizations,
>>   when a mechanism specifies that a string authentication identity or
>>   password used as input to a cryptographic function (or used for
>>   comparison) it SHOULD specify that the string first be prepared using
>>   the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm
>>   [StringPrep].  This should be done by both the client (upon getting
>>   user input or retrieving a value from configuration) and by the
>>   server (upon receiving the value from the client).
>>    
>>
>
>What's the point of this duplicate preparation?  Why not do it only
>at the server side?
>  
>
Because if the client doesn't do that, the hash calculated on the server 
will not match the one calculated on the client.

>>   A service name, to be selected from the IANA registry of "service"
>>   elements for the GSSAPI host-based service name form. [GSSAPI]    
>>
>
>Nitpick: I think the period should be after [GSSAPI].
>
Fixed.

>>   This
>>   service name is made available to the authentication mechanism.
>>    
>>
>
>There should be no paragraph break here.
>
Fixed.

>>   The registry is available at the URL
>>   "http://www.iana.org/assignments/gssapi-service-names"
>>    
>>
>
>Instead, a paragraph break here.  (And a trailing '.'.)
>  
>
Fixed.

>>   A definition
>>   of the command to initiate the authentication protocol exchange.
>>    
>>
>>   The command SHOULD have a method for the server to include an
>>   optional challenge with a success notification.
>>    
>>
>
>I suggest you rename "an optional challenge" to "optional data", or
>put "challenge" in quotes.
>  
>
Ok.

>>   A protocol profile MAY further refine the definition of an
>>   authorization identity by adding additional syntactic restrictions
>>   and protocol-specific semantics.
>>    
>>
>
>Add a paragraph break here, since the following is a new item.  Remove
>"A protocol profile MUST specify" to just make the following a new item
>in the list of things that must be specified.
>
>  
>
>>   A protocol profile MUST specify the
>>   form of the authorization identity (as it is protocol specific, as
>>   
>>
I would rather not do this, as this is a single logic item.

>
>  
>
>>6.3.  Multiple authentications
>>
>>   Unless otherwise stated by the protocol's profile, only one
>>   successful SASL negotiation may occur in a protocol session.
>>    
>>
>
>This should be mentioned in the "Protocol profile requirements" section.
>
I agree.

>>7.1.  Formal syntax
>>
>>   initial-response  = *( UTF8-char-no-null )
>>    
>>
>
>Why is initial-response required to be UTF-8 when the character encoding
>scheme of the rest of the exchange is left to the specifications of the
>individual mechanisms?  I would think that either initial-response
>merely "SHOULD" be UTF-8, like the rest of the exchange.
>
This is specific to EXTERNAL.
I've changed "initial-response" to "extern-init-resp" in order to avoid 
confusion.

> 
>
>
>And, as I mentioned, there should be an 'Obsoletes: rfc 2222' at the
>top.
> 
>
I've added a sentence about this in the introduction section.

Alexey

Date: Wed, 08 Oct 2003 11:54:31 -0700
To: Jeffrey Hutzelman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: CHARSET-POLICY Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt
Cc: [email-masked]
Sender: [email-masked]

My main gripe here is that the I-D implied incorrectly that
the IETF character set policy RECOMMENDs protocols be able
to use UTF-8 when the police that protocols are REQUIRED
to be able to use UTF-8.

I think both these "Per IETF character set policy" statements
should be deleted.  Inserting a note like shown below might
be appropriate.

>   The character encoding scheme used (see [CHARSET-POLICY]
for IETF policy regarding character sets in IETF protocols)
for
>   transmitting an authorization identity over protocol is
>    specified in each authentication mechanism (with the
>   authentication mechanism's blob being further
>   restricted/encoded by the protocol profile).  

At 08:43 AM 10/1/2003, Jeffrey Hutzelman wrote:
>>>  Per IETF character set
>>>  policy [CHARSET-POLICY], authentication mechanisms SHOULD encode
>>>  these and other strings in UTF-8 [UTF-8].
>>
>>This seems counter to [CHARSET-POLICY] as it allows a mechanism to
>>not support UTF-8 transfer of character data.
>>[CHARSET-POLICY] says:
>>   Protocols MUST be able to use the UTF-8 charset, which consists of
>>   the ISO 10646 coded character set combined with the UTF-8 character
>>   encoding scheme, as defined in [10646] Annex R (published in
>>   Amendment 2), for all text.
>
>It would probably be appropriate to require applications to deal, though the truth is that CHARSET-POLICY already does that without our help.
>While we can impose requirements on SASL mechanisms, we really can't impose requirements on the authentication technologies upon which they are built.
> Requiring mechanisms to use UTF-8 might impose an impossible burden on the SASL mechansim designer, forcing them to do transformations between Unicode and some other character set.
>
>So, it is appropriate to REQUIRE that authorization identities (which are not really owned by the mechanism anyway) be encoded as UTF-8, and I think we should do so.  But it may not be appropriate for "other strings".

Date: Wed, 08 Oct 2003 10:28:30 -0700
To: Hallvard B Furuseth <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: empty authzid in draft-ietf-sasl-plain-02.txt
Cc: [email-masked]
Sender: [email-masked]

At 06:49 AM 10/1/2003, Hallvard B Furuseth wrote:

>draft-ietf-sasl-plain-02.txt says that
>
>  The client leaves
>  the authorization identity empty if it wishes the server to derive the
>  authorization identity from the provided authentication identity.
>
>and
>
>  Note that the parameters provided to the Authorize function are not
>  prepared.
>
>so I think the pseudo-code for empty authzid should say
>          authzid = DeriveAuthzid(authcid);
>and not
>          authzid = DeriveAuthzid(pAuthcid);

I think the current psuedo-code is correct, the first
quoted text is misleading.  The word "provided" should
be deleted as it implies the provided representation
(as opposed to prepared representation of the provided
authentication identity).  Also, I recommend the following
text be added immediately above the paragraph which
ends with "that string MUST be prepared before generation
of the hash."

 When the no authorization identity is provided, the server
 SHALL derive the authorization identity from the prepared
 representation of the provided authentication identity
 string.  This ensures that the derivation of different
 representations of the authentication identity produce
 the same authorization identity.

Kurt 

Date: Wed, 08 Oct 2003 09:37:00 -0700
To: Hallvard B Furuseth <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments
Cc: [email-masked]
Sender: [email-masked]

Hallvard,

This wording concerns me a bit too.  I think we need to have
one registry which lists all "public" mechanisms.  Hence, I
suggest the text be reworded to allow a standard track RFC
to establish additional registration requirements for
portions of the name space (or "families of names").  That
is, the SASL-GSSAPI specification can establish additional
requirements for GSSAPI mechanisms.  However, SASL-GSSAPI
cannot (without updating the base specification) remove
requirements established by the base specification.

Also, I think having the text belongs only in the IANA
Considerations section.  Section 4 should just say
  SASL mechanism names must be registered with the IANA
  in accordance with Section 8 of this document.

Section 8 should include both the guidelines for IANA
to follow (for individual names and for families of names)
and procedures for those requesting registration.  (I
suggest having two subsections "Guidelines for IANA"
and "Registration Procedures".

Kurt

At 01:48 PM 9/30/2003, Hallvard B Furuseth wrote:
>>    SASL mechanism names must be registered with the IANA.
>>    IETF Standards Track documents may override this registration
>>    requirement by reserving a portion of the SASL mechanism namespace
>>    for their own use;
>
>Huh?  So I must search through all Standards Track RFCs as well as the
>IANA registry in order to find out if a mechanism name is reserved?
>Why not register these name reservations with IANA too?
>
>> 4.1.  Authentication protocol exchange
>>
>>    A SASL mechanism is responsible for conducting an authentication
>>    protocol exchange.  This consists of a series of server challenges
>>    and client responses,
>
>Does this mean that the initial auth command from the client is not
>considered part of the authentication protocol exchange? 

Date: Tue, 7 Oct 2003 18:24:30 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: "Kurt D. Zeilenga" <[email-masked]>, Steven F Siirila <[email-masked]>, SASL mailing list <[email-masked]>
Subject: Re: draft-murchison-sasl-login-00  Last Call
Sender: [email-masked]

On Tue, 7 Oct 2003, Ken Murchison wrote:
> FWIW, I wanted to make the challenge strings used by M$ products a
> SHOULD and those originally intended by c-client a MAY.  Mark is against
> making c-client [semi-]uncompliant, which I can also agree with.

Especially since c-client is the first, reference, and most widely
deployed implementation of the LOGIN mechanism; and was written by its
inventor.

I think that c-client's needs are more important that the evil empire's,
and that it would be reprehensible to change specifications to match a
broken implementation in evil empireware.

I have never encountered the reported problems with evil empireware.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Tue, 7 Oct 2003 16:47:15 -0700 (PDT)
From: SY Yip <[email-masked]>
Subject: linkage to data security
To: [email-masked]
Sender: [email-masked]

Hi All

I'm new to this list.  Just wonder if ietf-sasl
addresses the linkage of authentication to data
security.  Meaning, a user logs on to a system, the
system is able to use the user identity to determine
data access security from LDAP or RDBMS.  Today most
applications can authenticate users but they use
system id to connect to LDAP or RDBMS.  As a result,
they can't link the login ID to Data Access.

Much appreciated for any help.

Regards
sy yip
Gama Technology

Date: Tue, 07 Oct 2003 19:12:32 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: "Kurt D. Zeilenga" <[email-masked]>
CC: Steven F Siirila <[email-masked]>, SASL mailing list <[email-masked]>, Mark Crispin <[email-masked]>
Subject: Re: draft-murchison-sasl-login-00  Last Call
Sender: [email-masked]

Kurt D. Zeilenga wrote:
> Ken,
> 
> This use of MAY is a bit problematic.  MAY items are suppose to be
> truly optional (see RFC 2119).  As servers using the
> alternative protocol tokens won't interoperate with client not
> expecting those alternatives, this item isn't.
> 
> Likely this can be addressed by (more explicitly) limiting the
> applicability of the option.

I'll let Mark argue for the continued use of MAY.

FWIW, I wanted to make the challenge strings used by M$ products a 
SHOULD and those originally intended by c-client a MAY.  Mark is against 
making c-client [semi-]uncompliant, which I can also agree with.

Cyrus SASL uses the M$ challenges and we are not aware of any products 
which fail to work with these strings, since clients other than M$ 
correctly ignore the contents of the challenges.

Mark, Rob and myself struggled with this issue a lot.

>>Steven F Siirila wrote:
>>
>>
>>>In reading section 2.2:
>>>2.2.  Server side of authentication protocol exchange
>>>   The server issues the string "User Name" in challenge, and receives a
>>>   client response.  This response is recorded as the authorization
>>>   identity.  The server then issues the string "Password" in challenge,
>>>   and receives a client response.  This response is recorded as the
>>>   authorization authenticator.  The server must verify that the
>>>   authorization authenticator permits login as the authorization
>>>   identity.
>>>   Note: There is at least one widely deployed client which requires
>>>   that the challenge strings transmitted by the server be "Username:"
>>>   and "Password:" respectively.  For this reason, server
>>>   implementations MAY send these challenge strings instead of those
>>>   listed above.
>>>Why is the string "User name" chosen as the suggested challenge to be sent
>>>by the server instead of "Username:", considering that second paragraph?
>>>Are there other clients out there that expect "User name" as a challenge
>>>string?  Note that the current Cyrus SASL (V2) returns "Username:" and
>>>"Password:".
>>
>>The former describes the original intended specification, the latter describes an existing deployed implementation which requires these challenge strings (think large monopoly in Redmond, WA).
>>
>>The wording in the draft is a compromise between the authors.
>>
>>-- 
>>Kenneth Murchison     Oceana Matrix Ltd.
>>Software Engineer     21 Princeton Place
>>716-662-8973 x26      Orchard Park, NY 14127
>>--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp
> 
> 
> 

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Wed, 08 Oct 2003 03:04:05 -0700
To: Ken Murchison <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: draft-murchison-sasl-login-00  Last Call
Cc: Steven F Siirila <[email-masked]>, SASL mailing list <[email-masked]>, Mark Crispin <[email-masked]>
Sender: [email-masked]

Ken,

This use of MAY is a bit problematic.  MAY items are suppose to be
truly optional (see RFC 2119).  As servers using the
alternative protocol tokens won't interoperate with client not
expecting those alternatives, this item isn't.

Likely this can be addressed by (more explicitly) limiting the
applicability of the option.

Kurt

At 11:38 AM 10/7/2003, Ken Murchison wrote:

>Steven F Siirila wrote:
>
>>In reading section 2.2:
>>2.2.  Server side of authentication protocol exchange
>>    The server issues the string "User Name" in challenge, and receives a
>>    client response.  This response is recorded as the authorization
>>    identity.  The server then issues the string "Password" in challenge,
>>    and receives a client response.  This response is recorded as the
>>    authorization authenticator.  The server must verify that the
>>    authorization authenticator permits login as the authorization
>>    identity.
>>    Note: There is at least one widely deployed client which requires
>>    that the challenge strings transmitted by the server be "Username:"
>>    and "Password:" respectively.  For this reason, server
>>    implementations MAY send these challenge strings instead of those
>>    listed above.
>>Why is the string "User name" chosen as the suggested challenge to be sent
>>by the server instead of "Username:", considering that second paragraph?
>>Are there other clients out there that expect "User name" as a challenge
>>string?  Note that the current Cyrus SASL (V2) returns "Username:" and
>>"Password:".
>
>The former describes the original intended specification, the latter describes an existing deployed implementation which requires these challenge strings (think large monopoly in Redmond, WA).
>
>The wording in the draft is a compromise between the authors.
>
>-- 
>Kenneth Murchison     Oceana Matrix Ltd.
>Software Engineer     21 Princeton Place
>716-662-8973 x26      Orchard Park, NY 14127
>--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Tue, 07 Oct 2003 22:49:33 +0100
From: Alexey Melnikov <[email-masked]>
To: Peter Saint-Andre <[email-masked]>, Jeremie Miller <[email-masked]>
CC: [email-masked], [email-masked], SASL WG <[email-masked]>
Subject: Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard)
Sender: [email-masked]

The IESG wrote:

>The IESG has received a request from the Extensible Messaging and Presence 
>Protocol WG to consider the following document:
>
>- 'XMPP Core '
>   <draft-ietf-xmpp-core-18.txt> as a Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send any comments to the
>[email-masked] or [email-masked] mailing lists by 2003-10-09.
>                                                                                       
>The file can be obtained via
>http://www.ietf.org/internet-drafts/draft-ietf-xmpp-core-18.txt
>
I would like to raise several SASL related issues in XMPP document.
(Sorry for crosspost and sorry for being late with reviewing this.)

1).
 >   7.  The initiating entity MUST provide an authzid during SASL
 >       negotiation. The authzid-value MUST be a valid JID of the form
 >       <domain> (i.e., a domain identifier only) for servers and of the
 >       form <user@domain/resource> (i.e., node identifier, domain
 >       identifier, and resource identifier) for clients. The initiating
 >       entity MAY process the authzid-value in accordance with the rules
 >       defined in Addressing Scheme (Section 3) before providing it to
 >       the receiving entity, but is NOT REQUIRED to do so; however, the
 >       receiving entity MUST verify that the authzid-value provided by
 >       the initiating entity conforms to the rules defined therein.

Not all SASL mechanisms are capable of transmitting authorization 
identity, so this requirement might be problematic.

Also, the revision of RFC 2222 says that the client must not specify 
authorization-id unless it wants to impersonate some other entity:

   As a client might not have the same information as the server,
   clients SHOULD NOT themselves try to derive authorization identities
   from authentication identities when clients could instead transmit an
   authorization identity of the empty string.

So, the text should be reworded reflect that an authorization identity 
is optional and that if one is provided, it is in the form described above.

2).

 >   This series of challenge/response pairs continues until one of three
 >   things happens:
 >
 >   1.  The initiating entity aborts the handshake by sending an <abort/>
 >       element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl'
 >       namespace to the receiving entity. Upon receiving the <abort/>
 >       element, the receiving entity MUST terminate the TCP connection.

I think the requirement to drop TCP connection is unreasonable here.
There are several valid reasons why the client may retry failed 
authentication:
1). User typed in a wrong password, the client should retry the same 
SASL mechanism a reasonable number of times.
2). The client invoked a SASL mechanism that reported that it can't be 
used because of misconfiguration (e.g. kerberos configuration file is 
missing). The client than sends <abort/> to the server and tries another 
mechanism.

3).

 >   3.  The receiving entity reports success of the handshake by sending
 >       a <success/> element qualified by the
 >       'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating
 >       entity; this element MAY optionally contain character data (in
 >       SASL terminology "additional data with success"). Upon receiving
 >       the <success/> element, the initiating entity MUST initiate a new
 >       stream by sending an opening XML stream header to the receiving
 >       entity (it is not necessary to send a closing </stream:stream>
 >       element first, since the receiving entity and initiating entity
 >       MUST consider the original stream to be closed upon sending or
 >       receiving the <success/> element). Upon receiving the new stream
 >       header from the initiating entity, the receiving entity MUST
 >       respond by sending a new XML stream header to the initiating
 >       entity, along with any remaining available features (but NOT
 >       including the STARTTLS feature or any authentication mechanisms)
 >       or an empty features element (to signify that no additional
 >       features are available); note that any such additional features
 >       are not defined herein, and MUST be defined by the relevant
 >       extension to XMPP.

Other protocols (IMAP/SMTP/POP) list available SASL mechanisms after a 
successful SASL authentication.
Some of them require that the client compares the list of the advertised 
mechanism with the one before the authentication.
This is done to prevent man-in-the-middle attacks when an attacker 
removes strong SASL mechanisms from the list of supported mechanisms.
(Whether this check is useful in practice is another matter. I am not 
sure whether anybody implements it).

4). There was a recent discussion on the bugtraq mailing list about 
handling invalid base64 data. It turned out that different 
implementations handle
this differently, for example:
1). Ignore invalid characters
2). Treat an invalid character as the end of the base64 encoded data 
(and ignore the rest)
3). Truncate base64 encoded data before the invalid character.

In particular there was a discussion regarding the padding character 
('=') in the middle of a base64 data.

I suggest that some text about this be added to the Security 
considerations sections. For example:

Both the client and the server should verify the received base64 data 
and reject (and not ignore) any characters not explicitly allowed by the 
base64 alphabet
[BASE64] and should reject any sequence of base64 characters that 
contains the pad ('=') character not as the last
character of the (e.g. "=AAA" or "BBBB=CCC").

[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 
RFC 3548, July 2003.

(You might decide to relax this for XMPP and to allow spaces and/or 
CRLFs anywhere in the data.)

5).
 >6.3 SASL Errors
 >
 >   o  <bad-protocol/> -- The data provided by the initiating entity
 >      could not be processed, e.g. because does not adhere to the
 >      protocol for the requested mechanism; sent in response to the
 >      <response/> element.

Do you mean invalid base64 encoding here or something else?

6).

 >6.3 SASL Errors
 >
 >   The following SASL-related error conditions are defined:
 >
 >   o  <aborted/> -- The receiving entity acknowledges an <abort/>
 >      element sent by the initiating entity; sent in response to the
 >      <abort/> element.
 >
 >   o  <bad-protocol/> -- The data provided by the initiating entity
 >      could not be processed, e.g. because does not adhere to the
 >      protocol for the requested mechanism; sent in response to the
 >      <response/> element.

or <auth/> with initial challenge data. Example: SASL PLAIN mechanism.

 >   o  <encryption-required/> -- The mechanism chosen by the initiating
 >      entity may be used only if the stream is already encrypted; sent
 >      in response to the <auth/> element.
 >
 >   o  <invalid-authzid/> -- The authzid provided by the initiating
 >      entity is invalid, either because it is incorrectly formatted or
 >      because the initiating entity does not have permissions to
 >      authorize that ID; sent in response to a <response/> element.

or <auth/> with initial challenge data.

 >   o  <invalid-mechanism/> -- The initiating entity did not provide a
 >      mechanism or requested a mechanism that is not supported by the
 >      receiving entity; sent in response to the <auth/> element.
 >
 >   o  <invalid-realm/> -- The realm provided by the initiating entity
 >      (in mechanisms that support the concept of a realm) does not match
 >      one of the hostnames served by the receiving entity; sent in
 >      response to a <response/> element.

or <auth/> with initial challenge data.

 >   o  <mechanism-too-weak/> -- The mechanism requested by the initiating
 >      entity is weaker than server policy permits for that initiating
 >      entity; sent in response to the <response/> element.

or <auth/> with initial challenge data.

 >   o  <not-authorized/> -- The authentication failed because the
 >      initiating entity did not provide valid credentials (this includes
 >      the case of an unknown username); sent in response to a 
<response/> element.   

or <auth/> with initial challenge data.

7).

 >12.4 Order of Layers
 >
 >   The order of layers in which protocols MUST be stacked is as follows:
 >
 >   1.  TCP
 >
 >   2.  TLS
 >
 >   3.  SASL
 >
 >   4.  XMPP
 >
 >   The rationale for this order is that TCP is the base connection layer
 >   used by all of the protocols stacked on top of TCP, TLS is often
 >   provided at the operating system layer, SASL is often provided at the
 >   application layer, and XMPP is the application itself.

This should be referenced in "6.4 SASL Definition" section, because it 
is related to the XMPP profile of SASL.

Cheers,
Alexey

Date: Tue, 07 Oct 2003 14:38:55 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Steven F Siirila <[email-masked]>
CC: SASL mailing list <[email-masked]>, Mark Crispin <[email-masked]>
Subject: Re: draft-murchison-sasl-login-00  Last Call
Sender: [email-masked]

Steven F Siirila wrote:

> In reading section 2.2:
> 
> 2.2.  Server side of authentication protocol exchange
> 
>     The server issues the string "User Name" in challenge, and receives a
>     client response.  This response is recorded as the authorization
>     identity.  The server then issues the string "Password" in challenge,
>     and receives a client response.  This response is recorded as the
>     authorization authenticator.  The server must verify that the
>     authorization authenticator permits login as the authorization
>     identity.
> 
>     Note: There is at least one widely deployed client which requires
>     that the challenge strings transmitted by the server be "Username:"
>     and "Password:" respectively.  For this reason, server
>     implementations MAY send these challenge strings instead of those
>     listed above.
> 
> Why is the string "User name" chosen as the suggested challenge to be sent
> by the server instead of "Username:", considering that second paragraph?
> Are there other clients out there that expect "User name" as a challenge
> string?  Note that the current Cyrus SASL (V2) returns "Username:" and
> "Password:".

The former describes the original intended specification, the latter 
describes an existing deployed implementation which requires these 
challenge strings (think large monopoly in Redmond, WA).

The wording in the draft is a compromise between the authors.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Tue, 07 Oct 2003 14:32:24 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: SASL mailing list <[email-masked]>
Subject: draft-murchison-sasl-login-00  Last Call
Sender: [email-masked]

Since we did not receive any negative feedback (or positive, for that
matter) and Mark, Rob Siemborski and I feel that the current doc
accurately describes the existing deployed implementation, I intend ask
the IETF to Last Call it shortly.  If you have any comments on the
existing doc, please send them soon.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Mon, 6 Oct 2003 16:49:14 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 6 Oct 2003, Rob Siemborski wrote:
> Currently, the argument against
> creating such an extention is that "implementors get client-initial-send
> wrong" (Specifically, servers get it wrong when clients choose to not
> perform the optional initial send).  Mark, as this is your argument,
> please correct me if I have summarized it incorrectly.

Yes, that is an incorrect summary.

The argument against creating such an extension is that the current
specifications for SASL in POP3 and SMTP (which permit
client-initial-send) are complex, and as a result many POP3/SMTP servers
are not handling client-initial-send properly when the client does not
provide an initial response.

Consequently, I do not believe that IMAP should be extended to provide
client-initial-send until after the specifications are clarified.  This is
especially the case because IMAP will be a *more* complex case than
POP3/SMTP because client-initial-send is mandatory to implement in
POP3/SMTP servers but must be optional (due to compatibility with the
installed base) in IMAP servers.  Thus, the interoperability matrix with
IMAP is 4 possible configurations instead of 2 with POP3/SMTP.

The one-line summary:
	Before making it more complex, fix the existing complexity

> Isn't it typical that a SASL implementor should need to look at 3
> documents however?  The one for their protocol, the one for the mechanism
> that interests them, and RFC2222 or its replacement.

Empirical data suggests that this requires considerably more care than
currently exists among implementors.  An understanding of the correct
server behavior for "AUTH PLAIN<CRLF>" in SMTP requires reading three
documents.

> My personal reading of 2554 is that it could use a lot of rework anyway,
> and I'm toying with writing an update to it right now.  Such an update
> would include examples.

Excellent; I'll be glad to help you.

> I don't see a strong technical reason for reducing the requirement for
> SHOULD to MAY (reducing the round trips used should be encouraged).  I do
> see a strong argument for making it abundantly clear that servers MUST
> implement the correct omitted-challenge behavior (to be distinguished from
> an empty challenge -- "" is not the same as NIL)

I see it as a matter of semantics.  Too many people see a SHOULD as an
excuse to overlook a MUST.

> The examples situation should be fixed.  I don't think that we can expect
> SASL implementors to (in the general case) have to read only two RFCs,
> especially as we are breaking all of the mechanisms into their own
> documents.

I fear that it is a lot to expect them to read *one* RFC, much less grasp
concepts that only come through by reading three.  We seem to be in a
world where protocol engines are written by empirical tests and a cursory
glance at the examples in RFCs.

It is a helpful exercise to go through the steps to figure out what is the
correct server response to "AUTH PLAIN<CRLF>" in SMTP.  You have to start
with 2554, then 2595, then 2222, then back to 2554, then back to 2595.
You have to remember certain statements in each of these documents which
make no apparent sense until you read certain equally-obscure statements
in the other documents.  And you have to put this all together.

I went through this exercise with someone who I knew to be of
above-average intelligence.  It took some time before he grasped it.
That told me that the documents have a problem.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 6 Oct 2003 19:16:30 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: Re: SASL Initial Response? (fwd)
Sender: [email-masked]

Here are some of Mark's comments on RFC2222bis:

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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-----

---------- Forwarded message ----------
Date: Mon, 6 Oct 2003 16:12:58 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
Cc: RL 'Bob' Morgan <[email-masked]>,
     IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?

On Mon, 6 Oct 2003, Rob Siemborski wrote:
> I agree.  I also suspect an example or two could help the appropriate
> sections of 2222bis.  But further discussion of this should probably move
> to the ietf-sasl list.

I'm not on the ietf-sasl list, so would appreciate this being passed on.
I guess that I should be at the SASL session in Minneapolis (assuming I go
there which seems likely).

Examples are always helpful.  Section 6.1 of 2222bis should give examples
of AUTH PLAIN in SMTP both with and without initial client data.

Similar examples should appear in the specification for the PLAIN
mechanism (which currently is hidden in the IMAP/POP3/ACAP TLS spec!)
*and* in the specifications for POP3 SASL and SMTP SASL.

> Obviously.  But currently it seems that the primary reason that we don't
> have an initial SASL response in IMAP is concerns over clarity of the
> SASL specification.

Actually, the primary reason was compatibility with the past; IMAP SASL is
older than SASL.  I'm willing to go along with it as a server-optional
extension *IF* the problems with the current client-optional
server-mandatory initial client data POP3/SMTP SASL are fixed.

Since implementation of initial client data will be server-optional in
IMAP, it will be more complex than in POP3/SMTP.  This is because it's
mandatory to implement in POP3/SMTP servers.

> If fixing *that* specification still isn't good enough, I'm totally
> willing to supply text in the draft for the IMAP extention to the effect
> of "pay careful attention to the fact that initial responses are
> *optional*," even to the point of making it a Security Consideration.

We will need that text, and much more.

> And indeed, any IMAP server that didn't get this right would immediately
> have a large number of old-style clients fail to work against it anyway,
> since it is an extention and not part of the base protocol.

It's not just IMAP servers we have to worry about.  It's also IMAP
clients.

We already have clients which fail to interoperate with a server that does
not have a particular extension and/or declare such servers to be
"broken."  The offenders know who they are.

We have to concern ourselves about the possibility of clients that think
that initial data is mandatory to implement in the server (since it is
mandatory in POP3 and SMTP).

Thus, the situation is *worse* with IMAP than with POP3 or SMTP.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 6 Oct 2003 19:15:41 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?
Sender: [email-masked]

I am moving this discussion to the ietf-sasl list, since it seems to have
wandered somewhat from a discussion of IMAP's specific case.

Background for members of the IETF SASL list:  This was part of a
discussion in the IMAPEXT working group about the creation of an initial
client response extention for IMAP.  Currently, the argument against
creating such an extention is that "implementors get client-initial-send
wrong" (Specifically, servers get it wrong when clients choose to not
perform the optional initial send).  Mark, as this is your argument,
please correct me if I have summarized it incorrectly.

On Mon, 6 Oct 2003, Mark Crispin wrote:

> On Mon, 6 Oct 2003, Ken Murchison wrote:
> > > The most common offense is to implement PLAIN and LOGIN as the same thing,
> > > thus giving LOGIN challenges to PLAIN with no initial response.
> > That's inexcusable, since they are clearly NOT the same thing, and PLAIN
> > has always had a standardized SPEC.  Obviously we can't make people read
> > the specs correctly, all we can do is make them clear and unambiguous.
>
> Agreed completely.  However, multiple commercial implementations have done
> this blunder.
>
> > > The second most common offense is "334 ok, go on" or "+ ok, go on".
> > > Somtimes you also find extra CRLFs in the responses.
> > This might be an ambiguous/incomplete specification for SMTP AUTH.  I'll
> > take a look.
>
> It's not ambiguous, but you have to read three separate documents (RFCs
> 2222, 2554, and 2595) to work out how to handle an AUTH PLAIN command in
> SMTP.  For POP3, you just need to read 2222 and 2595.
>
> There is no single document, and *NO* examples, that explains this.  RFC
> 2554 is a bit better in talking about empty challenges than 2595 (see
> first paragraph of page 3, RFC 2554) but without the context of RFC 2222
> it makes no sense.

Isn't it typical that a SASL implementor should need to look at 3
documents however?  The one for their protocol, the one for the mechanism
that interests them, and RFC2222 or its replacement.

My personal reading of 2554 is that it could use a lot of rework anyway,
and I'm toying with writing an update to it right now.  Such an update
would include examples.

> > > Over and over again, I get told "just make Pine send the initial
> > > challenge"; in other words, that the initial challenge is mandatory.  But
> > > the SASL specification does not say that; and the idea of inflicting the
> > > non-interoperable brokenness of POP/SMTP on IMAP repels me.
> > So, you would like to see section 6.1 of RFC 2222bis use a MUST instead
> > of SHOULD?  For some mechs (e.g. DIGEST-MD5) this could become
> > problematic because the initial response truely is optional.
>
> Actually, I would like the SHOULD to become a MAY, and it be emphasized
> that servers MUST implement the correct empty challenge behavior.
>
> However, a MUST is preferable to the status quo, which is a de jure SHOULD
> but (at least according to certain individuals) a de facto MUST.

I don't see a strong technical reason for reducing the requirement for
SHOULD to MAY (reducing the round trips used should be encouraged).  I do
see a strong argument for making it abundantly clear that servers MUST
implement the correct omitted-challenge behavior (to be distinguished from
an empty challenge -- "" is not the same as NIL)

> > I will do this.  Just to be clear, we are only talking about
> > client-first mechanisms in which the client chooses to not send an
> > initial response, correct?
>
> Correct.  SMTP is the worst case, since you have to read three RFCs to
> work out how to implement PLAIN in SMTP.
>
> Note that there are no examples.

The examples situation should be fixed.  I don't think that we can expect
SASL implementors to (in the general case) have to read only two RFCs,
especially as we are breaking all of the mechanisms into their own
documents.

I will be forwarding your other message along to the SASL list
momentarily.

-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: [email-masked]
Subject: Re: malformed messages (Re: draft-ietf-sasl-anon-01.txt)
From: Sam Hartman <[email-masked]>
Date: Fri, 03 Oct 2003 13:59:57 -0400
Sender: [email-masked]

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

    Kurt> I'm thinking a malformed message should be treated as a
    Kurt> protocol error in the application protocol.

    Kurt> Comments?

This seems reasonable during the authentication phase, but I think we
may need to say something more specific about security layers.

Date: Fri, 03 Oct 2003 16:53:53 +0100
From: Alexey Melnikov <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt
Sender: [email-masked]

I've started with the easy (editorial) stuff and I will reply to other 
comments after the weekend.

Kurt D. Zeilenga wrote:

>Attached are my raw review notes... mostly editorial,
>clarifications, and such.  I do raise (as Hallvard did)
>some concerns with the realm text.  I'll try to pull
>that issue (and maybe a couple of other issues) out as
>separate threads.
>
>Kurt
>  
>
>>
>>1.    Abstract
>>
>>  SASL provides a method for adding authentication support with an
>>  optional security layer to connection-based protocols.
>>    
>>
>
>SASL needs to be spelled out here (first use in Abstract).
>
Done.

>>  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.
>>
>>...
>>
>>2.2.  Conventions used in this document
>>
>>  In examples, "C:" and "S:" indicate lines sent by the client and
>>  server respectively.
>>
>>  The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
>>  in this document are to be interpreted as defined in "Key words for
>>  use in RFCs to Indicate Requirement Levels" [KEYWORDS].    
>>
>
>Add U+ convent description (see SASLprep).
>
>  
>
Done.

>>...
>>
>>4.    Authentication mechanisms
>>
>>  SASL mechanisms are named by strings, from 1 to 20 characters in
>>  length, consisting of upper-case letters, digits, hyphens, and/or
>>  underscores.  SASL mechanism names must be registered with the IANA.
>>    
>>
>
>IANA should be spelled out here.
>
Ok.

>>  IETF Standards Track documents may override this registration
>>  requirement by reserving a portion of the SASL mechanism namespace
>>  for their own use; the GSSAPI mechanism specification [SASL-GSSAPI]
>>  does this.  Procedures for registering new SASL mechanisms are given
>>  in the section "Registration procedures".
>>
>>  The "sasl-mech" rule below defines the syntax of a SASL mechanism
>>  name.  This uses the augmented Backus-Naur Form (BNF) notation as    
>>
>
>s/augmented Backus-Naur Form (BNF)/Augmented Backus-Naur Form (ABNF)/
>
Done.

>>  specified in [ABNF] and the ABNF core rules as specified in Appendix
>>  A of the ABNF specification [ABNF].
>>    
>>
>>  sasl-mech    = 1*20mech-char
>>  mech-char    = %x41-5A / DIGIT / "-" / "_"
>>                 ; mech names restricted to uppercase letters,
>>                 ; digits, "-" and "_"
>>
>>
>>
>>
>>
>>
>>A. Melnikov                                             FORMFEED[Page 3]
>>
>>
>>
>>
>>
>>Internet DRAFT                    SASL                    19 August 2003
>>
>>
>>4.1.  Authentication protocol exchange
>>
>>  A SASL mechanism is responsible for conducting an authentication
>>  protocol exchange.  This consists of a series of server challenges
>>  and client responses, the contents of which are specific to and
>>  defined by the mechanism.
>>    
>>
>
>Can't the client challenge the server as well?
>
Rob has already answered this question.

> ...
>
>>  After receiving a challenge, a client mechanism may issue a response
>>  or abort the exchange.  The protocol's profile specifies how each of
>>  these is then represented over the connection.
>>    
>>
>
>Indicate here that mechanisms may also involve challenges to
>the server by the client.
>  
>
See Rob's reply.

>>...
>>
>>  An authorization identity is a string of zero or more ISO 10646
>>  [ISO-10646] coded characters.  The NUL (U+0000) character is not
>>  permitted in authorization identities. The meaning of an
>>  authorization identity of the empty string (zero length) is defined
>>  below in this section. The authorization identity is used by the
>>  server as the primary identity for making access policy decisions.
>>
>>  The character encoding scheme used for transmitting an authorization
>>  identity over protocol is specified in each authentication mechanism
>>  (with the authentication mechanism's blob being further
>>  restricted/encoded by the protocol profile).
>>    
>>
>
>I'm thinking "blob" is not a good word choice here.
>
>  Blob \Blob\ (bl[o^]b), n. [See {Bleb}.]
>     1. Something blunt and round; a small drop or lump of
>        something viscid or thick; a drop; a bubble; a blister.
>        --Wright.
>  
>     2. (Zo["o]l.) A small fresh-water fish ({Uranidea
>        Richardsoni}); the miller's thumb.
>
>>From WordNet (r) 2.0 [wn]:
>
>  blob
>       n : an indistinct shapeless form
>       v : make a spot or mark onto; "The wine spotted the tablecloth"
>           [syn: {spot}, {fleck}, {blot}]
>       [also: {blobbing}, {blobbed}]
>
>       
>You could have meant BLOB (Binary Large OBject), but this seems not to
>fit as well.
>
>I'm thinking "blob" should be replaced with "string".
>
I would rather use "data".

>>  While some legacy
>>  mechanisms are incapable of transmitting an authorization identity
>>  other than the empty string,
>>    
>>
>
>I know of mechanisms which do not transmit an authorization identity...
>but are there ones which only allow transfers of empty authorization
>identity strings?
>
No, I am not aware of any such mechanism

>>  newly defined mechanisms are expected to
>>  be capable of carrying the entire Unicode repertoire (with the
>>  exception of the NUL character). An authorization identity of the
>>  empty string and and an absent authorization identity MUST be treated
>>    
>>
>
>s/and and/and/
>
Yes, already fixed in my diff ;-).

>>  as equivalent.  However, mechanisms SHOULD NOT allow both (i.e. if an
>>
>>
>>
>>A. Melnikov                                             FORMFEED[Page 4]
>>
>>
>>
>>
>>
>>Internet DRAFT                    SASL                    19 August 2003
>>
>>
>>  authorization identity is allowed to be absent, but one is
>>  transferred, it SHOULD NOT be an empty string).
>>    
>>
>
>Suggest this be reworded:
>	However, mechanisms SHOULD NOT allow both.  That is, a mechanism
>	which provides an optional field for an authorization identity,
>	SHOULD NOT allow that field, when present, to be empty.
>  
>
Done (I didn't like the original either, but couldn't think of anything 
better).

>>  This feature permits agents such as
>>  proxy servers to authenticate using their own credentials, yet
>>  request the access privileges of the identity for which they are
>>  proxying.
>>
>>  The server makes an implementation defined policy decision as to
>>  whether the authentication identity is permitted to have the access
>>  privileges of the authorization identity and whether the
>>  authorization identity is permitted to receive service.  If it is
>>  not, the server indicates failure of the authentication protocol
>>  exchange.
>>
>>  As a client might not have the same information as the server,
>>  clients SHOULD NOT themselves try to derive authorization identities
>>  from authentication identities when clients could instead transmit an
>>  authorization identity of the empty string.
>>    
>>
>
>I suggest rewording this:
>	As a client might not have the same information as the
>	server, clients SHOULD NOT derive authorization identities
>	from authentication identities.  Instead, clients SHOULD
>	provide no (or empty) authorization identity when the user
>	has not provided an authorization identity.
>
Ok.

>>...
>>
>>   In this example, the client is proxy
>>  authenticating, sending the authorization id "fred".  The server has
>>  determined the client's identity through IPsec and has a security
>>  policy that permits that identity to proxy authenticate as any other
>>  identity.
>>
>>  To the protocol profile, the four octet sequence "fred" is an opaque
>>  binary blob.  The SASL protocol profile for SMTP specifies that
>>  server challenges and client responses are encoded in BASE64; the
>>  BASE64 encoding of "fred" is "ZnJlZA==".
>>    
>>
>
>s/binary blob/string/
>
I've changed this to "data" instead, as above.

>>...
>>
>>     S: 220 smtp.example.com ESMTP server ready
>>     C: EHLO jgm.example.com
>>     S: 250-smtp.example.com
>>     S: 250 AUTH DIGEST-MD5 EXTERNAL
>>     C: AUTH EXTERNAL ZnJlZA==
>>     S: 235 Authentication successful.
>>
>>8.    IANA Considerations
>>
>>  Registration of a SASL mechanism is done by filling in the template
>>  in section 8.4 and sending it in to [email-masked].  IANA has the
>>  right to reject obviously bogus registrations, but will perform no
>>  review of claims made in the registration form.
>>
>>
>>
>>
>>A. Melnikov                                            FORMFEED[Page 11]
>>
>>
>>
>>
>>
>>Internet DRAFT                    SASL                    19 August 2003
>>
>>
>>  There is no naming convention for SASL mechanisms; any name that
>>  conforms to the syntax of a SASL mechanism name can be registered.
>>  An IETF Standards Track document may reserve a portion of the SASL
>>  mechanism namespace for its own use, amending the registration rules
>>  for that portion of the namespace.
>>
>>  While the registration procedures do not require it, authors of SASL
>>  mechanisms are encouraged to seek community review and comment
>>  whenever that is feasible.  Authors may seek community review by
>>  posting a specification of their proposed mechanism as an internet-
>>  draft.  SASL mechanisms intended for widespread use should be
>>  standardized through the normal IETF process, when appropriate.
>>
>>8.1.  Comments on SASL mechanism registrations
>>
>>  Comments on registered SASL mechanisms should first be sent to the
>>  "owner" of the mechanism.  Submitters of comments may, after a
>>  reasonable attempt to contact the owner, request IANA to attach their
>>  comment to the SASL mechanism registration itself.  If IANA approves
>>  of this the comment will be made accessible in conjunction with the
>>  SASL mechanism registration itself.
>>
>>8.2.  Location of registered SASL mechanism list
>>
>>  SASL mechanism registrations are available at the URL
>>  "http://www.iana.org/assignments/sasl-mechanisms" The SASL mechanism
>>    
>>
>
>Replace quotes with < and >, and insert a period at the end of the
>sentence.
>  
>
Already done.

>>  description and other supporting material may also be published as an
>>  Informational RFC by sending it to "[email-masked]"
>>  (please follow the instructions to RFC authors [RFC-INSTRUCTIONS]).
>>    
>>
>
>Drop "by sending (...)".
>
Done.

>>...
>>
>>9.    References
>>
>>9.1.  Normative References
>>
>>  [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
>>  ABNF", RFC 2234, November 1997
>>
>>  [CHARSET-POLICY] Alvestrand, "IETF Policy on Character Sets and
>>  Languages", RFC 2277, January 1998
>>
>>  [GSSAPI] Linn, "Generic Security Service Application Program
>>  Interface, Version 2, Update 1", RFC 2743, January 2000
>>
>>  [ISO-10646] "Universal Multiple-Octet Coded Character Set (UCS) -
>>  Architecture and Basic Multilingual Plane", ISO/IEC 10646-1 : 1993.
>>    
>>
>
>For consistency (all other references use tags not associated with
>their document numbers), I suggest replacing the tag [ISO-10646]
>with [UCS].
>  
>
I frankly doubt that this make it any better.

>>  [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
>>  Requirement Levels", RFC 2119, March 1997
>>
>>  [Stringprep] P. Hoffman, M. Blanchet, "Preparation of
>>  Internationalized Strings ("stringprep")", RFC 3454, December 2002.
>>
>>  [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user names
>>  and passwords", Work in progress, draft-ietf-sasl-saslprep-XX.txt.
>>
>>  [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646", work
>>  in progress (draft-yergeau-rfc2279bis-XX) that replaces RFC 2279,
>>  Janyary 1998
>>
>>...
>>
>>12.   Acknowledgments
>>
>>  This document is a revision of RFC 2222 written by John G. Myers
>>  <[email-masked]>. He also wrote the major part of this
>>  document.
>>    
>>
>
>Drop John's e-mail address here.  I suggest replacing the second
>sentence with:
>	He also contributed significantly to this revision.
>
Ok.

>>  Thank you to Magnus Nystrom for the ASCII picture used in section
>>  6.3. 
>>
>
>	Magnus Nystrom provided the ASCII art used in Section 6.3.
>  
>
Ok.

>>  Definition of realm was extracted from RFC 2617 ("HTTP
>>  Authentication: Basic and Digest Access Authentication").
>>
>>  Contributions of many members of the SASL mailing list are gratefully
>>  acknowledged.
>>    
>>
>
>s/mailing list/working group/
>
A lot of contribution was done before we had a working group.
(Not that it worth arguing about anyway.)

>>...
>>
>>Appendix B. IANA considerations
>>
>>  The IANA is directed to modify the SASL mechanisms registry as
>>  follows:
>>    
>>
>
>Please reword this to be not so demanding.  For example,
>	It is requested that IANA update the SASL mechanisms registry
>	as follows:
>  
>
Ok.

Alexey

Date: Fri, 03 Oct 2003 01:39:46 -0600
From: Lyndon Nerenberg <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
Subject: Re: malformed messages (Re: draft-ietf-sasl-anon-01.txt)
Sender: [email-masked]

> At 02:19 PM 10/2/2003, Simon Josefsson wrote:
>> * The document doesn't mandate any specific action when the client
>>  send an invalid string (e.g., one that is rejected by string
>>  processing)
[...]
> That is, what should the implementation do if the message it receives
> is malformed?

In the absence of a very compelling reason to do otherwise, the 
application should immediately fail the transaction. "Be liberal in what 
you accept" has no place here. However, I'm more concerned about protocol 
parser state machines getting out of sync (see the recent spate of -- 
again -- ASN.1 parser bugs) than applications misinterpreting bogus realm 
strings.

> I note that this issue is likely not unique to ANONYMOUS.  So, maybe
> it should be dealt with in base SASL specification.
[...]
> I'm thinking a malformed message should be treated as a protocol
> error in the application protocol.

[Son-of-]2222 is a framework document, so I'm not sure if we can mandate 
that sort of behaviour in it. But that cannot stop us from suggesting 
some extremely rude behaviour towards authors of deviant software in the 
Security Considerations section.

--lyndon

Date: Fri, 03 Oct 2003 06:41:43 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: malformed messages (Re: draft-ietf-sasl-anon-01.txt)
Sender: [email-masked]

Simon raised this issue to me privately... but I think it needs
broader discussion (given that it is a technical issue).

At 02:19 PM 10/2/2003, Simon Josefsson wrote:
>* The document doesn't mandate any specific action when the client
>  send an invalid string (e.g., one that is rejected by string
>  processing).

That is, what should the implementation do if the message it receives
is malformed?

I note that this issue is likely not unique to ANONYMOUS.  So, maybe
it should be dealt with in base SASL specification.

I'm thinking a malformed message should be treated as a protocol
error in the application protocol.

Comments?

Kurt 

Date: Wed, 1 Oct 2003 14:46:14 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Sam Hartman <[email-masked]>
cc: "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt
Sender: [email-masked]

On Wed, 1 Oct 2003, Sam Hartman wrote:

>     Kurt> Can't the client challenge the server as well?
>
> I always thought that in SASL, the challenge was defined to be the
> message from the server to the client even if it didn't serve that
> purpose in a security sense.

I agree.

Indeed, in 6.1 we refer to an "initial client response" even though it
could, in fact, be an initial challenge from client to server.

-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: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt
From: Sam Hartman <[email-masked]>
Date: Wed, 01 Oct 2003 14:20:02 -0400
Sender: [email-masked]

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

    >> 4.1.  Authentication protocol exchange
    >> 
    >> A SASL mechanism is responsible for conducting an
    >> authentication protocol exchange.  This consists of a series of
    >> server challenges and client responses, the contents of which
    >> are specific to and defined by the mechanism.

    Kurt> Can't the client challenge the server as well?

I always thought that in SASL, the challenge was defined to be the
message from the server to the client even if it didn't serve that
purpose in a security sense.

--Sam

Date: Wed, 01 Oct 2003 11:43:34 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt
Sender: [email-masked]

On Wednesday, October 01, 2003 10:17:55 -0700 "Kurt D. Zeilenga" 
<[email-masked]> wrote:

>> Network Working Group                                        A. Melnikov
>> Internet Draft                                                    Editor
>> Document: draft-ietf-sasl-rfc2222bis-02.txt                  August 2003
>>                                                   Expires in six months

Well, it doesn't matter now, but "expires in six months" is not acceptable; 
a specific date must be specified.  See the "Formatting" section in 
1id-guidelines.txt

>> 1.    Abstract

Don't number the abstract.

>> 4.    Authentication mechanisms
>>
>>   SASL mechanisms are named by strings, from 1 to 20 characters in
>>   length, consisting of upper-case letters, digits, hyphens, and/or
>>   underscores.  SASL mechanism names must be registered with the IANA.
>
> IANA should be spelled out here.
>
>>   IETF Standards Track documents may override this registration
>>   requirement by reserving a portion of the SASL mechanism namespace
>>   for their own use; the GSSAPI mechanism specification [SASL-GSSAPI]
>>   does this.  Procedures for registering new SASL mechanisms are given
>>   in the section "Registration procedures".

Ick.  IMHO this phrasing is ugly and not necessary.  It appears to 
encourage authors of documents like SASL-GSSAPI to allocate themselves 
parts of the namespace without bothering to direct the IANA to reserve 
them.  This would be a bad thing, and would indeed require that a potential 
future protocol designer (and/or the IANA itself) search the complete space 
of standards-track documents to see if the name they want to use has been 
reserved.

IETF standards-track documents do not need the SASL spec's permission to 
direct the IANA to reserve parts of the namespace; thus, I don't think it's 
necessary to mention it at all.  However, if it is mentioned, it should be 
in the IANA considerations section, not here, and with text like "IETF 
standards track documents may direct the IANA to reserve a portion of the 
SASL mechansim namespace and may specify different registration criteria 
for the reserved portion."

Given the large size of the mechanism namespace, it is unfortunate that we 
have failed to provide for mechanism names of the form foo@domain. 
Delegated registration is much less work for IANA.

>>   Per IETF character set
>>   policy [CHARSET-POLICY], authentication mechanisms SHOULD encode
>>   these and other strings in UTF-8 [UTF-8].
>
> This seems counter to [CHARSET-POLICY] as it allows a mechanism to
> not support UTF-8 transfer of character data.
>
> [CHARSET-POLICY] says:
>    Protocols MUST be able to use the UTF-8 charset, which consists of
>    the ISO 10646 coded character set combined with the UTF-8 character
>    encoding scheme, as defined in [10646] Annex R (published in
>    Amendment 2), for all text.

It would probably be appropriate to require applications to deal, though 
the truth is that CHARSET-POLICY already does that without our help.

While we can impose requirements on SASL mechanisms, we really can't impose 
requirements on the authentication technologies upon which they are built. 
Requiring mechanisms to use UTF-8 might impose an impossible burden on the 
SASL mechansim designer, forcing them to do transformations between Unicode 
and some other character set.

So, it is appropriate to REQUIRE that authorization identities (which are 
not really owned by the mechanism anyway) be encoded as UTF-8, and I think 
we should do so.  But it may not be appropriate for "other strings".

>>   If the authorization identity transmitted during the authentication
>>   protocol exchange is not the empty string, this is typically referred
>>   to as "proxy authentication".
>
> Personally, I refer to this as "proxy authorization".  Proxy
> authentication makes it sound like the feature can be used by a
> proxy to authenticate its users.

The same argument can be made for "proxy authorization".  We are talking 
about "authentication by proxy", not "authentication to a proxy".  And yes, 
we're really talking about authorization, not authentication, but it's not 
really "authorization by proxy"; it's just authorization.

The terminology is pretty bad.  It's not clear to me that we need a name 
for this at all.  But I'm pretty sure the phrase "proxy authentication" has 
been in use for a while, and to change it might cause more confusion than 
leaving it alone.

>>   This feature permits agents such as
>>   proxy servers to authenticate using their own credentials, yet
>>   request the access privileges of the identity for which they are
>>   proxying.

Sure, but that's not really all it's good for.  It also allows 
[email-masked] to log in to the IMAP server on CYRUS.ANDREW.CMU.EDU as 
'jhutz', even though the server is in the ANDREW.CMU.EDU realm.  And 
similar functionality, though not using SASL, allows me to type 
"[email-masked],maint:" at a login prompt, followed by [email-masked]'s 
password, and log in as the user 'maint'.

>>   The server SHOULD verify the correctness of a received authorization
>>   identity.
>
> "Correctness" here doesn't appear to be correct.  And it should
> be a MUST.   I suggest:
> 	The server SHALL fail the authentication exchange if the
> 	authenticated client is not allowed to assume the asserted
> 	authorization identity.

s/SHALL/MUST/

>> 4.4.  Character string issues
>>
>>   Per IETF character set policy [CHARSET-POLICY], authentication
>>   mechanisms SHOULD encode character strings in UTF-8 [UTF-8].
>
> See above note about charset-policy.

And my response.  It's really quite important that we get this right for 
authentication identities, or we risk invalidating a number of popular 
mechanisms because they are based on underlying authentication technology 
which does not use UTF-8.

>> 5.    Protocol profile requirements
>>
>>   In order to use this specification, a protocol definition MUST supply
>>   the following information:
>>
>>   A service name, to be selected from the IANA registry of "service"
>>   elements for the GSSAPI host-based service name form. [GSSAPI]  This
>>   service name is made available to the authentication mechanism.
>>
>>   The registry is available at the URL
>>   "http://www.iana.org/assignments/gssapi-service-names" A definition

Paragraph break.

>>   A definition of the method by which the authentication protocol
>>   exchange is carried out, including how the challenges and responses
>>   are encoded, how the server indicates completion or failure of the
>>   exchange, how the client aborts an exchange, and how the exchange
>>   method interacts with any line length limits in the protocol.
>>
>>   The command SHOULD have a method for the server to include an
>>   optional challenge with a success notification.  This allows the
>>   server to avoid a round trip when using a mechanism which is defined
>>   to have the server send additional data along with the indication of
>>   successful completion.  See section 6.2 of this document for further
>>   information.

What command?  Who says "the method by which the authentication protocol 
exchange is carried out" is a command?  s/The command/The exchange method/

>>   Certain SASL mechanisms, e.g. DIGEST-MD5 [SASL-DIGEST], use a concept
>>   of realm.
>
> I think it unwise to enter into a discussion of realms here.
> Realm syntax and semantics are, for mechanisms which have realms,
> mechanism specific.  The mechanism specification should state how
> they are to be compared.  The mechanism specification should state
> how they are to constructed and used in the mechanism and, where
> appropriate, state any protocol profiling requirements.  (Note:
> I'd likely doubt any mechanism attempt to state protocol profiling
> requirements as this breaks SASL's separation of profile and
> mechanism).

I agree.  A realm is just part of the authentication identities used by 
certain mechanisms.  It is mechanism-specific, and a discussion of realms 
is irrelevant to protocol profiling.

>>   A protocol profile SHOULD provide a guidance how realms are to be
>>   constructed and used in the protocol and MAY further restrict its
>>   syntax and protocol-specific semantics.

Absolutely not.  Protocols may decide to include some concept of realm in 
their authorization identities, but they have no business whatsoever 
defining the semantics of authentication identities.  That is the 
responsiblity of the mechanism.

>>   Below the term "realm" has the meaning as defined in the section 5.
>>   A security layer that remains in effect when a client, which already
>>   has authenticated and established the security layer with "Realm A",
>>   authenticates to "Realm B", without negotiating a new security layer,
>>   enables "Realm B" to make guesses about previously observed
>>   ciphertext using the server's SASL engine as an oracle. "Realm B" may
>>   observe how known cleartext is encrypted.
>>
>>              +---------+                   +---------+
>>              |         |                   |         |
>>              | Realm B |                   | Realm A |
>>              |         |                   |         |
>>              +---------+                   +---------+
>>                  |  ^                           |
>>                  |  :      +-----------+        |
>>     Traffic from |  :      | Encryption|        | Traffic from A
>>      B to client +-------->| end point |<-------+ to client
>>                     :      | (SSL/SASL)|
>>                     :      +-----------+
>>                     :            |
>>                     :            |
>>                     :          +---+
>>                     :          |   |
>>                     :          |   |
>>                     :          |   | Encryption tunnel, e.g. SASL or SSL,
>>                     :          |   | between the server
>
>>           encrypted            |   | Separate tunnels to different
>>           traffic between      |   | clients.
>>           Realm A and client   +---+
>>                                  |
>>                                  |
>>                                  +-----------> Traffic to clients

This discussion is confusing and makes no sense to me.  SASL doesn't 
protect traffic between "realms" and clients; it protects traffic between 
_servers_ and clients.  This needs to be reworded so it makes sense, in 
terms of entities known to the SASL framework.  A "realm" is not such an 
entity; it is no more than part of the autentication identities used by 
some mechanisms, and has no place outside the mechainsm specification.

Put another way, and ignoring the issue of "realms"; the above description 
makes so little sense to me that I cannot evaluate its validity or 
understand what attack we are trying to avoid.

>> 8.    IANA Considerations
>>
>>   Registration of a SASL mechanism is done by filling in the template
>>   in section 8.4 and sending it in to [email-masked].  IANA has the
>>   right to reject obviously bogus registrations, but will perform no
>>   review of claims made in the registration form.

Provide the template.  Do not specify how to communicate the registration 
to the IANA, because that may change over time and is out of scope for this 
document.

>>   There is no naming convention for SASL mechanisms; any name that
>>   conforms to the syntax of a SASL mechanism name can be registered.
>>   An IETF Standards Track document may reserve a portion of the SASL
>>   mechanism namespace for its own use, amending the registration rules
>>   for that portion of the namespace.

Again, too bad we didn't allow for [email-masked].

>> 8.2.  Location of registered SASL mechanism list
>>
>>   SASL mechanism registrations are available at the URL
>>   "http://www.iana.org/assignments/sasl-mechanisms" The SASL mechanism
>
> Replace quotes with < and >, and insert a period at the end of the
> sentence.
>
>>   description and other supporting material may also be published as an
>>   Informational RFC by sending it to "[email-masked]"
>>   (please follow the instructions to RFC authors [RFC-INSTRUCTIONS]).
>
> Drop "by sending (...)".

IMHO, drop the whole subsection.  IANA considerations are about telling the 
IANA what it needs to do and be aware of with respect to this document. 
It's appropriate to specify the form of registration and the rules which 
govern whether IANA should accept a registration.  It is not appropriate to 
specify the means used to communicate with the IANA or the RFC Editor, or 
to direct the IANA as to the URL at which it must provide the registration 
data.  These things may change over time, and it is out of scope for the 
SASL working group (or, indeed, the IETF) to specify them.

>> 8.3.  Change control
>>
>>   Once a SASL mechanism registration has been published by IANA, the
>>   author may request a change to its definition.  The change request
>>   follows the same procedure as the registration request.

This sounds a lot like the stringprep loophole, and it makes me nervous.

>> 9.2.  Informative References
>>
>>   <<Update the reference below>> [SASL-GSSAPI] Myers, "SASL GSSAPI
>>   mechanisms", work in progress, draft-ietf-cat-sasl-gssapi-XX.txt,
>>   September 2000

>>   [SASL-DIGEST] Leach, P., Newman, C., Melnikov, A., "Using Digest
>>   Authentication as a SASL Mechanism", work in progress, draft-ietf-
>>   sasl-rfc2831bis-XX.txt, replaces RFC 2831

I think it would be good to eliminate references to new or updated 
mechanisms if at all possible, since otherwise we are forced to either 
publish a document with incorrect or incomplete references, or wait until 
those documents are ready.  If we keep them, use the correct reference form:

[SASL-GSSAPI] Myers, "SASL GSSAPI mechanisms" 
(draft-ietf-cat-sasl-gssapi-01.txt)

See "References" in section 2 of ID-nits.

>>   [IANA-SASL]  IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
>>   MECHANISMS", http://www.iana.org/assignments/sasl-mechanisms.

Ew.  I don't think this is necessary.  Also, references to URL's are to be 
avoided, as they may change, rendering the document obsolete and confusing. 
See "References" in section 2 of id-nits.

>>   "stringprep" and Unicode security considerations apply to
>>   authentication identities, authorization identities and passwords.

Include references to these.

Put Security Considerations _before_ references, not after.

>> 12.   Acknowledgments

>>   Definition of realm was extracted from RFC 2617 ("HTTP
>>   Authentication: Basic and Digest Access Authentication").

Except we should be dropping the definition of "realm".

>>   In certain situations, it is reasonable to use SASL underneath one of
>>   these Transport Security services.  The transport service would
>>   secure the connection, either service would authenticate the client,
>>   and SASL would negotiate the authorization identity.  The SASL
>>   negotiation would be what moves the protocol from "unauthenticated"
>>   to "authenticated" state.  The "EXTERNAL" SASL mechanism is
>>   explicitly intended to handle the case where the transport service
>>   secures the connection and authenticates the client and SASL
>>   negotiates the authorization identity.
>>
>>   When using SASL underneath a sufficiently strong Transport Security
>>   service, a SASL security layer would most likely be redundant.  The
>>   client and server would thus probably want to negotiate off the use
>>   of a SASL security layer.

Please don't say this without a _lot_ more text explaining when it is safe. 
A common configuration is to run SASL under TLS, using SASL for client 
authentication and negotation of the authorization identity.  In this 
configuration, it is _not_ safe to skip using a SASL security layer if the 
client did not check the server's certificate (there is a tunnelling MitM 
attack), and it's not a particularly good idea even if the server cert was 
checked, because the client's authentication is still not bound to the 
encryption keys used at the TLS layer.

We already have problems with people who think it is actively bad to use a 
SASL security layer under TLS.  The result is that some insecure 
configurations are now widely deployed.  Let's not encourage this any 
further.

>> Appendix B. IANA considerations

Uh, no.  IANA considerations were section 8.  Please merge them.

>>   The IANA is directed to modify the SASL mechanisms registry as
>>   follows:
>
> Please reword this to be not so demanding.  For example,
> 	It is requested that IANA update the SASL mechanisms registry
> 	as follows:

It's not demanting; it's perfectly reasonable usage.  The IANA works for 
the IETF; it is appropriate for the IETF, in the form of a standards-track 
document, to direct it to make changes to a registry.  It is also common 
usage.

Put the TOC at the _top_ of the document, just after the abstract.  See the 
"Tabel of Contents" section at http://www.rfc-editor.org/policy.html

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

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: empty authzid in draft-ietf-sasl-plain-02.txt
Date: Wed, 1 Oct 2003 15:49:40 +0200
Sender: [email-masked]

draft-ietf-sasl-plain-02.txt says that

  The client leaves
  the authorization identity empty if it wishes the server to derive the
  authorization identity from the provided authentication identity.

and

  Note that the parameters provided to the Authorize function are not
  prepared.

so I think the pseudo-code for empty authzid should say
          authzid = DeriveAuthzid(authcid);
and not
          authzid = DeriveAuthzid(pAuthcid);

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt
Date: Wed, 1 Oct 2003 15:25:25 +0200
Sender: [email-masked]

Kurt D. Zeilenga writes:
>>   The character encoding scheme used for transmitting an authorization
>>   identity over protocol is specified in each authentication mechanism
>>   (with the authentication mechanism's blob being further
>>   restricted/encoded by the protocol profile).
> 
> I'm thinking "blob" is not a good word choice here.  (...)
> I'm thinking "blob" should be replaced with "string".

But which string is the draft talking about?

-- 
Hallvard