Subject: Some thoughts on SASLPrep usage in DIGEST-MD5
From: Alexey Melnikov <[email-masked]>
To: SASL WG <[email-masked]>
Date: Wed, 27 Jul 2005 10:45:41 +0100
List-Id: <ietf-sasl.imc.org>

I was updating SASLPrep text in the DIGEST-MD5 draft (more like 
wrestling really) and came to a conclusion that the original text was 
giving wrong recommendations. Here is my take on where SASLPrep should 
be happening in DIGEST-MD5:

1). The server generates a list of realms it supports. They SHOULD 
(can't be MUST, as no server out there currently do that) be sent in the 
prepared form.

Client can verify if realms are in prepared form, but this seems rather 
pointless. The client can refuse to work with non-prepared realms (which 
will reduce interoperability, especially when working with old clients) 
or the client can log a warning that the realms are not prepared. Both 
seems of marginal utility to me.

The client can also prepare the received realms. This is effectively the 
same as "refuse to work with non-prepared realms", because if the 
prepared value != received value, than the calculated hashes would not 
match. (Unless the server only supports a single realm and doesn't check 
that the value received from the client is not the same as the sent value)

2). The client picks a realm. If it chooses to use a realm different 
from all realms provided by the server, it SHOULD prepare it, before 
calculating hashes and sending it to server.
If the client decides to use one of the realms provided by the server, 
it MUST NOT prepare it, or authentication exchange might fail later on.

3). The client obtains username and password (from user or 
configuration), both SHOULD be prepared with SASLPrep. The prepared 
versions are used in hashes and sent to the server.
The server MUST NOT prepare the received username.

Does this make any sense?

There are other peculiar interop issues between old and new 
clients/servers, which this doesn't cover. For example, what if we 
consider a client that used SASLPrep on password and a server that 
stores digest hashes and the password wasn't prepared with SASLPrep when 
the hash was calculated?

Alexey

Date: Wed, 27 Jul 2005 10:23:47 +0100
From: Alexey Melnikov <[email-masked]>
To: SASL WG <[email-masked]>
Subject: Changes in DIGEST-MD5 -06
Sender: [email-masked]

Below is the list of changes since -05, plus some questions to the group:

1). Removed any mentioning of DES/3DES ciphers.
2). Updated references to the documents containing ABNF for IPv4/IPv6 
addresses.
3). Added IANA Considerations section.
4). Updated ABNF to be more aligned with RFC 2617 (HTTP Digest), in 
particular
 a). clarified which values should be unquoted before hashing. This is 
done using "unq(X)" construct when describing the hashing procedure.
 b). nonce/cnonce values allow [again] for "\" and <">. Once upon a time 
Cyrus SASL wasn't escaping these characters in quoted strings, so I 
though that it would be prudent to prohibit them. However this is fixed 
now. Does anybody know of any implementation that actually generates "\" 
and <"> in nonces?
5). Rewrote text about performing SASLPrep. The original text was a mess 
(probably still is), because it was recommending to use SASLPrep in 
wrong places, IMHO. I will send a separate message that will describe 
the changes in more details.

Alexey

From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: [(nowhere)] Review: Simple Authentication and Security Layer  (SASL)
Date: Tue, 26 Jul 2005 16:00:21 -0400
Sender: [email-masked]

Simon,

> Perhaps it would help to move this discussion forward if you could try
> to propose actual modifications?

Sure, let me suggest the following paragraph from earlier email with
the controversial bit at the end removed:

> > There are two sorts of character data that a SASL mechanism
> > may need to deal with, the authorization identity string, and any
> > other character data that the mechanism uses.  Different rules
> > and responsibilities apply to these two classes of character data.
> > Character normalization (e.g., stringprep) of the authorization
> > identity string is the protocol's responsibility.  Character
> > normalization of any other character data is the SASL mechanism's
> > responsibility, and the SASL mechanism is also responsible
> > for all Unicode character encoding.  This split in responsibility
> > is necessary for compatibility with existing mechanisms and
> > implementations

To which I would add: "and to allow SASL mechanisms to be used in
multiple protocols that may have different character normalization
requirements for authentication identities."

Of the Unicode issues, this is the important one, as the potential
need to use two different normalization rules for character data
in a single SASL mechanism is going to come as a surprise to some
implementers who are new to the wonders of Unicode and i18n.  I think
the above text (or something along those lines) is needed to alert
those who haven't thought through the Unicode/i18n implications of
SASL mechanism reuse.

Turning to number of normalizations:

> I believe a single normalization and encoding is a pipe dream, I'm
> afraid.
>
> SASLprep is not applicable to all data, it was designed for simple
> usernames and passwords.  It would be incorrect to use it on X.509
> DN's (for PKI-based SASL mechanisms) or a hostname (for some kind of
> host-based SASL mechanism) or a XMPP/Jabber user identity.  Even the
> new ANONYMOUS mechanism don't use SASLprep, rather it has its own
> normalization scheme, and for a good reason.

I understand and agree with the quoted text.  I did not mean to suggest
using SASLprep for everything, but rather that [proposed text]:

	When designing a SASL mechanism for which the syntax of
authorization
	identities is known, using a character normalization mechanism
	appropriate to those identities for all character data in the SASL
	mechanism avoids the need for two different normalizations,
potentially
	simplifying implementations.  For example, for a PKI SASL mechanism
	where X.509 DN's are expected as authorization identities, a
stringprep
	variant appropriate for X.509 DN's could be specified for all other
	character data in the SASL mechanism (e.g., LDAP stringprep
	[draft-ietf-ldapbis-strprep], as applied to X.509 DN's in
	[draft-hoffman-pkix-stringmatch], thereby avoiding the need to
	implement both LDAP stringprep and SASLprep).

And number of encodings:

> Regarding encoding, existing SASL mechanisms, such as (if I recall
> correctly) NTLM, use UTF-16 today.  There is no compelling reason to
> forbid that, even if we should recommend against anything but UTF-8.
> But the IETF already do push UTF-8 strongly.  I don't think a
> completely new SASL mechanism that used UTF-16 would fly in the IETF.

I (now) agree - "running code" wins over simplicity here, so recommending
UTF-8 in the absence of compelling reasons to use something else (e.g.,
backwards compatibility) should be fine.

Do these suggestions seem reasonable?

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Simon Josefsson [mailto:[email-masked]] 
> Sent: Tuesday, July 19, 2005 5:21 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [(nowhere)] Review: Simple Authentication and 
> Security Layer (SASL)
> 
> [email-masked] writes:
> 
> > There are two sorts of character data that a SASL mechanism
> > may need to deal with, the authorization identity string, and any
> > other character data that the mechanism uses.  Different rules
> > and responsibilities apply to these two classes of character data.
> > Character normalization (e.g., stringprep) of the authorization
> > identity string is the protocol's responsibility.  Character
> > normalization of any other character data is the SASL mechanism's
> > responsibility, and the SASL mechanism is also responsible
> > for all Unicode character encoding.  This split in responsibility
> > is necessary for compatibility with existing mechanisms and
> > implementations, but implementation complexity may be reduced when
> > protocols and the SASL mechanisms they use are designed to use a
> > single normalization and a single encoding are used for all 
> character
> > data involved in SASL.
> 
> I believe a single normalization and encoding is a pipe dream, I'm
> afraid.
> 
> SASLprep is not applicable to all data, it was designed for simple
> usernames and passwords.  It would be incorrect to use it on X.509
> DN's (for PKI-based SASL mechanisms) or a hostname (for some kind of
> host-based SASL mechanism) or a XMPP/Jabber user identity.  Even the
> new ANONYMOUS mechanism don't use SASLprep, rather it has its own
> normalization scheme, and for a good reason.
> 
> Regarding encoding, existing SASL mechanisms, such as (if I recall
> correctly) NTLM, use UTF-16 today.  There is no compelling reason to
> forbid that, even if we should recommend against anything but UTF-8.
> But the IETF already do push UTF-8 strongly.  I don't think a
> completely new SASL mechanism that used UTF-16 would fly in the IETF.
> DIGEST-MD5 also has its share of legacy in this regard, it support
> Latin-1 too, which is required for those with deployed shared-secret
> DIGEST-MD5 user databases.
> 
> As much as I'd like for the core document to be clear on this topic (I
> have tried to argue for this in the past), I couldn't seem to find any
> way to put down in writing exactly those requirements we would want to
> impose without excluding otherwise good SASL mechanism designs.
> 
> Perhaps it would help to move this discussion forward if you could try
> to propose actual modifications?  I found doing that was harder than I
> thought, so I gave up.  I support the current
> leave-all-the-gory-details-for-the-mechanism-and-profiles position.
> 
> Note that implementations may still use UTF-8 everywhere.  My SASL
> library do exactly that.  Converting to and from the wire-encoding can
> happen within the mechanism.  Normalizing all data using SASLprep is
> plain wrong though.
> 
> Regards,
> Simon
> 

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-rfc2831bis-06.txt 
Date: Tue, 19 Jul 2005 15:50:01 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Using Digest Authentication as a SASL
                          Mechanism
	Author(s)	: P. Leach, et al.
	Filename	: draft-ietf-sasl-rfc2831bis-06.txt
	Pages		: 45
	Date		: 2005-7-19
	
This specification defines how HTTP Digest Authentication [Digest]
   can be used as a SASL [RFC 2222] mechanism for any protocol that has
   a SASL profile. It is intended both as an improvement over CRAM-MD5
   [RFC 2195] and as a convenient way to support a single authentication
   mechanism for web, mail, LDAP, and other protocols.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sasl-rfc2831bis-06.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-rfc2831bis-06.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-rfc2831bis-06.txt

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

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

--OtherAccess--

--NextPart--

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [(nowhere)] Review: Simple Authentication and Security Layer  (SASL)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 19 Jul 2005 11:21:05 +0200
Sender: [email-masked]

[email-masked] writes:

> There are two sorts of character data that a SASL mechanism
> may need to deal with, the authorization identity string, and any
> other character data that the mechanism uses.  Different rules
> and responsibilities apply to these two classes of character data.
> Character normalization (e.g., stringprep) of the authorization
> identity string is the protocol's responsibility.  Character
> normalization of any other character data is the SASL mechanism's
> responsibility, and the SASL mechanism is also responsible
> for all Unicode character encoding.  This split in responsibility
> is necessary for compatibility with existing mechanisms and
> implementations, but implementation complexity may be reduced when
> protocols and the SASL mechanisms they use are designed to use a
> single normalization and a single encoding are used for all character
> data involved in SASL.

I believe a single normalization and encoding is a pipe dream, I'm
afraid.

SASLprep is not applicable to all data, it was designed for simple
usernames and passwords.  It would be incorrect to use it on X.509
DN's (for PKI-based SASL mechanisms) or a hostname (for some kind of
host-based SASL mechanism) or a XMPP/Jabber user identity.  Even the
new ANONYMOUS mechanism don't use SASLprep, rather it has its own
normalization scheme, and for a good reason.

Regarding encoding, existing SASL mechanisms, such as (if I recall
correctly) NTLM, use UTF-16 today.  There is no compelling reason to
forbid that, even if we should recommend against anything but UTF-8.
But the IETF already do push UTF-8 strongly.  I don't think a
completely new SASL mechanism that used UTF-16 would fly in the IETF.
DIGEST-MD5 also has its share of legacy in this regard, it support
Latin-1 too, which is required for those with deployed shared-secret
DIGEST-MD5 user databases.

As much as I'd like for the core document to be clear on this topic (I
have tried to argue for this in the past), I couldn't seem to find any
way to put down in writing exactly those requirements we would want to
impose without excluding otherwise good SASL mechanism designs.

Perhaps it would help to move this discussion forward if you could try
to propose actual modifications?  I found doing that was harder than I
thought, so I gave up.  I support the current
leave-all-the-gory-details-for-the-mechanism-and-profiles position.

Note that implementations may still use UTF-8 everywhere.  My SASL
library do exactly that.  Converting to and from the wire-encoding can
happen within the mechanism.  Normalizing all data using SASLprep is
plain wrong though.

Regards,
Simon

From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: [(nowhere)] Review: Simple Authentication and Security Layer  (SASL)
Date: Mon, 18 Jul 2005 19:53:23 -0400
Sender: [email-masked]

Kurt,

Thanks for looking at (and putting up with) this review (I think
I owe you a beer or equivalent).  After looking at your comments,
here's what I would suggest:

--- Unicode ---

IMHO, the draft needs clarity, as SASL's division of Unicode
responsibility is subtle at the very least.  It would be useful
to add an overview of Unicode paragraph or two in the draft
(new Section 3.9?) to explain who is responsible for doing what
Unicode processing, saying at least:

There are two sorts of character data that a SASL mechanism
may need to deal with, the authorization identity string, and any
other character data that the mechanism uses.  Different rules
and responsibilities apply to these two classes of character data.
Character normalization (e.g., stringprep) of the authorization
identity string is the protocol's responsibility.  Character
normalization of any other character data is the SASL mechanism's
responsibility, and the SASL mechanism is also responsible
for all Unicode character encoding.  This split in responsibility
is necessary for compatibility with existing mechanisms and
implementations, but implementation complexity may be reduced when
protocols and the SASL mechanisms they use are designed to use a
single normalization and a single encoding are used for all character
data involved in SASL.

[Note: This structure and division of responsibility strikes me as
less than wonderful, but I read your email as saying that it's
necessary.].

The Unicode encoding requirements are mostly implicit, they should
be explicit.  The following text could be added to the end of item 3)
in Section 5 (for the authorization identity string) and again at
the end of Section 5 for other character data:

  The mechanism MUST specify the Unicode encoding used for
  character data, including authorization identity strings, and
  if more than one encoding is allowed, how the encoding in use
  is determined.  UTF-8 is recommended [note: lower case] in the
  absence of other design considerations.

IMHO, the description of EXTERNAL should contain a sentence saying
that the client is responsible for any Unicode character
normalization of the authorization identity string required by the
protocol that uses the EXTERNAL mechanism.

--- Unknown Authorization Identity ---

The following paragraphs from your comments would be useful
explanatory additions to the draft:

> It is not bad for a server to allow a client to assume an
> authorization identity it has no particular knowledge of.
> What matters is the server knows that the particular
> requested authorization identity is in the set of
> identities the authenticated identity is allowed to assume.
> 
> It is also useful to allow certain identities to assume any
> identity, including ones which are non-existent in any
> system.  The use is to actually test proper function
> and/or configuration of the authorization policy system.

--- Identity Relationships ---

I'll leave the level of requirement that is appropriate here
to the Area Directors' discretion.  I simply wanted to note
the issue, which has been considered important in the past.

Other issues (e.g., "install" vs. "take effect", and whether
to add a forward reference to the discussion of downgrade
attacks) are not significant.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[email-masked]] 
> Sent: Monday, July 18, 2005 6:14 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [(nowhere)] Review: Simple Authentication and 
> Security Layer (SASL)
> 
> From: [email-masked]
> >Ted asked me to review SASL from a non-expert standpoint.
> 
> Thanks for the review.
> 
> >Overall, the draft looks pretty good, and seems reasonable to
> >design protocols from, but I have a couple of serious concerns:
> >
> >- The Unicode stuff isn't quite cooked, but it's "digging
> >in the right place."  Between the possibility of multiple
> >character encodings and the lack of clarity on who (protocol
> >vs. mechanism) is responsible for stringprep (plus the oops
> >of EXTERNAL not mentioning stringprep), I think there may be
> >too much wiggle room here.  
> 
> I'll focus my comments on your detail comments.
> 
> >Here are my detailed comments:
> >
> >Section 3.2's discussion of downgrade attacks could usefully
> >say something about the need for security policy to limit
> >the possible extent of downgrade.  This is covered well in
> >Section 6.1.1, so a forward reference to that would suffice.
> 
> No sure how useful this would actually be.  I suggest someone
> (anyone) who supports addition in this area provide specific
> text for WG consideration.
> 
> >Section 3.4.1 says "Unicode" and leaves the character encoding
> >to the mechanism.  I presume/hope there's a good reason that this
> >is more general than "MUST use UTF-8."  It would be good to add
> >a sentence indicating either that a mechanism which permits more
> >than one character encoding for a string it must have a means for
> >the recipient to determine the encoding or that a mechanism MUST
> >choose a single encoding for a mechanism.  I found the SHOULD
> >for UTF-8 in Section 5, item 3) - repeating it here would be good.
> 
> I personally think repeating statements, especially implementation
> imperatives, is, in general, not a good thing.   I purposely
> tried to avoid use of implementation imperatives in Section 3.
> (The ones in 3.7 were not easily avoidable.)
> 
> >Section 3.6.  In addition to the authorization identity string
> >being malformed, it could designate an authorization identity
> >unknown to the server.  I suppose this falls into the "not
> >authorized to act as the requested authorization identity"
> >category of failures but it would be helpful to point it out,
> >as successfully authenticating to unknown authorization identities
> >can be very bad if that authorization identity actually permits
> >something useful somewhere.
> 
> It is not bad for a server to allow a client to assume an
> authorization identity it has no particular knowledge of.
> What matters is the server knows that the particular
> requested authorization identity is in the set of
> identities the authenticated identity is allowed to assume.
> 
> It is also useful to allow certain identities to assume any
> identity, including ones which are non-existent in any
> system.  The use is to actually test proper function
> and/or configuration of the authorization policy system.
> 
> So, in short, I think it would be bad to say that the
> exchange will fail the requested authorization identity
> is unknown to the server.
> 
> >Sections 3.6 and 3.7.  What does it mean to "install" a security
> >layer?
> 
> It means to insert a new layer into the protocol stack.
> 
> >I presume it means that the protocol session/transport
> >connection carrying SASL starts to use the layer, but "install"
> >is not the verb I would have expected for this.  Later in Section
> >3.7, the phrasing "is in effect" is used, so "take effect" would
> >be a better choice of words.
> 
> I think the word "install" is fine here, and goes well
> with phrases such as "installation of data security layers with
> at least integrity protection."
> 
> >Section 3.8.  Should include the possibility of the protocol
> >closing the connection if a subsequent SASL authentication fails.
> 
> This is not only a possibility on a subsequent SASL authentication
> exchange, its a possible on failed initial SASL authentication.
> In fact, its possible everywhere.  That is, this specification
> does not restrict when a protocol specification may call for
> closure of the protocol session.
> 
> I don't see any real value in adding text in this area,
> especially to section 3.8.
> 
> >Section 4, item 4).  So the protocol specifies authorization
> >string syntax and the mechanism specifies the Unicode character
> >encoding.  That split seems peculiar, making "MUST use UTF-8" more
> >attractive ... I found the "SHOULD" for UTF-8 in Section 5, item 3) .
> 
> For a mechanism in which all other character data was
> transferred as UTF-16 encoded Unicode, it would peculiar
> to require use of UTF-8 encoded Unicode just for this string.
> 
> Anyways, as we're not designing SASL a new, we have to be
> careful not to insert new requirements that will lead to
> breakage.  Such a change would lead to breakage as there
> are existing mechanisms (with multiple implementations)
> that use (or allow) encodings other than UTF-8 here.
> 
> >Section 4, item 4).  Should use of something like stringprep
> >be mandatory (or mandatory for identities that may be user-visible)?
> >The SHOULD for SASLprep is fine,
> 
> I note the WG is considering dropping this SHOULD.  It's
> redundant given the previous sentence.
> 
> >but I'm suggesting backing
> >it with a MUST that says "ignoring this issue is not acceptable".
> 
> The WG is considering text as the second paragraph of this
> item.
>  In order to avoid interoperability problems due to differing
>  normalizations, the protocol specification MUST detail precisely
>  the how and where (client or server) non-empty authorization
>  identity strings are prepared, including all normalizations,
>  for comparison and other applicable functions to ensure
>  proper function.
> 
> 
> >Section 4, item 4).  This "may" level of attention to identity
> >relationships would have earned at least one snide remark from Jeff
> >Schiller.  Sam should look at this, but I think at least a "SHOULD"
> >for doing something about this issue if it occurs is appropriate.
> 
> There are actually two "may"s in this item, neither of
> which are intended to be interpreted in the "MAY" sense.
> I don't it would be appropriate to use a SHOULD in either
> case.
> 
> >Section 5, item 3).  Need to decide whether a mechanism can use
> >more than one Unicode character encoding.  Simplicity suggests
> >not, so the result would be "MUST specify use pf a single Unicode
> >character encoding, which SHOULD be UTF-8."  Need to say something
> >about SASLprep and stringprep here (backpointer to Section 4, item
> >4) would suffice).
> 
> I don't see this specification, nor RFC 2222, disallowing
> mechanisms from allowing a choice of character encodings.
> I don't see simplicity as a good enough reason to disallow
> mechanisms from allowing such a choice, as I think there
> are reasonable cases where such a choice would be reasonable.
> 
> I think it reasonable obvious that the specification doesn't
> restrict mechanisms from having a choice of character
> encodings.  I don't think clarification is required here,
> but if someone wants to offer something for consideration....
> 
> >Section 5, 2nd and 3rd paragraphs from the end.  Here's where some
> >of the requirement to pay attention to Unicode string preparation
> >is hiding.  This text is a bit opaque, and I'm left slightly confused
> >about where the responsibility for stringprep lies between the
> >protocol and the mechanism.  A separate summary section on this
> >might help.
> 
> This section is referring to character data other than
> the authorization identity string.  Some clarification
> in the 3rd to last paragraph may be appropriate.
> 
> >Appendix A.  No mention of stringprep or SASLprep in the EXTERNAL
> >mechanism specification.  Ooops ...
> 
> No mention is needed.  The only string carried in the
> mechanism is an authorization identity string and, as
> detailed in the SASL specification, any normalization
> of the authorization identity string is protocol
> specific not mechanism specific.
> 
> 
> >Enjoy,
> >--David
> >
> >----------------------------------------------------
> >David L. Black, Senior Technologist
> >EMC Corporation, 176 South St., Hopkinton, MA  01748
> >+1 (508) 293-7953             FAX: +1 (508) 293-7786
> >[email-masked]        Mobile: +1 (978) 394-7754
> >----------------------------------------------------
> >
> >> -----Original Message-----
> >> From: Ted Hardie [mailto:[email-masked]] 
> >> Sent: Friday, July 01, 2005 5:37 PM
> >> To: [email-masked]
> >> Subject: RE: [Tom Yu] LAST CALL: Simple Authentication and 
> >> Security Layer (SASL)
> >> 
> >> >Ted,
> >> >
> >> >Sure, next week looks reasonable at this point (famous last 
> >> words ...).
> >> >
> >> >Can you explain a bit more about why you're looking for broader
> >> >review, and the sort of concerns that you'd like SASL non-experts
> >> >such as myself to pay attention to?
> >> >
> >> >Thanks,
> >> >--David
> >> 
> >> First, thanks; you can send the review to me, Sam Hartman, 
> or the wg.
> >> The basic aim in asking some outside folks to review is to 
> check how
> >> well the doc stands alone.  This is one of the cases where there is
> >> a lot of "lore" (in how SASL works and is used), and we'd 
> like to ask
> >> folks who aren't that tapped into the lore to tell us if the 
> >> spec works
> >> if you start with the spec (rather than from an existing 
> >> implementation,
> >> for example).
> >>                       thanks again,
> >>                                       Ted Hardie
> >> 
> >> 
> >> >----------------------------------------------------
> >> >David L. Black, Senior Technologist
> >> >EMC Corporation, 176 South St., Hopkinton, MA  01748
> >> >+1 (508) 293-7953             FAX: +1 (508) 293-7786
> >> >[email-masked]        Mobile: +1 (978) 394-7754
> >> >----------------------------------------------------
> >> >
> >> >> -----Original Message-----
> >> >> From: Ted Hardie [mailto:[email-masked]]
> >> >> Sent: Friday, July 01, 2005 4:47 PM
> >> >> To: [email-masked]
> >> >> Subject: Fwd: [Tom Yu] LAST CALL: Simple Authentication and
> >> >> Security Layer (SASL)
> >> >>
> >> >> Hi David,
> >> >>    We're trying to get a few folks outside of the usual orbit
> >> >> of this group to review the spec.  Is there a chance 
> you'd be able
> >> >> to review it?
> >> >>            regards,
> >> >>                    Ted Hardie
> >> >>
> >> >>
> >> >>
> >> >> >
> >> >> >This begins a Working Group Last Call on submitting 
> the following
> >> >> >document for publication as a Proposed Standard.  The 
> >> Last Call will
> >> >> >expire at 17:00 EDT on July 8, 2005.
> >> >> >
> >> >> >  Title           : Simple Authentication and Security
> >> >> Layer (SASL)
> >> >> >  Author(s)       : A. Melnikov, K. Zeilenga
> >> >> >  Filename        : draft-ietf-sasl-rfc2222bis-11.txt
> >> >> >  Pages           : 29
> >> >> >  Date            : 2005-6-1
> >> >> >  
> >> >> >A URL for this Internet-Draft is:
> >> >> 
> >> 
> >http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-11.txt
> >> >> >
> >> >> >In my opinion, there has not been enough review of this 
> >> document for
> >> >> >me to comfortably declare a WG consensus.  A lack of 
> >> objections WILL
> >> >> >NOT be sufficient grounds for advancing the document.
> >> >> >
> >> >> >If you have read this document and believe that it is ready for
> >> >> >IETF-wide Last Call, please reply indicating so.  
> >> Specific positive
> >> >> >comments are particularly encouraged.
> >> >> >
> >> >> >If you have not read the document, I urge you to do so and
> >> >> to comment,
> >> >> >especially if your work is affected by the SASL
> >> >> specification.  Please
> >> >> >address all technical comments to the list.
> >> >> >
> >> >> >- ---Tom
> >> >>
> >> 
> 

Date: Mon, 18 Jul 2005 12:14:01 +0200
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: [(nowhere)] Review: Simple Authentication and Security Layer  (SASL)
Cc: [email-masked]
Sender: [email-masked]

From: [email-masked]
>Ted asked me to review SASL from a non-expert standpoint.

Thanks for the review.

>Overall, the draft looks pretty good, and seems reasonable to
>design protocols from, but I have a couple of serious concerns:
>
>- The Unicode stuff isn't quite cooked, but it's "digging
>in the right place."  Between the possibility of multiple
>character encodings and the lack of clarity on who (protocol
>vs. mechanism) is responsible for stringprep (plus the oops
>of EXTERNAL not mentioning stringprep), I think there may be
>too much wiggle room here.  

I'll focus my comments on your detail comments.

>Here are my detailed comments:
>
>Section 3.2's discussion of downgrade attacks could usefully
>say something about the need for security policy to limit
>the possible extent of downgrade.  This is covered well in
>Section 6.1.1, so a forward reference to that would suffice.

No sure how useful this would actually be.  I suggest someone
(anyone) who supports addition in this area provide specific
text for WG consideration.

>Section 3.4.1 says "Unicode" and leaves the character encoding
>to the mechanism.  I presume/hope there's a good reason that this
>is more general than "MUST use UTF-8."  It would be good to add
>a sentence indicating either that a mechanism which permits more
>than one character encoding for a string it must have a means for
>the recipient to determine the encoding or that a mechanism MUST
>choose a single encoding for a mechanism.  I found the SHOULD
>for UTF-8 in Section 5, item 3) - repeating it here would be good.

I personally think repeating statements, especially implementation
imperatives, is, in general, not a good thing.   I purposely
tried to avoid use of implementation imperatives in Section 3.
(The ones in 3.7 were not easily avoidable.)

>Section 3.6.  In addition to the authorization identity string
>being malformed, it could designate an authorization identity
>unknown to the server.  I suppose this falls into the "not
>authorized to act as the requested authorization identity"
>category of failures but it would be helpful to point it out,
>as successfully authenticating to unknown authorization identities
>can be very bad if that authorization identity actually permits
>something useful somewhere.

It is not bad for a server to allow a client to assume an
authorization identity it has no particular knowledge of.
What matters is the server knows that the particular
requested authorization identity is in the set of
identities the authenticated identity is allowed to assume.

It is also useful to allow certain identities to assume any
identity, including ones which are non-existent in any
system.  The use is to actually test proper function
and/or configuration of the authorization policy system.

So, in short, I think it would be bad to say that the
exchange will fail the requested authorization identity
is unknown to the server.

>Sections 3.6 and 3.7.  What does it mean to "install" a security
>layer?

It means to insert a new layer into the protocol stack.

>I presume it means that the protocol session/transport
>connection carrying SASL starts to use the layer, but "install"
>is not the verb I would have expected for this.  Later in Section
>3.7, the phrasing "is in effect" is used, so "take effect" would
>be a better choice of words.

I think the word "install" is fine here, and goes well
with phrases such as "installation of data security layers with
at least integrity protection."

>Section 3.8.  Should include the possibility of the protocol
>closing the connection if a subsequent SASL authentication fails.

This is not only a possibility on a subsequent SASL authentication
exchange, its a possible on failed initial SASL authentication.
In fact, its possible everywhere.  That is, this specification
does not restrict when a protocol specification may call for
closure of the protocol session.

I don't see any real value in adding text in this area,
especially to section 3.8.

>Section 4, item 4).  So the protocol specifies authorization
>string syntax and the mechanism specifies the Unicode character
>encoding.  That split seems peculiar, making "MUST use UTF-8" more
>attractive ... I found the "SHOULD" for UTF-8 in Section 5, item 3) .

For a mechanism in which all other character data was
transferred as UTF-16 encoded Unicode, it would peculiar
to require use of UTF-8 encoded Unicode just for this string.

Anyways, as we're not designing SASL a new, we have to be
careful not to insert new requirements that will lead to
breakage.  Such a change would lead to breakage as there
are existing mechanisms (with multiple implementations)
that use (or allow) encodings other than UTF-8 here.

>Section 4, item 4).  Should use of something like stringprep
>be mandatory (or mandatory for identities that may be user-visible)?
>The SHOULD for SASLprep is fine,

I note the WG is considering dropping this SHOULD.  It's
redundant given the previous sentence.

>but I'm suggesting backing
>it with a MUST that says "ignoring this issue is not acceptable".

The WG is considering text as the second paragraph of this
item.
 In order to avoid interoperability problems due to differing
 normalizations, the protocol specification MUST detail precisely
 the how and where (client or server) non-empty authorization
 identity strings are prepared, including all normalizations,
 for comparison and other applicable functions to ensure
 proper function.

>Section 4, item 4).  This "may" level of attention to identity
>relationships would have earned at least one snide remark from Jeff
>Schiller.  Sam should look at this, but I think at least a "SHOULD"
>for doing something about this issue if it occurs is appropriate.

There are actually two "may"s in this item, neither of
which are intended to be interpreted in the "MAY" sense.
I don't it would be appropriate to use a SHOULD in either
case.

>Section 5, item 3).  Need to decide whether a mechanism can use
>more than one Unicode character encoding.  Simplicity suggests
>not, so the result would be "MUST specify use pf a single Unicode
>character encoding, which SHOULD be UTF-8."  Need to say something
>about SASLprep and stringprep here (backpointer to Section 4, item
>4) would suffice).

I don't see this specification, nor RFC 2222, disallowing
mechanisms from allowing a choice of character encodings.
I don't see simplicity as a good enough reason to disallow
mechanisms from allowing such a choice, as I think there
are reasonable cases where such a choice would be reasonable.

I think it reasonable obvious that the specification doesn't
restrict mechanisms from having a choice of character
encodings.  I don't think clarification is required here,
but if someone wants to offer something for consideration....

>Section 5, 2nd and 3rd paragraphs from the end.  Here's where some
>of the requirement to pay attention to Unicode string preparation
>is hiding.  This text is a bit opaque, and I'm left slightly confused
>about where the responsibility for stringprep lies between the
>protocol and the mechanism.  A separate summary section on this
>might help.

This section is referring to character data other than
the authorization identity string.  Some clarification
in the 3rd to last paragraph may be appropriate.

>Appendix A.  No mention of stringprep or SASLprep in the EXTERNAL
>mechanism specification.  Ooops ...

No mention is needed.  The only string carried in the
mechanism is an authorization identity string and, as
detailed in the SASL specification, any normalization
of the authorization identity string is protocol
specific not mechanism specific.

>Enjoy,
>--David
>
>----------------------------------------------------
>David L. Black, Senior Technologist
>EMC Corporation, 176 South St., Hopkinton, MA  01748
>+1 (508) 293-7953             FAX: +1 (508) 293-7786
>[email-masked]        Mobile: +1 (978) 394-7754
>----------------------------------------------------
>
>> -----Original Message-----
>> From: Ted Hardie [mailto:[email-masked]] 
>> Sent: Friday, July 01, 2005 5:37 PM
>> To: [email-masked]
>> Subject: RE: [Tom Yu] LAST CALL: Simple Authentication and 
>> Security Layer (SASL)
>> 
>> >Ted,
>> >
>> >Sure, next week looks reasonable at this point (famous last 
>> words ...).
>> >
>> >Can you explain a bit more about why you're looking for broader
>> >review, and the sort of concerns that you'd like SASL non-experts
>> >such as myself to pay attention to?
>> >
>> >Thanks,
>> >--David
>> 
>> First, thanks; you can send the review to me, Sam Hartman, or the wg.
>> The basic aim in asking some outside folks to review is to check how
>> well the doc stands alone.  This is one of the cases where there is
>> a lot of "lore" (in how SASL works and is used), and we'd like to ask
>> folks who aren't that tapped into the lore to tell us if the 
>> spec works
>> if you start with the spec (rather than from an existing 
>> implementation,
>> for example).
>>                       thanks again,
>>                                       Ted Hardie
>> 
>> 
>> >----------------------------------------------------
>> >David L. Black, Senior Technologist
>> >EMC Corporation, 176 South St., Hopkinton, MA  01748
>> >+1 (508) 293-7953             FAX: +1 (508) 293-7786
>> >[email-masked]        Mobile: +1 (978) 394-7754
>> >----------------------------------------------------
>> >
>> >> -----Original Message-----
>> >> From: Ted Hardie [mailto:[email-masked]]
>> >> Sent: Friday, July 01, 2005 4:47 PM
>> >> To: [email-masked]
>> >> Subject: Fwd: [Tom Yu] LAST CALL: Simple Authentication and
>> >> Security Layer (SASL)
>> >>
>> >> Hi David,
>> >>    We're trying to get a few folks outside of the usual orbit
>> >> of this group to review the spec.  Is there a chance you'd be able
>> >> to review it?
>> >>            regards,
>> >>                    Ted Hardie
>> >>
>> >>
>> >>
>> >> >
>> >> >This begins a Working Group Last Call on submitting the following
>> >> >document for publication as a Proposed Standard.  The 
>> Last Call will
>> >> >expire at 17:00 EDT on July 8, 2005.
>> >> >
>> >> >  Title           : Simple Authentication and Security
>> >> Layer (SASL)
>> >> >  Author(s)       : A. Melnikov, K. Zeilenga
>> >> >  Filename        : draft-ietf-sasl-rfc2222bis-11.txt
>> >> >  Pages           : 29
>> >> >  Date            : 2005-6-1
>> >> >  
>> >> >A URL for this Internet-Draft is:
>> >> 
>> >http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-11.txt
>> >> >
>> >> >In my opinion, there has not been enough review of this 
>> document for
>> >> >me to comfortably declare a WG consensus.  A lack of 
>> objections WILL
>> >> >NOT be sufficient grounds for advancing the document.
>> >> >
>> >> >If you have read this document and believe that it is ready for
>> >> >IETF-wide Last Call, please reply indicating so.  
>> Specific positive
>> >> >comments are particularly encouraged.
>> >> >
>> >> >If you have not read the document, I urge you to do so and
>> >> to comment,
>> >> >especially if your work is affected by the SASL
>> >> specification.  Please
>> >> >address all technical comments to the list.
>> >> >
>> >> >- ---Tom
>> >>
>> 

From: Simon Josefsson <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
Subject: Re: LAST CALL: Simple Authentication and Security Layer (SASL)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 14 Jul 2005 21:55:44 +0200
Sender: [email-masked]

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

> At 06:21 AM 6/24/2005, Simon Josefsson wrote:
>
>>Hello all,
>>
>>In general, I think the document is pretty good.  It could use a
>>re-read, to fix editorial flaws.  I only reviewed my pet problem-area
>>of SASLprep below.
>>
>>Section 4, Protocol Requirements:
>>
>>     Specifications are encouraged to prescribe use of existing
>>     authorization identity forms as well as existing string
>>     representations, such as simple user names [RFC4013].  Protocols
>>     whose authorization identities are simple user names SHOULD use of
>>     SASLprep [RFC4013] (a profile of the StringPrep [RFC3454]
>>     preparation algorithm) as their preparation algorithm.
>>
>>The intention of the requirement appear unclear to me.  For example,
>>take IMAP or SMTP authentication, with simple username+password.  Is
>>the intention that the transferred authorization identity should be in
>>SASLprep:ed form?  If so, I believe it is better to preserve as much
>>as possible of what the user typed as long as possible.  Having the
>>client apply SASLprep to the authorization identity would violate
>>that.
>>
>>On the other hand, requiring the server to apply SASLprep may be too
>>expensive.  There are resource-starvation issues to consider here.
>>Customers are asking for optimized versions of my StringPrep
>>implementation to be able to use it in a server.
>>If the above requirement is going to be present, I believe it should
>>either be clear on what is intended, or acknowledge that it is meant
>>to be fuzzy and that is leaves things open.  To me, I get the
>>impression that it is meant to be fuzzy.
>
> The recommendation was intended only to encourage use of
> SASLprep.  The wording purposely avoids details such as
> whether the SASLprep, if applied, would be applied by the
> client before transfer of the authzid or by the server
> upon receipt.  That detail is left to protocol specifications.

Good, I think that is preferable.

> I note that I support dropping the second sentence of the
> above quoted passage.  It seems redundant with the first
> which already references SASLprep.

I support that too.  It is redundant, and the SHOULD isn't technically
enforceable or verifiable.

>>Adopting parts of the
>>following paragraph, from Mechanism Requirements, would acknowledge
>>that the fuzziness is intended, and that protocol specifications must
>>clarify the details.  What do you think?
>>
>>  In order to avoid interoperability problems due to differing
>>  normalizations, when a mechanism calls for character data is to be
>>  used as input to a cryptographic and/or comparison function, the
>>  specification MUST detail precisely how and where (client or server)
>>  the character data is to be prepared, including all normalizations,
>>  for input into the function to ensure proper operation.
>>
>>Also, there is a typo, s/SHOULD use of/SHOULD use/.
>
> I wouldn't have a problem adding something like:
>   In order to avoid interoperability problems due to differing
>   normalizations, the protocol specification MUST detail precisely
>   the how and where (client or server) non-\empty authorization 
    ---
>   identity strings are prepared, including all normalizations,
>   for comparison and other applicable functions to ensure
>   proper function.
>
> as the second paragraph of 4(4).

I like it, and believe it would help protocol profile authors.

>>Section 5, Mechanism Requirements:
>>
>>  The mechanism SHOULD NOT use the authorization identity string in
>>  generation of any long-term cryptographic keys or hashes as there is
>>  no requirement that the authorization identity string be be
>>  non-canonical.
>>
>>I might be picking words here, but 'non-canonical'?  Shouldn't that be
>>'canonical'?
>
> Yes.
>
>>Even so, if I understand correctly, what is intended is
>>that one user may have different authorization identities in different
>>protocols,
>
> No.  Note that document is talking about the authorization identity
> STRING of a particular not being canonical.  That is, two different
> authorization identity strings in a particular protocol may represent
> the same identity.  For instance, [email-masked] and [email-masked]
> both may represent the same simple user name.   Using either in a
> long-term key/hash would be problematic.
>
>>and that is why mechanisms shouldn't use the authorization
>>identities as input to hash functions etc.  If so, I don't think
>>"canonical" is a good word here, since one protocol's authzid is as
>>good as another protocol's authzid.  There is no "canonical" authzid
>>to speak of.
>
> Of course.  This warning was more to the point that there
> can be more than one valid string in a particular protocol
> that represent the same authorization identity.

Ok, all agreed.  I found the use of SHOULD NOT a bit odd in guidance
text like that, but see no real problem with the paragraph as a whole
now.

Thanks,
Simon

To: [email-masked]
Cc: [email-masked]
Subject: [(nowhere)] Review: Simple Authentication and Security Layer  (SASL)
From: Sam Hartman <[email-masked]>
Date: Mon, 11 Jul 2005 15:08:48 -0400
Sender: [email-masked]

--=-=-=

David is not on the list, plese cc him on comments

--=-=-=
Content-Type: message/rfc822
Content-Disposition: inline

From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Review: Simple Authentication and Security Layer  (SASL)
Date: Fri, 8 Jul 2005 22:07:04 -0400 

Ted asked me to review SASL from a non-expert standpoint.
Overall, the draft looks pretty good, and seems reasonable to
design protocols from, but I have a couple of serious concerns:

- The Unicode stuff isn't quite cooked, but it's "digging
in the right place."  Between the possibility of multiple
character encodings and the lack of clarity on who (protocol
vs. mechanism) is responsible for stringprep (plus the oops
of EXTERNAL not mentioning stringprep), I think there may be
too much wiggle room here.  

Here are my detailed comments:

Section 3.2's discussion of downgrade attacks could usefully
say something about the need for security policy to limit
the possible extent of downgrade.  This is covered well in
Section 6.1.1, so a forward reference to that would suffice.

Section 3.4.1 says "Unicode" and leaves the character encoding
to the mechanism.  I presume/hope there's a good reason that this
is more general than "MUST use UTF-8."  It would be good to add
a sentence indicating either that a mechanism which permits more
than one character encoding for a string it must have a means for
the recipient to determine the encoding or that a mechanism MUST
choose a single encoding for a mechanism.  I found the SHOULD
for UTF-8 in Section 5, item 3) - repeating it here would be good.

Section 3.6.  In addition to the authorization identity string
being malformed, it could designate an authorization identity
unknown to the server.  I suppose this falls into the "not
authorized to act as the requested authorization identity"
category of failures but it would be helpful to point it out,
as successfully authenticating to unknown authorization identities
can be very bad if that authorization identity actually permits
something useful somewhere.

Sections 3.6 and 3.7.  What does it mean to "install" a security
layer?  I presume it means that the protocol session/transport
connection carrying SASL starts to use the layer, but "install"
is not the verb I would have expected for this.  Later in Section
3.7, the phrasing "is in effect" is used, so "take effect" would
be a better choice of words.

Section 3.8.  Should include the possibility of the protocol
closing the connection if a subsequent SASL authentication fails.

Section 4, item 4).  So the protocol specifies authorization
string syntax and the mechanism specifies the Unicode character
encoding.  That split seems peculiar, making "MUST use UTF-8" more
attractive ... I found the "SHOULD" for UTF-8 in Section 5, item 3) .

Section 4, item 4).  Should use of something like stringprep
be mandatory (or mandatory for identities that may be user-visible)?
The SHOULD for SASLprep is fine, but I'm suggesting backing
it with a MUST that says "ignoring this issue is not acceptable".

Section 4, item 4).  This "may" level of attention to identity
relationships would have earned at least one snide remark from Jeff
Schiller.  Sam should look at this, but I think at least a "SHOULD"
for doing something about this issue if it occurs is appropriate.

Section 5, item 3).  Need to decide whether a mechanism can use
more than one Unicode character encoding.  Simplicity suggests
not, so the result would be "MUST specify use pf a single Unicode
character encoding, which SHOULD be UTF-8."  Need to say something
about SASLprep and stringprep here (backpointer to Section 4, item
4) would suffice).

Section 5, 2nd and 3rd paragraphs from the end.  Here's where some
of the requirement to pay attention to Unicode string preparation
is hiding.  This text is a bit opaque, and I'm left slightly confused
about where the responsibility for stringprep lies between the
protocol and the mechanism.  A separate summary section on this
might help.

Appendix A.  No mention of stringprep or SASLprep in the EXTERNAL
mechanism specification.  Ooops ...

Enjoy,
--David

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Ted Hardie [mailto:[email-masked]] 
> Sent: Friday, July 01, 2005 5:37 PM
> To: [email-masked]
> Subject: RE: [Tom Yu] LAST CALL: Simple Authentication and 
> Security Layer (SASL)
> 
> >Ted,
> >
> >Sure, next week looks reasonable at this point (famous last 
> words ...).
> >
> >Can you explain a bit more about why you're looking for broader
> >review, and the sort of concerns that you'd like SASL non-experts
> >such as myself to pay attention to?
> >
> >Thanks,
> >--David
> 
> First, thanks; you can send the review to me, Sam Hartman, or the wg.
> The basic aim in asking some outside folks to review is to check how
> well the doc stands alone.  This is one of the cases where there is
> a lot of "lore" (in how SASL works and is used), and we'd like to ask
> folks who aren't that tapped into the lore to tell us if the 
> spec works
> if you start with the spec (rather than from an existing 
> implementation,
> for example).
> 			thanks again,
> 					Ted Hardie
> 
> 
> >----------------------------------------------------
> >David L. Black, Senior Technologist
> >EMC Corporation, 176 South St., Hopkinton, MA  01748
> >+1 (508) 293-7953             FAX: +1 (508) 293-7786
> >[email-masked]        Mobile: +1 (978) 394-7754
> >----------------------------------------------------
> >
> >> -----Original Message-----
> >> From: Ted Hardie [mailto:[email-masked]]
> >> Sent: Friday, July 01, 2005 4:47 PM
> >> To: [email-masked]
> >> Subject: Fwd: [Tom Yu] LAST CALL: Simple Authentication and
> >> Security Layer (SASL)
> >>
> >> Hi David,
> >>	We're trying to get a few folks outside of the usual orbit
> >> of this group to review the spec.  Is there a chance you'd be able
> >> to review it?
> >>		regards,
> >>			Ted Hardie
> >>
> >>
> >>
> >> >
> >> >This begins a Working Group Last Call on submitting the following
> >> >document for publication as a Proposed Standard.  The 
> Last Call will
> >> >expire at 17:00 EDT on July 8, 2005.
> >> >
> >> >	Title		: Simple Authentication and Security
> >> Layer (SASL)
> >> >	Author(s)	: A. Melnikov, K. Zeilenga
> >> >	Filename	: draft-ietf-sasl-rfc2222bis-11.txt
> >> >	Pages		: 29
> >> >	Date		: 2005-6-1
> >> >	
> >> >A URL for this Internet-Draft is:
> >> 
> >http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-11.txt
> >> >
> >> >In my opinion, there has not been enough review of this 
> document for
> >> >me to comfortably declare a WG consensus.  A lack of 
> objections WILL
> >> >NOT be sufficient grounds for advancing the document.
> >> >
> >> >If you have read this document and believe that it is ready for
> >> >IETF-wide Last Call, please reply indicating so.  
> Specific positive
> >> >comments are particularly encouraged.
> >> >
> >> >If you have not read the document, I urge you to do so and
> >> to comment,
> >> >especially if your work is affected by the SASL
> >> specification.  Please
> >> >address all technical comments to the list.
> >> >
> >> >- ---Tom
> >>
> 

--=-=-=--

Date: Mon, 11 Jul 2005 16:43:32 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>, Jeffrey Hutzelman <[email-masked]>
cc: [email-masked]
Subject: Re: A review of SASL base
Sender: [email-masked]

Again responding two-in-one..

On Sun, 10 Jul 2005, Kurt D. Zeilenga wrote:
> At 07:19 AM 7/10/2005, Pekka Savola wrote:
>> As you see, the first issue is document's self-consistency.
>
> And the next issue is consistency with RFC 2222.
[...]

OK, I didn't catch the context of GSSAPI discussion.

If nobody implements sending stuff on the failure (how do you know 
about this as all the specs aren't public? :) and you don't think it's 
a necessary mechanism, then by all means, I have no objections to 
forbidding it.

>>> [Jeffrey]
>>> The intent of this text is to suggest that whatever means a protocol
>>> provides to discover the set of supported mechanisms should continue
>>> to be available after authentication, so that a client can fetch the
>>> list again and verify that it hasn't been subjected to a downgrade
>>> attack by an attacker modifying the original, unauthenticated list.
>>
>> Right.  My comment was actually more meant to question how the client
>> can authenticate securely, and sufficiently strongly.  If the client
>> wouldn't authenticate the server, and the initial (downgraded)
>> authentication was something like a plain password, a MITM attacker
>> could also forge the "secured" list of authentication methods, and
>> downgrade attack would not be detected.
>
> The paragraph like could be rewritten to reflect that
> not all authentication exchanges result in data security
> layers being installed.
>
>  To detect downgrade attacks, a protocol may allow the client to
>  discover available mechanism subsequent to the authentication
>  exchange and installation of data security layers with at least
>  integrity protection.  This allows the client to detect changes to
>  the list of mechanisms supported by the server.
>
> [Jeffrey]
>Yes, that's true.  You can only detect a downgrade if the weakest
>mechanism you are willing to support still provides strong enough
>integrity protection.  And yes, it's possible to run SASL in the clear
>using a weak mechanism like PLAIN that provides no such protection.  I
>wouldn't recommend it, but...
>
>Do you think we need more verbiage on this issue?

I think Jeffrey mentioned a key point here, that the weakest mechanism 
you're willing to support still needs to provide sufficiently strong 
integrity protection [and authentication, so that you're integrity 
protecting the right peer], which at least should be spelled out 
explicitly.

>> Would it be appropriate to add something like "If the installation of
>> the security layer fails, the connection must be closed as described
>> in Section 3.7" here?  (Or if this is too much duplication, just a
>> shorter pointer on security layer (installation failures) pointing to
>> 3.7).  This would sufficiently clarify the case I was concerned about.
>
> I prefer adding "(See Section 3.7)" to the end of first sentence
> this Section 3 paragraph and add any discussion of "failure to
> install a security layer" (or "unwilling or unable to continue
> with the security layer") in Section 3.7.

Works for me.

>> 1) An IANA registered 'GSSAPI/Kerberos/SASL service name', using the
>>     process as described in Section 4.1 of [RFC2743].
>
>[Jeffrey]
>Except that's not what the registry is called.  I think the current
>description is better, except that the reference needs to be more 
>precise.
>How about this:
>
>     1) A service name, to be selected from the IANA registry of "service"
>     elements for the GSSAPI host-based service name form, as described
>     in Section 4.1 of [RFC2743].  Note that this registry is shared by
>     all GSSAPI and SASL mechanisms.

The name I used was from the title of 
http://www.iana.org/assignments/gssapi-service-names, so if it's 
right, it should be fixed.

But either way, either approach is fine with me.

>> Yes, that would help.  I don't care much one way or the other whether
>> this doc specifies the policy or not, but as it is, the policy is not
>> clear enough.
>>
>> Therefore I'd suggest that in addition to adding a pointer to sect
>> 4.1, this doc would instruct IANA to beef up the IANA service name
>> page to describe the allocation policy or at least give a specific
>> pointer to the latest policy.
>
> We can simply ask IANA now (in a simple email message)
> to update http://www.iana.org/assignments/gssapi-service-names
> with a reference to 4.1 of RFC 2743.  There is no need to
> formalize this request in this document.  I'll coordinate
> the email text with the relevant WG chairs/ADs.

Fine with me..

>>>>> 7) Whether or not you are vulnerable to MITM attacks seems to
>>>>> depend on the challenge/response methods used, so the below text
>>>>> seems to be assumptive.
>
> As I now read the first paragraph of 6.1.1, I do find the
> text to be confused (then, again, its quite early and my
> brain is not yet fully functional).
>
> When the client selects a security layer with at least integrity
> protection, this protects against an active attacker hijacking the
> connection and modifying the authentication exchange to negotiate
> a plain-text connection.
>
> If "security layer" here refers to a SASL security layer, then
> it clearly doesn't protect against modification of the authentication
> exchange.  It protects against modification of application
> protocol data sent after the exchange.  It should read
>        "... and modifying application data sent after the
>        authentication exchange."

That does clarify, though I'm still unsure whether the point gets 
spelled out clearly enough, below..

>>> [Jeffrey]
>>> The text assumes that mechanisms which provide a security
>>> layer with integrity protection will bind that channel to the
>>> authentication used.
>>
>> I'm not sure if I understand this comment, maybe I don't understand
>> the model well enough.  The usefulness of integrity protection depends
>> on authentication (because if you protect the integrity of the
>> messages to the man-in-the-middle attacker, and the MITM guy modifies
>> the messages and sends them to you, purporting to be the server, it
>> won't help much).  And if the authentication is too weak, integrity
>> protection doesn't seem to help, which was my point?
>
> I think the point of the paragraph is note that items not
> protected by integrity protective services should be considered
> suspect.

.. and IMHO, if you don't have sufficiently strong authentication when 
creating integrity protection, the integrity protection is also 
suspect.  The mere existence of integrity protection doesn't really 
help that much, and I suspect if a MITM attack were to happen, it 
would target the integrity protection.

>>>>> 8) shouldn't there be some recommendations how to avoid the most important
>>>>> passive attacks?
>>>
>>> [Jeffrey]
>>> You mean, other than not using those mechanisms, or using
>>> SASL-over-TLS as suggested in the first paragraph on page 18?  Does
>>> that text need to be expanded a bit?
>>>
>>> [Kurt]
>>> If there are general, mechanism-neutral recommendations that
>>> are supported by consensus, yes.  I am open to expanding
>>> this section.
>>
>> Well, let's just say that as written, this part of the security
>> considerations seems to say, "yes, [a couple of vulnerabilities]
>> exist",
>
> s/exist/may exist in these separately specified mechanisms/
>
>> which, looking back at typicaly IESG evaluations, hasn't been
>> considered exactly sufficient ;-).. even for non-security area WGs :)
>
> The presumption is that the separate specifications will detail
> their issues.  We're just noting here that one should not assume
> all SASL mechanisms (adequately) protect against passive attacks.
>
> We could add something like:
>        Each specification for mechanisms of interest
>        should be consulted for details.
>
> if you like.  But this applies not only here, but to every
> mechanism level issue.  That's why we later say:
>
>  Protocol designers and implementors should understand the security
>  considerations of mechanisms so they may select mechanisms which
>  are applicable to their needs.
>
> [Jeffrey]
>Well, yes, it says there are some mechanisms that are vulnerable in 
>that way.  There are also mechansims that are not.  You avoid the 
>vulnerability by not using the mechansims that have it.
>
>Alternately, you can run the whole thing over TLS, which is a fairly 
>common technique and is even secure if you bother to validate the 
>server's certificate and verify its identity (and against a passive 
>attacker, it's effective even if you don't).  This is already 
>mentioned in an earlier section, but perhaps it bears repeating 
>and/or discussion in more detail.
>
>> What I was looking for is at least some guidance or pointers how to
>> avoid these vulnerabilities.
>
> The guidance is to read the mechanism specification of interest.

But how do the people designing a mechanism [specification] figure out 
these things?  As this is a framework document, I was expecting that 
this doc might give a bit more guidance to the mechanism, protocol, 
etc. designers as well how to do it "properly" or what are the major 
tradeoffs to consider.

>>>>> 9) I don't know the precedent, but I'm not sure if it's appropriate to
>>>>> include the URLs or addresses in an RFC.
>>
>> Your assumption is that when the IANA would get a registration request
>> with the old template (and would somehow be able to detect that an old
>> template was being used, if the changes are subtle), IANA would bounce
>> it back to the author, adding a roundtrip and dependency on IANA to
>> look at the requests carefully.
>
> No, my assumption is that if IANA is unable to act on a
> registration request it would take an appropriate action,
> such as advising the submitter that it lacks some crucial
> piece of information.
>
> I assume that IANA will not reject registration request
> simply because the wrong template was used.  It been my
> experience that IANA is pretty flexible.  It is, after all,
> only a template and the statement it be used only guidance.
>
>> To me it seems pretty clear that the users should be instructed to go
>> to the IANA website to find the latest procedures.
>
> I disagree.  Users of this technical specification should read
> this technical specification for the latest procedures.  (Note
> here that I didn't say 'document'.  The user is use the
> RFC Editor pages to find the particular document(s) containing
> the latest technical specification.)
>
> This is not to say that I think having IANA provide a reference
> in the registries to the latest procedures is a bad thing.  In
> fact, I think that would be a good thing.
>
> [Jeffrey]
>Mechanism designers, or indeed anyone wishing to make a registration 
>in an IANA registry, should go look at the IANA site to find a list 
>of existing values as well as information on registration policy and 
>the procedures to be used to register new values.  In the case of 
>SASL mechanism names, the registry currently points to the 
>"Registration procedures" section of RFC2222 for procedures; I assume 
>this will be updated when RFC2222bis is published.  For policy, it 
>says only "(?)", because RFC2222 doesn't set one.
>
>I think the question of whether the IANA page includes a copy of the 
>latest template or a pointer to it is an operational issue for IANA, 
>and not a proper subject for this document.  In either case, the 
>document needs to include the template, because at a minimum, it has 
>to tell the IANA what the template _is_.

OK.  Even if I have a philosophically different opinion, I think 
Jeffrey's argument is persuasive enough.  As long as the IANA web 
pages sufficiently clearly point to the latest spec, this approach 
should be OK.

>>>>> 7.1.2.  Comments on SASL Mechanism Registrations
>>>>>
>>>>>  Comments on registered SASL mechanisms should first be sent to the
>>>>>  "owner" of the mechanism and/or to the SASL WG mailing list.
>>>>>
>>>>>  Submitters of comments may, after a reasonable attempt to contact the
>>>>>  owner, request IANA to attach their comment to the SASL mechanism
>>>>>  registration itself by sending mail to <[email-masked]>.  At IANA sole
>>>>>  discretion, IANA may attach the comment to the registration SASL
>>>>>  mechanism.
>>>>>
>>>>> 10) The use of passive voice conceals who is allowed to change the status
>>>>> of a mechanism.  Obviously the owner.  I guess the IESG can also do that for
>>>>> any mechanism?
>>> [Jeffrey]
>>>
>>> You appear to be speaking specifically to the text about declaring a
>>> mechansim "OBSOLETE", since I can't find anything else that's at all
>>> unclear.  Lacking any text to the contrary, I would expect this
>>> change to fall under the same rules as any other, as defined earlier
>>> in the same section.  Namely, only the owner may make changes, except
>>> that the IESG can change an owner.
>>
>> Yes, obsoleting was the thing that struck my eye, it should be spelled
>> out explicitly.
>
> Personally, I think the current text is sufficiently clear.
> But if anyone has specific text they feel is more clear,
> now would be a good time to offer it for WG consideration.

Well, maybe replace:

   SASL mechanism registrations may not be deleted; mechanisms which are
   no longer believed appropriate for use can be declared OBSOLETE by a
   change to their "intended usage" field; such SASL mechanisms will be
   clearly marked in the lists published by IANA.

with:

   SASL mechanism registrations must not be deleted; if a mechanism is
   no longer believed appropriate for use, the owner can declare it
   OBSOLETE by a change to their "intended usage" field; such SASL
   mechanisms will be clearly marked in the lists published by IANA.

(also "may" -> "must").

btw, I noticed that SKEY is already OBSOLETE at the IANA pages, but 
the draft requests:

   1) Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism
   registrations to OBSOLETE.

>>> [Kurt>
>>> Only the owner.  Of course, IESG may assume or assign
>>> ownership in order to facility such a change.
>>>
>>>> Can anyone else change another people's markings?  What's the
>>>>> RFC2434 requirement?  IETF consensus?  IESG Approval?
>>>
>>> The change request follows the same procedure as the registration request.
>>
>> It seems a bit strange to me that if the IETF had a consensus about
>> the Usage status of a mechanism the IESG could not instruct the IANA
>> to change the status to something else, but would have to change the
>> owner first.
>
> I don't think its strange at all.  The IETF should assume
> ownership of registrations it changes.  To leave the ownership
> as is implies that the owner agrees with the change, which
> might not be the case.  But more importantly, to prevent
> the owner from reverting the change, the IETF must take ownership.

OK, this argument seems convincing enough.

>>>>> 12) are these changes with respect to RFC 2222 backward-compatible?
>>
>> First, it seems that there are two issues:
>>  1) transition issues in the SASL framework.  If you implement some of
>> this stuff in a library, you may face these issues when you upgrade
>> the library to 2222bis
>>  2) transition issues in the protocols, mechanisms, etc. See below.
>>
>> While the transition issues in the mechanisms etc. are likely going to
>> be uncovered when the mechanism is revised (or updated to work with
>> the new framework, see 1), there could be issues which are common to
>> every mechanism.  Therefore completely punting dealing with transition
>> issues to the specifications implementing the framework doesn't seems
>> a bit questionable.
>
>[Jeffrey]
>
>I don't believe there are any wire-level or semantic 
>incompatibilities. There might be transition issues with API changes, 
>but that's entirely an implementation issue.  I can't think what 
>transition issues there might be that aren't either 
>implementation-dependent or specific to a particular mechanism or 
>application protocol.  If you can, then by all means, let's discuss 
>them.

OK, I don't have the technical expertise to evaluate this.  If the WG 
thinks there are no issues, IMHO it would be appropriate to insert "It 
is believed that there should be no incompatibilities with the RFC2222 
and RFCXXXX SASL frameworks" (or something better worded).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Date: Sun, 10 Jul 2005 23:20:49 -0700
From: Rob Siemborski <[email-masked]>
Reply-To: Rob Siemborski <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: returning data on failure (was: A review of SASL base)
Cc: Jeffrey Hutzelman <[email-masked]>, Pekka Savola <[email-masked]>, [email-masked]
Sender: [email-masked]

On 7/10/05, Kurt D. Zeilenga <[email-masked]> wrote:
> I don't see the mechanism specific information being so useful
> as to be worth an extra roundtrip.   Do we really think mechanism
> designers are going to code their mechanisms so as to require
> an extra roundtrip on failure in protocols (e.g., including
> all existing SASL-aware protocols) that don't support this feature?

I suspect what we would see is, at best, is a mismash of
implementations that do different things when a mechanism returns
failure halfway through.

I can't imagine this is useful in the real world.  Certainly, since it
would atleast require designing a new mechanism to make use of it
anyway, I would hate to see it hold up 2222bis.

-Rob

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

Date: Sun, 10 Jul 2005 15:47:54 -0700
To: Jeffrey Hutzelman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: returning data on failure (was: A review of SASL base)
Cc: Pekka Savola <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I not sure why SASL was specified not to allow mechanism
specific data in a failure message.  Maybe it was to avoid
having both application and mechanism specific error
reporting, maybe it was because it viewed better to have
the server map the mechanism specific error information
into (existing) protocol specific fields (note that SASL
was designed to augment authentication facilities in
existing protocols), maybe because the designers thought
there should be little difference between a mid-exchange
abort and an end-of-exchange failed outcome message, or
maybe because exchanges can fail (or be aborted) for reasons
outside of the mechanism, or some other reason.
But I don't think it matters much what the reason was.

At 12:38 PM 7/10/2005, Jeffrey Hutzelman wrote:
>IMHO this is all about whether RFC2222 allows existing application
>protocols to assume that failure will not include additional data.  If
>not, then yes, absolutely we should allow it.

I cannot see adding a feature for which there exists no
implementation of (which is obviously so since there is
no protocol or mechanism which details additional data
be sent with a failure outcome message).   We're targeting
Draft Standard (after a hopefully short stay at Proposed).
Seems like the wrong time to be adding new features, especially
ones which are not necessary.  (Useful != necessary).

I also cannot see adding new features at this stage of our work.
But maybe because I don't see this merely as dropping a
restriction, but as a new feature that would require significant
engineering.

Personally, I don't see this being all that useful.  Maybe
that's because I am not sure what portion (mechanism,
framework, protocol) of the client implementation is expected
to consume this information (or whether the consumer depends
on the particulars of the mechanism-specific additional
data.  But putting this aside, I doubt that server mechanism
implementor will take advantage of this feature (and hence
doubt that framework implementations will support the feature).
Here's why:

Say a mechanism was designed so that additional data was to
be sent in the failure outcome message.  That mechanism would
have to be designed also to allow sending that additional data
in a final challenge with empty response.   Given a
framework implementation that supports optional additional
data with a failure outcome message and supporting protocol
and protocol implementation, the mechanism implementor can
implement code that avoids the round trip.  But if the
application protocol or protocol implementation doesn't support
this, that code is for not.  And as a mechanism implementation
can always abort the exchange and that always avoid the round trip
(by not sending the data), and its the simple thing to do,
that's what many server mechanism implementations are likely
to do.  The only reason why a server mechanism implementation
would bother supporting this feature is that usefulness of
the information to the client clearly outweighs the expense
of the roundtrip in protocols and their implementations
that don't support this feature.

I don't see the mechanism specific information being so useful
as to be worth an extra roundtrip.   Do we really think mechanism
designers are going to code their mechanisms so as to require
an extra roundtrip on failure in protocols (e.g., including
all existing SASL-aware protocols) that don't support this feature?

Kurt 

Date: Sun, 10 Jul 2005 15:38:04 -0400 (EDT)
From: Jeffrey Hutzelman <[email-masked]>
To: Pekka Savola <[email-masked]>
cc: "Kurt D. Zeilenga" <[email-masked]>, <[email-masked]>
Subject: Re: A review of SASL base
Sender: [email-masked]

On Sun, 10 Jul 2005, Pekka Savola wrote:

> As you see, the first issue is document's self-consistency.  You could
> either forbid or allow this (with potentially disclaimers etc).
> Based on follow-up discussion about GSSAPI, there already seems to be
> a mechanism using it with failure.

Yes, there appears to be a consistency issue here.  I think we need to go
back and see what RFC2222 says about this, and then make a decision as to
what RFC2222bis should say, avoiding breaking backward compatibility if
possible.

Sam's previous comment was talking about what we've seen with GSSAPI as a
framework, not about the SASL mechansim of that name.  He was pointing out
that we've found it useful for GSSAPI mechanisms to be able to pass back
detailed error information which the client can make available to the
application, and that having the same feature in SASL might be useful.  I
agree, but given that the empty-response technique is available to any
mechanism in any application protocol, we should allow additional data
with failure if and only if it won't break any existing applications.

> Looking at this from the external point of view, forbidding it may not
> be the best approach, at least with such strong words as proposed
> above (maybe something like ".. should not include additional data
> when the outcome is a failure" would be closer).

IMHO this is all about whether RFC2222 allows existing application
protocols to assume that failure will not include additional data.  If
not, then yes, absolutely we should allow it.

> >[Jeffrey]
> >The intent of this text is to suggest that whatever means a protocol
> >provides to discover the set of supported mechanisms should continue
> >to be available after authentication, so that a client can fetch the
> >list again and verify that it hasn't been subjected to a downgrade
> >attack by an attacker modifying the original, unauthenticated list.
>
> Right.  My comment was actually more meant to question how the client
> can authenticate securely, and sufficiently strongly.  If the client
> wouldn't authenticate the server, and the initial (downgraded)
> authentication was something like a plain password, a MITM attacker
> could also forge the "secured" list of authentication methods, and
> downgrade attack would not be detected.

Yes, that's true.  You can only detect a downgrade if the weakest
mechanism you are willing to support still provides strong enough
integrity protection.  And yes, it's possible to run SASL in the clear
using a weak mechanism like PLAIN that provides no such protection.  I
wouldn't recommend it, but...

Do you think we need more verbiage on this issue?

> >>> It also isn't clear why you mention (and refer to) GSSAPI here, as
> >>> AFAICS these service names need to be used by any SASL mechanism
> >>> whether it has any relation to GSSAPI or not.
> >>>
> >>>     1) A service name, to be selected from the IANA registry of "service"
> >>>     elements for the GSSAPI host-based service name form [RFC2743].
> >
> > For consistency across all SASL mechanisms which require a
> > service name.
> >
> >[Jeffrey]
> >That's correct, and the same set of service names are to be
> >used for all mechanisms.  SASL reuses the registry previously
> >established for GSSAPI and Kerberos service names, because they serve
> >the same function and because it makes things easier if the same name
> >is used at all three layers.
>
> Maybe the text above could be clerer on this, also with regard to
> point 5) above.  Maybe something like the following:
>
> 1) An IANA registered 'GSSAPI/Kerberos/SASL service name', using the
>     process as described in Section 4.1 of [RFC2743].

Except that's not what the registry is called.  I think the current
description is better, except that the reference needs to be more precise.
How about this:

     1) A service name, to be selected from the IANA registry of "service"
     elements for the GSSAPI host-based service name form, as described
     in Section 4.1 of [RFC2743].  Note that this registry is shared by
     all GSSAPI and SASL mechanisms.

> Therefore I'd suggest that in addition to adding a pointer to sect
> 4.1, this doc would instruct IANA to beef up the IANA service name
> page to describe the allocation policy or at least give a specific
> pointer to the latest policy.

Actually, IANA's table of registries does specifically refer to RFC2743,
section 4.1, which is the current policy.  If you think they should
describe the policy directly instead of via a reference, IMHO that is
something to suggest to [email-masked] or maybe even [email-masked],
not a subject for standards action.

> >>> 7) Whether or not you are vulnerable to MITM attacks seems to
> >>> depend on the challenge/response methods used, so the below text
> >>> seems to be assumptive.

This is too complicated for me to write about at the moment; I'll pick it
up again in a later message.

> >>> 8) shouldn't there be some recommendations how to avoid the most important
> >>> passive attacks?
> >
> >[Jeffrey]
> >You mean, other than not using those mechanisms, or using
> >SASL-over-TLS as suggested in the first paragraph on page 18?  Does
> >that text need to be expanded a bit?
> >
> > [Kurt]
> > If there are general, mechanism-neutral recommendations that
> > are supported by consensus, yes.  I am open to expanding
> > this section.
>
> Well, let's just say that as written, this part of the security
> considerations seems to say, "yes, [a couple of vulnerabilities]
> exist", which, looking back at typicaly IESG evaluations, hasn't been
> considered exactly sufficient ;-).. even for non-security area WGs :).

Well, yes, it says there are some mechanisms that are vulnerable in that
way.  There are also mechansims that are not.  You avoid the vulnerability
by not using the mechansims that have it.

Alternately, you can run the whole thing over TLS, which is a fairly
common technique and is even secure if you bother to validate the server's
certificate and verify its identity (and against a passive attacker, it's
effective even if you don't).  This is already mentioned in an earlier
section, but perhaps it bears repeating and/or discussion in more detail.

> >>> Including the template to be filled here is also suspect;
> >>> would a better approach be advising
> >>> the IANA to include the template at a web page, and suggesting that
> >>> whoever wants to fill it, go to the IANA?
> >
> > No.  An IANA web page is not the definitive statement of
> > the procedures for registration of a value.  This document
> > states what information is to be provided, to whom, and
> > what actions may or may not be taken based upon that
> > information.
> >
> >> That way, if this spec is
> >>> revised in the future and the template changes, the users (who might be
> >>> looking at an old spec) are always pointed to the latest
> >>> version of the template.
> >
> > If the registration procedures need to be changed, the document
> > detailing those procedures should be updated appropriately.
> > IANA should advise anyone using an old template to read
> > the latest definitive statement of the procedures as stated
> > in the latest revision of the SASL technical specification.
>
> Your assumption is that when the IANA would get a registration request
> with the old template (and would somehow be able to detect that an old
> template was being used, if the changes are subtle), IANA would bounce
> it back to the author, adding a roundtrip and dependency on IANA to
> look at the requests carefully.
>
> I don't think that's a good model.  There needs to be a definitive
> statement of procedures (i.e., the latest spec updating the IANA
> registry is normative), yes, but this is a separate issue on where we
> advise the protocol/mechanism designers go looking for the
> registration procedures -- an RFC (the numbers of which could change
> in the future) or a stable IANA website (which can always be pointed
> to refer to the latest specs).

Mechanism designers, or indeed anyone wishing to make a registration in an
IANA registry, should go look at the IANA site to find a list of existing
values as well as information on registration policy and the procedures to
be used to register new values.  In the case of SASL mechanism names, the
registry currently points to the "Registration procedures" section of
RFC2222 for procedures; I assume this will be updated when RFC2222bis is
published.  For policy, it says only "(?)", because RFC2222 doesn't set
one.

I think the question of whether the IANA page includes a copy of the
latest template or a pointer to it is an operational issue for IANA, and
not a proper subject for this document.  In either case, the document
needs to include the template, because at a minimum, it has to tell the
IANA what the template _is_.

> Yes, obsoleting was the thing that struck my eye, it should be spelled
> out explicitly.

How's this?

   SASL mechanism registrations may not be deleted.  If a mechanism is no
   longer believed appropriate for use, its owner may declare it OBSOLETE
   by submitting a change to its "intended usage" field; such mechanisms
   will be clearly marked in the lists published by IANA.

>
> It seems a bit strange to me that if the IETF had a consensus about
> the Usage status of a mechanism the IESG could not instruct the IANA
> to change the status to something else, but would have to change the
> owner first.

They can say "Plase change the owner to me, change the usage to FOO, and
then change the owner back".  Of course, I'd expect they could just say to
change the usage and the IANA would be intelligent enough to allow the
request.

> First, it seems that there are two issues:
>   1) transition issues in the SASL framework.  If you implement some of
> this stuff in a library, you may face these issues when you upgrade
> the library to 2222bis

I don't believe there are any wire-level or semantic incompatibilities.
There might be transition issues with API changes, but that's entirely an
implementation issue.  I can't think what transition issues there might be
that aren't either implementation-dependent or specific to a particular
mechanism or application protocol.  If you can, then by all means, let's
discuss them.

BTW, thanks for reviewing this.

-- Jeff

Date: Sun, 10 Jul 2005 10:21:18 -0700
To: Pekka Savola <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: A review of SASL base
Cc: [email-masked]
Sender: [email-masked]

At 07:19 AM 7/10/2005, Pekka Savola wrote:
>>>> 2) question on applicability of the latter exchange below.
>>
>> See Rob's response.
>
>OK.
>
>>>> I also note that the description in the first exchange implies 
>>>> that sending additional data is allowed only when the 
>>>> authentication is successful,
>>
>> Correct.
>>
>>> but I don't see why piggybacking additional data (if sending it is 
>>> necessary) should be restricted to just the success?
>>
>> There is no need to send additional data with the indication of
>> failure.
>>
>>> Contradicting that, section 3.6 does not specify that additional 
>>> data may only be sent with a success, rather with any outcome.
>>
>> I think 3.6 wording meant that the outcome message format may
>> include a field for this purpose.  It wasn't intended to imply
>> that a non-successful outcome message instance could contain
>> data in this field.
>>
>> Adding:
>>  This field can only include additional
>>  data when the outcome is successful.
>>
>> would, I think, adequately address this issue.
>
>As you see, the first issue is document's self-consistency.

And the next issue is consistency with RFC 2222.

>You could 
>either forbid or allow this (with potentially disclaimers etc). 
>Based on follow-up discussion about GSSAPI, there already seems to be 
>a mechanism using it with failure.

No.  Note that Sam was referring to GSSAPI in general, not specifically
to the SASL GSSAPI mechanism (e.g., the SASL mechanism named "GSSAPI"),
as an example of an authentication technology could provide additional
data both with its indication of success and failure.

>Looking at this from the external point of view, forbidding it may not 
>be the best approach, at least with such strong words as proposed 
>above (maybe something like ".. should not include additional data 
>when the outcome is a failure" would be closer).  As there are some architectural considerations why this shouldn't 
>(typically) be useful or needed, some of this might or might not also 
>be appropriate to put in this draft.

As RFC 2222 clearly did not provide a facility for sending
optional data with a non-successful outcome, we'd have to
add this.  It would be a new feature.  And, charter aside,
new features like this can easily break things.

As Jeffery noted, any mechanism that wanted to provide additional
data upon failure would have to have a final challenge designed to
carry that data and a empty response.  Now, the interesting thing
is, as soon as an server realizes an exchange has failed,
it can (and generally will) abort the exchange.  Hence, the
challenge often won't be sent in all cases unless you mandate
servers complete such exchanges.  That, I think, would be quite
problematic and seems counter to the design of SASL.  In SASL,
reporting of failure is intended to be protocol-specific,
not mechanism-specific.  This facilitates mechanism
upgrade/replacement in clients by not requiring clients to
understand mechanism specific error information.

My point here is, just because the feature might be useful,
doesn't necessarily mean that we should add it. 

>>>> 3) how could the client authenticate prior to knowing which authentication
>>>> mechanism is should use for authentication?  Maybe the following requires
>>>> clarification. (also s/mechanism/mechanisms/ ?)  Are you referring to some predefined
>>>> default authentication method or the use of multiple authentications (sect 3.8)?
>>>>
>>>>  To detect downgrade attacks, a protocol may allow the client to
>>>>  discover available mechanism subsequent to the authentication exchange
>>>>  (and, hence, protected by any data security layer provided by
>>>>  mechanism) so that downgrade attacks can be detected.
>>
>>[Jeffrey]
>>The intent of this text is to suggest that whatever means a protocol 
>>provides to discover the set of supported mechanisms should continue 
>>to be available after authentication, so that a client can fetch the 
>>list again and verify that it hasn't been subjected to a downgrade 
>>attack by an attacker modifying the original, unauthenticated list.
>
>Right.  My comment was actually more meant to question how the client 
>can authenticate securely, and sufficiently strongly.  If the client 
>wouldn't authenticate the server, and the initial (downgraded) 
>authentication was something like a plain password, a MITM attacker 
>could also forge the "secured" list of authentication methods, and 
>downgrade attack would not be detected.

The paragraph like could be rewritten to reflect that
not all authentication exchanges result in data security
layers being installed.

  To detect downgrade attacks, a protocol may allow the client to
  discover available mechanism subsequent to the authentication 
  exchange and installation of data security layers with at least
  integrity protection.  This allows the client to detect changes to 
  the list of mechanisms supported by the server.

>I recall there is some text on the different components being required 
>to specify the minimum acceptable authentication, which may mitigate 
>this slightly, but it's an open question how much this helps in 
>practice.  Referring to this text here would probably help.

>(This issue is probably dependent on the resultion of comment 7.)
>
>>>> 4) below you don't specify what how the framework relates if the authentication
>>>> outcome is successful, but the installation of the security layer fails for
>>>> some reason.  Just to be on the safe side, should you specify or give some guidance
>>>> that either (1) the security layer should be installed or somehow tested prior
>>>> to reporting outcome (and failure would be, .., failure), or (2) if the installation
>>>> of security layer fails for any reason, the session must be aborted using protocol
>>>> specific means.
>>>>
>>>> What I'm worried about is that a sloppy implementation could 
>>>> report a successful outcome but the layer might not be installed 
>>>> due to whatever reasons, and the user would get a false sense of 
>>>> security.  (This seems to be discussed a bit later, in section 
>>>> 3.7)
>>>>
>>>>  If the outcome is successful and a security layer was negotiated, this
>>>>  layer is then installed.  If the outcome is unsuccessful, or a
>>>>  security layer was not negotiated, any existing security is left in
>>>>  place.
>>
>>
>> As implied by Jeffrey's comment, I thinking this would get into
>> implementation details.
>
>Would it be appropriate to add something like "If the installation of 
>the security layer fails, the connection must be closed as described 
>in Section 3.7" here?  (Or if this is too much duplication, just a 
>shorter pointer on security layer (installation failures) pointing to 
>3.7).  This would sufficiently clarify the case I was concerned about.

I prefer adding "(See Section 3.7)" to the end of first sentence
this Section 3 paragraph and add any discussion of "failure to
install a security layer" (or "unwilling or unable to continue
with the security layer") in Section 3.7.

>>>> 5) is it clear enough which registry are you referring to?
>>>> Initially I guessed http://www.iana.org/assignments/service-names, but it turned out to be
>>>> http://www.iana.org/assignments/gssapi-service-names.
>>
>> I think some clarification would be appropriate here.
>
>OK.
>
>>>> It also isn't clear why you mention (and refer to) GSSAPI here, as 
>>>> AFAICS these service names need to be used by any SASL mechanism 
>>>> whether it has any relation to GSSAPI or not.
>>>>
>>>>     1) A service name, to be selected from the IANA registry of "service"
>>>>     elements for the GSSAPI host-based service name form [RFC2743].
>>
>> For consistency across all SASL mechanisms which require a
>> service name.
>>
>>[Jeffrey]
>>That's correct, and the same set of service names are to be 
>>used for all mechanisms.  SASL reuses the registry previously 
>>established for GSSAPI and Kerberos service names, because they serve 
>>the same function and because it makes things easier if the same name 
>>is used at all three layers.
>
>Maybe the text above could be clerer on this, also with regard to 
>point 5) above.  Maybe something like the following:
>
>1) An IANA registered 'GSSAPI/Kerberos/SASL service name', using the
>    process as described in Section 4.1 of [RFC2743].

Okay.

>>>> 6) What is the IANA registration policy for gssapi-service-names?
>>>> The page doesn't tell and the GSSAPI specs don't appear to have
>>>> IANA considerations section.
>>
>> See Section 4.1 of RFC 2743.
>>
>>> Should this doc specify it?
>>
>> IMO, no.  (It might be appropriate for this to be detailed
>> separately from GSSAPI specifications, such as in a BCP, but
>> I don't see this as something we (the SASL WG) needs to address,
>> at least now.)
>>
>>> Should the guidance for protocol designers give advice on this?
>>
>> We can refer specifically to Section 4.1 of RFC 2743 if that
>> helps.
>
>Yes, that would help.  I don't care much one way or the other whether 
>this doc specifies the policy or not, but as it is, the policy is not 
>clear enough.
>
>Therefore I'd suggest that in addition to adding a pointer to sect 
>4.1, this doc would instruct IANA to beef up the IANA service name 
>page to describe the allocation policy or at least give a specific 
>pointer to the latest policy.

We can simply ask IANA now (in a simple email message)
to update http://www.iana.org/assignments/gssapi-service-names
with a reference to 4.1 of RFC 2743.  There is no need to
formalize this request in this document.  I'll coordinate
the email text with the relevant WG chairs/ADs.

>>>> 7) Whether or not you are vulnerable to MITM attacks seems to 
>>>> depend on the challenge/response methods used, so the below text 
>>>> seems to be assumptive.

As I now read the first paragraph of 6.1.1, I do find the
text to be confused (then, again, its quite early and my
brain is not yet fully functional).   

 When the client selects a security layer with at least integrity
 protection, this protects against an active attacker hijacking the
 connection and modifying the authentication exchange to negotiate
 a plain-text connection. 

If "security layer" here refers to a SASL security layer, then
it clearly doesn't protect against modification of the authentication
exchange.  It protects against modification of application
protocol data sent after the exchange.  It should read
        "... and modifying application data sent after the
        authentication exchange."

>>[Jeffrey]
>>The text assumes that mechanisms which provide a security 
>>layer with integrity protection will bind that channel to the 
>>authentication used.
>
>I'm not sure if I understand this comment, maybe I don't understand 
>the model well enough.  The usefulness of integrity protection depends 
>on authentication (because if you protect the integrity of the 
>messages to the man-in-the-middle attacker, and the MITM guy modifies 
>the messages and sends them to you, purporting to be the server, it 
>won't help much).  And if the authentication is too weak, integrity 
>protection doesn't seem to help, which was my point?

I think the point of the paragraph is note that items not
protected by integrity protective services should be considered
suspect.

>>> An attack example is challenge/response where the server doesn't 
>>> authenticate the client, so an attacker which is doing MITM when 
>>> SASL is exchanged can continue to perform MITM after the SASL 
>>> exchange. I guess it's important to distinguish the cases "MITM 
>>> attacker after SASL auth" and "MITM attacker modifying the SASL 
>>> negotiation", as well as look at the security of different 
>>> challenge/response methods provided.
>>>>
>>>> 6.1.1. Man-in-the-middle Attacks
>>>>
>>>>  When the client selects a security layer with at least integrity
>>>>  protection, this protects against an active attacker hijacking the
>>>>  connection and modifying the authentication exchange to negotiate a
>>>>  plain-text connection.  In this case, it is important that any
>>>>  security-sensitive protocol negotiations be performed after
>>>>  authentication is complete.  Protocols should be designed such that
>>>>  negotiations performed prior to authentication should be either
>>>>  ignored or revalidated once authentication is complete.
>>>>
>>>> 7.b) Speaking of which, the document doesn't seem to give any guidance
>>>> (or I missed it) to the protocol designers on which kind of
>>>> challenge responses should be supported and why (see section 3.4),
>>>> particularly the security tradeoffs ?
>>
>>[Jeffrey] No, I don't think the framework gives guidance to 
>>application developers on mechansim selection, and I don't think it 
>>should.  This document is the technical specification of what is 
>>supposed to be a mechanism-independent, applicaiton-agnostic 
>>framework, and as such should not be bound to specific mechansims. 
>>I agree that advice from the security community on selection of SASL 
>>mechansims (and indeed, on choosing between SASL, GSS, EAP, etc) 
>>would be useful, but I don't think it belongs in this document.
>
>>In fact, I think there is some such work underway already, but I'm 
>>not going to spend the time to search for it just now.  Perhaps in a 
>>later followup...
>>
>> [Kurt]
>> I wholeheartedly agree with Jeffrey's comment here.  Such guidance
>> should be provided separately from the technical specification.
>
>I believe such guidance is probably needed, and I guess it's one of 
>the cornerstones of secure SASL usage.  Security considerations should 
>be used to at least bring up this issue, and provide pointers to such 
>work (if already existing).
>
>>>> 8) shouldn't there be some recommendations how to avoid the most important
>>>> passive attacks?
>>
>>[Jeffrey]
>>You mean, other than not using those mechanisms, or using 
>>SASL-over-TLS as suggested in the first paragraph on page 18?  Does 
>>that text need to be expanded a bit?
>>
>> [Kurt]
>> If there are general, mechanism-neutral recommendations that
>> are supported by consensus, yes.  I am open to expanding
>> this section.
>
>Well, let's just say that as written, this part of the security 
>considerations seems to say, "yes, [a couple of vulnerabilities] 
>exist",

s/exist/may exist in these separately specified mechanisms/

>which, looking back at typicaly IESG evaluations, hasn't been 
>considered exactly sufficient ;-).. even for non-security area WGs :)

The presumption is that the separate specifications will detail
their issues.  We're just noting here that one should not assume
all SASL mechanisms (adequately) protect against passive attacks.

We could add something like:
        Each specification for mechanisms of interest
        should be consulted for details.

if you like.  But this applies not only here, but to every
mechanism level issue.  That's why we later say:

  Protocol designers and implementors should understand the security
  considerations of mechanisms so they may select mechanisms which 
  are applicable to their needs.

>What I was looking for is at least some guidance or pointers how to 
>avoid these vulnerabilities.

The guidance is to read the mechanism specification of interest.

>>>> 9) I don't know the precedent, but I'm not sure if it's appropriate to
>>>> include the URLs or addresses in an RFC.
>>
>> I think the inclusion of the URLs in this RFC are appropriate.
>>
>>>> Including the template to be filled here is also suspect;
>>>> would a better approach be advising
>>>> the IANA to include the template at a web page, and suggesting that
>>>> whoever wants to fill it, go to the IANA?
>>
>> No.  An IANA web page is not the definitive statement of
>> the procedures for registration of a value.  This document
>> states what information is to be provided, to whom, and
>> what actions may or may not be taken based upon that
>> information.
>>
>>> That way, if this spec is
>>>> revised in the future and the template changes, the users (who might be
>>>> looking at an old spec) are always pointed to the latest
>>>> version of the template.
>>
>> If the registration procedures need to be changed, the document
>> detailing those procedures should be updated appropriately.
>> IANA should advise anyone using an old template to read
>> the latest definitive statement of the procedures as stated
>> in the latest revision of the SASL technical specification.
>
>Your assumption is that when the IANA would get a registration request 
>with the old template (and would somehow be able to detect that an old 
>template was being used, if the changes are subtle), IANA would bounce 
>it back to the author, adding a roundtrip and dependency on IANA to 
>look at the requests carefully.

No, my assumption is that if IANA is unable to act on a
registration request it would take an appropriate action,
such as advising the submitter that it lacks some crucial
piece of information.

I assume that IANA will not reject registration request
simply because the wrong template was used.  It been my
experience that IANA is pretty flexible.  It is, after all,
only a template and the statement it be used only guidance.

>To me it seems pretty clear that the users should be instructed to go 
>to the IANA website to find the latest procedures.

I disagree.  Users of this technical specification should read
this technical specification for the latest procedures.  (Note
here that I didn't say 'document'.  The user is use the
RFC Editor pages to find the particular document(s) containing
the latest technical specification.)

This is not to say that I think having IANA provide a reference
in the registries to the latest procedures is a bad thing.  In
fact, I think that would be a good thing. 

>>>> 7.1.2.  Comments on SASL Mechanism Registrations
>>>>
>>>>  Comments on registered SASL mechanisms should first be sent to the
>>>>  "owner" of the mechanism and/or to the SASL WG mailing list.
>>>>
>>>>  Submitters of comments may, after a reasonable attempt to contact the
>>>>  owner, request IANA to attach their comment to the SASL mechanism
>>>>  registration itself by sending mail to <[email-masked]>.  At IANA sole
>>>>  discretion, IANA may attach the comment to the registration SASL
>>>>  mechanism.
>>>>
>>>> 10) The use of passive voice conceals who is allowed to change the status
>>>> of a mechanism.  Obviously the owner.  I guess the IESG can also do that for
>>>> any mechanism?
>> [Jeffrey]
>>
>>You appear to be speaking specifically to the text about declaring a 
>>mechansim "OBSOLETE", since I can't find anything else that's at all 
>>unclear.  Lacking any text to the contrary, I would expect this 
>>change to fall under the same rules as any other, as defined earlier 
>>in the same section.  Namely, only the owner may make changes, except 
>>that the IESG can change an owner.
>
>Yes, obsoleting was the thing that struck my eye, it should be spelled 
>out explicitly.

Personally, I think the current text is sufficiently clear.
But if anyone has specific text they feel is more clear,
now would be a good time to offer it for WG consideration.

>> [Kurt>
>> Only the owner.  Of course, IESG may assume or assign
>> ownership in order to facility such a change.
>>
>>> Can anyone else change another people's markings?  What's the
>>>> RFC2434 requirement?  IETF consensus?  IESG Approval?
>>
>> The change request follows the same procedure as the registration request.
>
>It seems a bit strange to me that if the IETF had a consensus about 
>the Usage status of a mechanism the IESG could not instruct the IANA 
>to change the status to something else, but would have to change the 
>owner first.

I don't think its strange at all.  The IETF should assume
ownership of registrations it changes.  To leave the ownership
as is implies that the owner agrees with the change, which
might not be the case.  But more importantly, to prevent
the owner from reverting the change, the IETF must take ownership.

>But I don't think this issue is big enough to warrant prolonged 
>discussion.
>
>>>> 11) normative reference issues (for the future). I think this spec
>>>> is intended to be recycled to Draft Standard after being 6 months at
>>>> PS.
>>
>> That is the hope but might not necessarily be the reality.
>>
>>> Please note that the normative references are at PS, so this spec
>>>> cannot be moved to DS before these also move forward, or some other
>>>> solution is found.
>>
>> or we obtain a variance.  I think we can deal with this
>> when the future arrives.
>
>Well, what I was hoping is that folks try to start campainging moving 
>some of these forward as well now.
>
>>>> 12) are these changes with respect to RFC 2222 backward-compatible?
>>
>> They are believed to be backwards compatible.
>>
>>>> If not, a transition strategy or a bit of warning might be warranted.
>>>> All in all, it might be a good idea to state explicitly whether
>>>> there are cases where 2222bis (due to new requirements for mechanisms, etc.)
>>>> would be incompatible with 2222.
>>
>> [Jeffrey]
>>This is a messy issue, and transition strategies, to the extent that 
>>they are needed, will depend on the specific application protocols 
>>involved.  I don't expect there are deployed applications for which 
>>this will actually matter very much (particularly WRT prohibiting 
>>NUL), but perhaps I am underestimating the scope of the problem.
>>
>> [Kurt]
>> The new requirements are upon mechanism/protocol SPECIFICATIONS, not
>> mechanisms/protocols.  If a mechanism/protocol specification is
>> changed in a way that changes the mechanism/protocol (whether
>> done to fulfill new requirements or not), that specification
>> is responsible to address compatibility issues.
>
>First, it seems that there are two issues:
>  1) transition issues in the SASL framework.  If you implement some of 
>this stuff in a library, you may face these issues when you upgrade 
>the library to 2222bis
>  2) transition issues in the protocols, mechanisms, etc. See below.
>
>While the transition issues in the mechanisms etc. are likely going to 
>be uncovered when the mechanism is revised (or updated to work with 
>the new framework, see 1), there could be issues which are common to 
>every mechanism.  Therefore completely punting dealing with transition 
>issues to the specifications implementing the framework doesn't seems 
>a bit questionable.
>
>>>> editorial
>>>> ---------
>>>>
>>>>  If the outcome is successful and a data layer was negotiated, this
>>>>  layer is then installed.  Protocols may allow this data to be carried
>>>>  in the request message.  This applies as well to the following
>>>>  illustrations.
>>>>
>>>>  Some mechanisms specify that the first data sent in the authentication
>>>>  exchange is from the client to the server.  Protocols may provide an
>>>>  optional initial response field in the request message to carry this
>>>>  data.  Where the mechanism specifies the first data data sent in the
>>>>  exchange is from the client to the server, the protocol provides an
>>>>  optional initial response field, and the client uses this field, the
>>>>  exchange is shortened by one round-trip:
>>>>
>>>>      C: Request authentication exchange + Initial response
>>>>      <additional challenge/response messages>
>>>>      S: Outcome of authentication exchange
>>>>
>>>> ==> quite a bit of text duplication in the 2nd paragraph?  Basically you say
>>>> the same thing twice. Is this necessary/useful?
>>>>
>>>> This appears to be a stylistic issue, as the following
>>>> paragraphs have the same as well.
>>
>> [Jeffrey]
>>Actually, we don't, though I'll admit the text is poorly worded. 
>>What it says is this:
>>
>>(a) The mech can specify client-speaks-first
>>(b) The protocol can provide an optional initial response field
>>(c) If (a) and (b) are both true, and the client chooses to use the
>>    optional field, then you save a round trip [example].
>
>OK.
>
>>>> ==> it is not 100% clear what you mean by the "data layer" and
>>>> "data to be carried" in the first paragraph?  Is this the same as the Initial
>>>> Response data in the second paragraph or something else?  If the same,
>>>> remove as duplicate; if not the same, maybe clarify briefly?
>>
>> As indicated by Jeffery, the paragraph should read
>> If the outcome is successful and a security layer was negotiated,
>> this layer is then installed.  This applies as well to the following
>> illustrations.
>
>OK.
>
>>>>  7) If the protocol supports other layered security services, such as
>>>>     Transport Layer Security (TLS) [RFC2246], the specification MUST
>>>>     prescribe the order in which security layers are applied to
>>>>     protocol data.
>>>>
>>>> ==> the revision of TLS spec appears to be almost complete
>>>> (draft-ietf-tls-rfc2246-bis), so maybe it could be referred, though
>>>> for the intents and purposes of this reference this should not matter.
>>
>> I think we should wait and see on this.
>
>OK.
>
>-- 
>Pekka Savola                 "You each name yourselves king, yet the
>Netcore Oy                    kingdom bleeds."
>Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Date: Sun, 10 Jul 2005 07:19:38 -0700
To: [email-masked]
From: Pekka Savola <[email-masked]>
Subject: Re: A review of SASL base : ietf-sasl
Sender: [email-masked]

Replying to Jeff's message, where appropriate, in one.

On Thu, 7 Jul 2005, Kurt D. Zeilenga wrote:
> In response to Pekka's comments...
>>> substantial
>>> -----------
>>>
>>> 1) just an observation: it would be useful for those protocol designers
>>> planning to use SASL to specify in the exchanges how many roundtrips (and
>>> possibly additional bytes, but that's more variable) the exchanges are.  All
>>> the exchange examples have "additional challenge/response messages" but you don't
>>> say how many and what that depends on?
>>>
>>> (There seems to be some useful discussion in section 3.4.  Maybe it should state
>>> the minimum number of roundtrips (1?), and 3.4 should be referred from the the start
>>> of section 3 where you first mention "additional challenge/response messages"?)
>
> I don't think such a statement this is all that necessary.  However,
> I would not object to s/pairs/one or more pairs/ in Section 3.4.

Such a minor edit would be excellent, because it would give the 
readers a sufficient hint about the length of challenge-response 
exchange required.

>>> 2) question on applicability of the latter exchange below.
>
> See Rob's response.

OK.

>>> I also note that the description in the first exchange implies 
>>> that sending additional data is allowed only when the 
>>> authentication is successful,
>
> Correct.
>
>> but I don't see why piggybacking additional data (if sending it is 
>> necessary) should be restricted to just the success?
>
> There is no need to send additional data with the indication of
> failure.
>
>> Contradicting that, section 3.6 does not specify that additional 
>> data may only be sent with a success, rather with any outcome.
>
> I think 3.6 wording meant that the outcome message format may
> include a field for this purpose.  It wasn't intended to imply
> that a non-successful outcome message instance could contain
> data in this field.
>
> Adding:
>  This field can only include additional
>  data when the outcome is successful.
>
> would, I think, adequately address this issue.

As you see, the first issue is document's self-consistency.  You could 
either forbid or allow this (with potentially disclaimers etc). 
Based on follow-up discussion about GSSAPI, there already seems to be 
a mechanism using it with failure.

Looking at this from the external point of view, forbidding it may not 
be the best approach, at least with such strong words as proposed 
above (maybe something like ".. should not include additional data 
when the outcome is a failure" would be closer).

As there are some architectural considerations why this shouldn't 
(typically) be useful or needed, some of this might or might not also 
be appropriate to put in this draft.

>>> 3) how could the client authenticate prior to knowing which authentication
>>> mechanism is should use for authentication?  Maybe the following requires
>>> clarification. (also s/mechanism/mechanisms/ ?)  Are you referring to some predefined
>>> default authentication method or the use of multiple authentications (sect 3.8)?
>>>
>>>  To detect downgrade attacks, a protocol may allow the client to
>>>  discover available mechanism subsequent to the authentication exchange
>>>  (and, hence, protected by any data security layer provided by
>>>  mechanism) so that downgrade attacks can be detected.
>
>[Jeffrey]
>The intent of this text is to suggest that whatever means a protocol 
>provides to discover the set of supported mechanisms should continue 
>to be available after authentication, so that a client can fetch the 
>list again and verify that it hasn't been subjected to a downgrade 
>attack by an attacker modifying the original, unauthenticated list.

Right.  My comment was actually more meant to question how the client 
can authenticate securely, and sufficiently strongly.  If the client 
wouldn't authenticate the server, and the initial (downgraded) 
authentication was something like a plain password, a MITM attacker 
could also forge the "secured" list of authentication methods, and 
downgrade attack would not be detected.

I recall there is some text on the different components being required 
to specify the minimum acceptable authentication, which may mitigate 
this slightly, but it's an open question how much this helps in 
practice.  Referring to this text here would probably help.

(This issue is probably dependent on the resultion of comment 7.)

>>> 4) below you don't specify what how the framework relates if the authentication
>>> outcome is successful, but the installation of the security layer fails for
>>> some reason.  Just to be on the safe side, should you specify or give some guidance
>>> that either (1) the security layer should be installed or somehow tested prior
>>> to reporting outcome (and failure would be, .., failure), or (2) if the installation
>>> of security layer fails for any reason, the session must be aborted using protocol
>>> specific means.
>>>
>>> What I'm worried about is that a sloppy implementation could 
>>> report a successful outcome but the layer might not be installed 
>>> due to whatever reasons, and the user would get a false sense of 
>>> security.  (This seems to be discussed a bit later, in section 
>>> 3.7)
>>>
>>>  If the outcome is successful and a security layer was negotiated, this
>>>  layer is then installed.  If the outcome is unsuccessful, or a
>>>  security layer was not negotiated, any existing security is left in
>>>  place.
>
>
> As implied by Jeffrey's comment, I thinking this would get into
> implementation details.

Would it be appropriate to add something like "If the installation of 
the security layer fails, the connection must be closed as described 
in Section 3.7" here?  (Or if this is too much duplication, just a 
shorter pointer on security layer (installation failures) pointing to 
3.7).  This would sufficiently clarify the case I was concerned about.

>>> 5) is it clear enough which registry are you referring to?
>>> Initially I guessed http://www.iana.org/assignments/service-names, but it turned out to be
>>> http://www.iana.org/assignments/gssapi-service-names.
>
> I think some clarification would be appropriate here.

OK.

>>> It also isn't clear why you mention (and refer to) GSSAPI here, as 
>>> AFAICS these service names need to be used by any SASL mechanism 
>>> whether it has any relation to GSSAPI or not.
>>>
>>>     1) A service name, to be selected from the IANA registry of "service"
>>>     elements for the GSSAPI host-based service name form [RFC2743].
>
> For consistency across all SASL mechanisms which require a
> service name.
>
>[Jeffrey]
>That's correct, and the same set of service names are to be 
>used for all mechanisms.  SASL reuses the registry previously 
>established for GSSAPI and Kerberos service names, because they serve 
>the same function and because it makes things easier if the same name 
>is used at all three layers.

Maybe the text above could be clerer on this, also with regard to 
point 5) above.  Maybe something like the following:

1) An IANA registered 'GSSAPI/Kerberos/SASL service name', using the
    process as described in Section 4.1 of [RFC2743].

>>> 6) What is the IANA registration policy for gssapi-service-names?
>>> The page doesn't tell and the GSSAPI specs don't appear to have
>>> IANA considerations section.
>
> See Section 4.1 of RFC 2743.
>
>> Should this doc specify it?
>
> IMO, no.  (It might be appropriate for this to be detailed
> separately from GSSAPI specifications, such as in a BCP, but
> I don't see this as something we (the SASL WG) needs to address,
> at least now.)
>
>> Should the guidance for protocol designers give advice on this?
>
> We can refer specifically to Section 4.1 of RFC 2743 if that
> helps.

Yes, that would help.  I don't care much one way or the other whether 
this doc specifies the policy or not, but as it is, the policy is not 
clear enough.

Therefore I'd suggest that in addition to adding a pointer to sect 
4.1, this doc would instruct IANA to beef up the IANA service name 
page to describe the allocation policy or at least give a specific 
pointer to the latest policy.

>>> 7) Whether or not you are vulnerable to MITM attacks seems to 
>>> depend on the challenge/response methods used, so the below text 
>>> seems to be assumptive.
>
>[Jeffrey]
>The text assumes that mechanisms which provide a security 
>layer with integrity protection will bind that channel to the 
>authentication used.

I'm not sure if I understand this comment, maybe I don't understand 
the model well enough.  The usefulness of integrity protection depends 
on authentication (because if you protect the integrity of the 
messages to the man-in-the-middle attacker, and the MITM guy modifies 
the messages and sends them to you, purporting to be the server, it 
won't help much).  And if the authentication is too weak, integrity 
protection doesn't seem to help, which was my point?

Or are you making an assumption that prior to SASL is run, you have 
already started an integrity-protected session, with the true 
endpoints and the MITM attacker would be on the wire only for the 
duration of the SASL authentication?  If so, that would seem like a 
too broad assumption for the insecure world out there...

>> An attack example is challenge/response where the server doesn't 
>> authenticate the client, so an attacker which is doing MITM when 
>> SASL is exchanged can continue to perform MITM after the SASL 
>> exchange. I guess it's important to distinguish the cases "MITM 
>> attacker after SASL auth" and "MITM attacker modifying the SASL 
>> negotiation", as well as look at the security of different 
>> challenge/response methods provided.
>>>
>>> 6.1.1. Man-in-the-middle Attacks
>>>
>>>  When the client selects a security layer with at least integrity
>>>  protection, this protects against an active attacker hijacking the
>>>  connection and modifying the authentication exchange to negotiate a
>>>  plain-text connection.  In this case, it is important that any
>>>  security-sensitive protocol negotiations be performed after
>>>  authentication is complete.  Protocols should be designed such that
>>>  negotiations performed prior to authentication should be either
>>>  ignored or revalidated once authentication is complete.
>>>
>>> 7.b) Speaking of which, the document doesn't seem to give any guidance
>>> (or I missed it) to the protocol designers on which kind of
>>> challenge responses should be supported and why (see section 3.4),
>>> particularly the security tradeoffs ?
>
>[Jeffrey] No, I don't think the framework gives guidance to 
>application developers on mechansim selection, and I don't think it 
>should.  This document is the technical specification of what is 
>supposed to be a mechanism-independent, applicaiton-agnostic 
>framework, and as such should not be bound to specific mechansims. 
>I agree that advice from the security community on selection of SASL 
>mechansims (and indeed, on choosing between SASL, GSS, EAP, etc) 
>would be useful, but I don't think it belongs in this document.

>In fact, I think there is some such work underway already, but I'm 
>not going to spend the time to search for it just now.  Perhaps in a 
>later followup...
>
> [Kurt]
> I wholeheartedly agree with Jeffrey's comment here.  Such guidance
> should be provided separately from the technical specification.

I believe such guidance is probably needed, and I guess it's one of 
the cornerstones of secure SASL usage.  Security considerations should 
be used to at least bring up this issue, and provide pointers to such 
work (if already existing).

>>> 8) shouldn't there be some recommendations how to avoid the most important
>>> passive attacks?
>
>[Jeffrey]
>You mean, other than not using those mechanisms, or using 
>SASL-over-TLS as suggested in the first paragraph on page 18?  Does 
>that text need to be expanded a bit?
>
> [Kurt]
> If there are general, mechanism-neutral recommendations that
> are supported by consensus, yes.  I am open to expanding
> this section.

Well, let's just say that as written, this part of the security 
considerations seems to say, "yes, [a couple of vulnerabilities] 
exist", which, looking back at typicaly IESG evaluations, hasn't been 
considered exactly sufficient ;-).. even for non-security area WGs :).

What I was looking for is at least some guidance or pointers how to 
avoid these vulnerabilities.

>>> 9) I don't know the precedent, but I'm not sure if it's appropriate to
>>> include the URLs or addresses in an RFC.
>
> I think the inclusion of the URLs in this RFC are appropriate.
>
>>> Including the template to be filled here is also suspect;
>>> would a better approach be advising
>>> the IANA to include the template at a web page, and suggesting that
>>> whoever wants to fill it, go to the IANA?
>
> No.  An IANA web page is not the definitive statement of
> the procedures for registration of a value.  This document
> states what information is to be provided, to whom, and
> what actions may or may not be taken based upon that
> information.
>
>> That way, if this spec is
>>> revised in the future and the template changes, the users (who might be
>>> looking at an old spec) are always pointed to the latest
>>> version of the template.
>
> If the registration procedures need to be changed, the document
> detailing those procedures should be updated appropriately.
> IANA should advise anyone using an old template to read
> the latest definitive statement of the procedures as stated
> in the latest revision of the SASL technical specification.

Your assumption is that when the IANA would get a registration request 
with the old template (and would somehow be able to detect that an old 
template was being used, if the changes are subtle), IANA would bounce 
it back to the author, adding a roundtrip and dependency on IANA to 
look at the requests carefully.

I don't think that's a good model.  There needs to be a definitive 
statement of procedures (i.e., the latest spec updating the IANA 
registry is normative), yes, but this is a separate issue on where we 
advise the protocol/mechanism designers go looking for the 
registration procedures -- an RFC (the numbers of which could change 
in the future) or a stable IANA website (which can always be pointed 
to refer to the latest specs).

(If you are following the discussion at newtrk WG, this is pretty 
close to an "ISD" arguments.)

To me it seems pretty clear that the users should be instructed to go 
to the IANA website to find the latest procedures.

>>> 7.1.2.  Comments on SASL Mechanism Registrations
>>>
>>>  Comments on registered SASL mechanisms should first be sent to the
>>>  "owner" of the mechanism and/or to the SASL WG mailing list.
>>>
>>>  Submitters of comments may, after a reasonable attempt to contact the
>>>  owner, request IANA to attach their comment to the SASL mechanism
>>>  registration itself by sending mail to <[email-masked]>.  At IANA sole
>>>  discretion, IANA may attach the comment to the registration SASL
>>>  mechanism.
>>>
>>> 10) The use of passive voice conceals who is allowed to change the status
>>> of a mechanism.  Obviously the owner.  I guess the IESG can also do that for
>>> any mechanism?
> [Jeffrey]
>
>You appear to be speaking specifically to the text about declaring a 
>mechansim "OBSOLETE", since I can't find anything else that's at all 
>unclear.  Lacking any text to the contrary, I would expect this 
>change to fall under the same rules as any other, as defined earlier 
>in the same section.  Namely, only the owner may make changes, except 
>that the IESG can change an owner.

Yes, obsoleting was the thing that struck my eye, it should be spelled 
out explicitly.

> [Kurt>
> Only the owner.  Of course, IESG may assume or assign
> ownership in order to facility such a change.
>
>> Can anyone else change another people's markings?  What's the
>>> RFC2434 requirement?  IETF consensus?  IESG Approval?
>
> The change request follows the same procedure as the registration request.

It seems a bit strange to me that if the IETF had a consensus about 
the Usage status of a mechanism the IESG could not instruct the IANA 
to change the status to something else, but would have to change the 
owner first.

But I don't think this issue is big enough to warrant prolonged 
discussion.

>>> 11) normative reference issues (for the future). I think this spec
>>> is intended to be recycled to Draft Standard after being 6 months at
>>> PS.
>
> That is the hope but might not necessarily be the reality.
>
>> Please note that the normative references are at PS, so this spec
>>> cannot be moved to DS before these also move forward, or some other
>>> solution is found.
>
> or we obtain a variance.  I think we can deal with this
> when the future arrives.

Well, what I was hoping is that folks try to start campainging moving 
some of these forward as well now.

>>> 12) are these changes with respect to RFC 2222 backward-compatible?
>
> They are believed to be backwards compatible.
>
>>> If not, a transition strategy or a bit of warning might be warranted.
>>> All in all, it might be a good idea to state explicitly whether
>>> there are cases where 2222bis (due to new requirements for mechanisms, etc.)
>>> would be incompatible with 2222.
>
> [Jeffrey]
>This is a messy issue, and transition strategies, to the extent that 
>they are needed, will depend on the specific application protocols 
>involved.  I don't expect there are deployed applications for which 
>this will actually matter very much (particularly WRT prohibiting 
>NUL), but perhaps I am underestimating the scope of the problem.
>
> [Kurt]
> The new requirements are upon mechanism/protocol SPECIFICATIONS, not
> mechanisms/protocols.  If a mechanism/protocol specification is
> changed in a way that changes the mechanism/protocol (whether
> done to fulfill new requirements or not), that specification
> is responsible to address compatibility issues.

First, it seems that there are two issues:
  1) transition issues in the SASL framework.  If you implement some of 
this stuff in a library, you may face these issues when you upgrade 
the library to 2222bis
  2) transition issues in the protocols, mechanisms, etc. See below.

While the transition issues in the mechanisms etc. are likely going to 
be uncovered when the mechanism is revised (or updated to work with 
the new framework, see 1), there could be issues which are common to 
every mechanism.  Therefore completely punting dealing with transition 
issues to the specifications implementing the framework doesn't seems 
a bit questionable.

>>> editorial
>>> ---------
>>>
>>>  If the outcome is successful and a data layer was negotiated, this
>>>  layer is then installed.  Protocols may allow this data to be carried
>>>  in the request message.  This applies as well to the following
>>>  illustrations.
>>>
>>>  Some mechanisms specify that the first data sent in the authentication
>>>  exchange is from the client to the server.  Protocols may provide an
>>>  optional initial response field in the request message to carry this
>>>  data.  Where the mechanism specifies the first data data sent in the
>>>  exchange is from the client to the server, the protocol provides an
>>>  optional initial response field, and the client uses this field, the
>>>  exchange is shortened by one round-trip:
>>>
>>>      C: Request authentication exchange + Initial response
>>>      <additional challenge/response messages>
>>>      S: Outcome of authentication exchange
>>>
>>> ==> quite a bit of text duplication in the 2nd paragraph?  Basically you say
>>> the same thing twice. Is this necessary/useful?
>>>
>>> This appears to be a stylistic issue, as the following
>>> paragraphs have the same as well.
>
> [Jeffrey]
>Actually, we don't, though I'll admit the text is poorly worded. 
>What it says is this:
>
>(a) The mech can specify client-speaks-first
>(b) The protocol can provide an optional initial response field
>(c) If (a) and (b) are both true, and the client chooses to use the
>    optional field, then you save a round trip [example].

OK.

>>> ==> it is not 100% clear what you mean by the "data layer" and
>>> "data to be carried" in the first paragraph?  Is this the same as the Initial
>>> Response data in the second paragraph or something else?  If the same,
>>> remove as duplicate; if not the same, maybe clarify briefly?
>
> As indicated by Jeffery, the paragraph should read
> If the outcome is successful and a security layer was negotiated,
> this layer is then installed.  This applies as well to the following
> illustrations.

OK.

>>>  7) If the protocol supports other layered security services, such as
>>>     Transport Layer Security (TLS) [RFC2246], the specification MUST
>>>     prescribe the order in which security layers are applied to
>>>     protocol data.
>>>
>>> ==> the revision of TLS spec appears to be almost complete
>>> (draft-ietf-tls-rfc2246-bis), so maybe it could be referred, though
>>> for the intents and purposes of this reference this should not matter.
>
> I think we should wait and see on this.

OK.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Date: Fri, 08 Jul 2005 13:38:24 -0700
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: A review of SASL base
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 12:03 PM 7/8/2005, Sam Hartman wrote:
>Kurt, why do you say that there is no need to send additional data
>with failure?  We've found that useful in the GSS case to give a final token
>describing why things failed.

SASL's assumption that the application protocol provides adequate
facilities for communicating why things failed in the
protocol-specific fields of the outcome message.  That is,
SASL assumes there is no need to communicate why things failed
in a mechanism-specific manner.  This assumption may well be
flawed.  Certainly it leads to inconsistent mapping of
mechanism specification failure reasons to protocol specific
failure reasons in implementations.  While these mappings can
be standardized, this is counter to the desire for protocol
specifications to be mechanism independent.   The alternative
of relying solely on mechanism failure reasons can also
be problematic, especially when the protocol supports
other authentication methods (e.g., native simple authentication,
native GSSAPI authentication, etc..).  

SASL, as I understand it, was designed to be retrofitted into
existing application protocols and their error handling
facilities.  Hence, the design which relies on implementations
to map mechanism specific failure reasons into protocol specific
fields.

Anyways, my statement was poorly worded.  I should have elaborated
on why in the SASL model sending additional data with an outcome
message indicating failure is not viewed as necessary.

Kurt

Date: Fri, 08 Jul 2005 16:06:03 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Sam Hartman <[email-masked]>, "Kurt D. Zeilenga" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: A review of SASL base
Originator-Info: login-token=Mulberry:01Yo/LI8z3QJeu2kOklQ37kvkBAk7pw0TPBPmImA8=; token_authority=[email-masked]
Sender: [email-masked]

On Friday, July 08, 2005 03:03:23 PM -0400 Sam Hartman 
<[email-masked]> wrote:

>
> Kurt, why do you say that there is no need to send additional data
> with failure?
>
> We've found that useful in the GSS case to give a final token
> describing why things failed.

Note that in the case of GSSAPI this is very clean, because the only way 
for the application layer to find out the negotiation has failed is by 
getting an error return from gss_init_sec_context, either the first time it 
is called or in response to a token.  So, at the wire level, the app 
protocol can't tell the difference between success and failure.

In SASL, because the outcome message is protocol-specific and not 
mechanism-specific, the app protocol can tell whether the exchange has 
succeeded or not.  It is entirely possible that some existing application 
protocol provides no way to send additional data with failure.  A mechanism 
that wants to deal with this in a portable fashion would have to be 
prepared to handle this the same way it would handle an app protocol that 
didn't provide for additional data at success, by sending a "challenge" 
containing the error details and expecting a null response.

I do, however, agree with Sam's point -- it is extremely useful for the 
server to be able to send back mechanism-specific data describing why the 
exchange failed in detail, and I don't think we should go out of our way to 
prohibit that, if we can allow it without breaking existing applications.

-- Jeff

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: A review of SASL base
From: Sam Hartman <[email-masked]>
Date: Fri, 08 Jul 2005 15:03:23 -0400
Sender: [email-masked]

Kurt, why do you say that there is no need to send additional data
with failure?

We've found that useful in the GSS case to give a final token
describing why things failed.

Date: Fri, 08 Jul 2005 09:17:19 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>, Sam Hartman <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: A review of SASL base
Originator-Info: login-token=Mulberry:01zzd5zTmf7kEbgvFOArWpPGapsPhWa/I8rKcyBbc=; token_authority=[email-masked]
Sender: [email-masked]

On Thursday, July 07, 2005 09:30:00 PM -0700 "Kurt D. Zeilenga" 
<[email-masked]> wrote:

>>> 6) What is the IANA registration policy for gssapi-service-names?
>>> The page doesn't tell and the GSSAPI specs don't appear to have
>>> IANA considerations section.
>
> See Section 4.1 of RFC 2743.

Hm.  Indeed, RFC2743 does specify a policy of "Specification Required" for 
this registry.  That's probably a little strong in this case, since the 
values in question are not used to determine behavior (the correct choice 
depends on what service you are implementing, but nothing should be basing 
its behavior solely on what service name it sees).

I'm not sure if IANA's registry pages normally indicate the registration 
policy, or if it's up to the reader to discover it by reading the 
appropriate spec.

-- Jeff

Date: Thu, 07 Jul 2005 21:30:00 -0700
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: A review of SASL base
Cc: [email-masked], [email-masked]
Sender: [email-masked]

In response to Pekka's comments...

>Return-Path: <[email-masked]>
>Received: from solipsist-nation ([unix socket])
>        by solipsist-nation (Cyrus v2.1.16-IPv6-Debian-2.1.16-10) with LMTP; Tue,
> 05 Jul 2005 12:44:51 -0400
>X-Sieve: CMU Sieve 2.2
>Return-Path: <[email-masked]>
>Received: from south-station-annex.mit.edu (SOUTH-STATION-ANNEX.MIT.EDU
> [18.72.1.2])
>        (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
>        (No client certificate requested)
>        by suchdamage.org (Postfix) with ESMTP id 30FB813259
>        for <[email-masked]>; Tue,  5 Jul 2005 12:44:50 -0400 (EDT)
>Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
> [18.7.21.83])
>        by south-station-annex.mit.edu (8.12.4/8.9.2) with ESMTP id j65GinT0001947
>        for <[email-masked]>; Tue, 5 Jul 2005 12:44:49 -0400 (EDT)
>Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59])
>        by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id
> j65Gibf2022590
>        for <[email-masked]>; Tue, 5 Jul 2005 12:44:38 -0400 (EDT)
>Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
>        by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j65GiZdd022113
>        for <[email-masked]>; Tue, 5 Jul 2005 09:44:35 -0700 (PDT)
>Received: from [192.168.1.4] (vpn-10-50-0-32.qualcomm.com [10.50.0.32])
>        by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j65GiT50010702
>        for <[email-masked]>; Tue, 5 Jul 2005 09:44:33 -0700 (PDT)
>Message-Id: <p06230906bef069450ca9@[192.168.1.4]>
>Date: Tue, 5 Jul 2005 09:44:28 -0700
>To: [email-masked]
>From: Ted Hardie <[email-masked]>
>Subject: Fwd: Re: SASL review?
>X-Scanned-By: MIMEDefang 2.42
>X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on 
>        solipsist-nation.suchdamage.org
>X-Spam-Level: 
>X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
>        version=3.0.2
>MIME-Version: 1.0
>
>Pekka's comments on the SASL docs.
>                                ted
>
>
>>Date: Sat, 2 Jul 2005 16:41:21 +0300 (EEST)
>>From: Pekka Savola <[email-masked]>
>>To: Ted Hardie <[email-masked]>
>>Subject: Re: SASL review?
>>
>>Feel free to pass the comments along and include me in the followups.
>>
>>.......
>>
>>I liked the spec, it was mostly very fluent to read and to understand. I don't think there are any showstoppers, but I noticed a number of places which could use improvement. As I've never read any SASL specs in the past, be gentle.
>>
>>(I wrote the comments as I read the spec, and added a few notes afterwards; there seemed to be some need for adding more forward pointers.)
>>
>>substantial
>>-----------
>>
>>1) just an observation: it would be useful for those protocol designers
>>planning to use SASL to specify in the exchanges how many roundtrips (and
>>possibly additional bytes, but that's more variable) the exchanges are.  All
>>the exchange examples have "additional challenge/response messages" but you don't
>>say how many and what that depends on?
>>
>>(There seems to be some useful discussion in section 3.4.  Maybe it should state
>>the minimum number of roundtrips (1?), and 3.4 should be referred from the the start
>>of section 3 where you first mention "additional challenge/response messages"?)

I don't think such a statement this is all that necessary.  However,
I would not object to s/pairs/one or more pairs/ in Section 3.4.

>>
>>2) question on applicability of the latter exchange below.

See Rob's response.

>>
>>     C: Request authentication exchange
>>      S: Initial challenge
>>      C: Initial response
>>      <additional challenge/response messages>
>>      S: Outcome of authentication exchange with
>>         additional data with success
>>
>>....
>>
>>      C: Request authentication exchange
>>      S: Initial challenge
>>      C: Initial response
>>      <additional challenge/response messages>
>>      S: Additional data challenge
>>      C: Empty Response
>>      S: Outcome of authentication exchange
>>
>>==> (too bad there aren't names for different kind of exchanges, it's difficult
>>to refer which ones you're talking about..)  The spec is clear here, but I don't
>>understand the usefulness of the second SASL conversation.  If the client's response
>>must always be empty, there is no benefit in sending additional data prior to the
>>outcome of the authentication exchange.  You're just wasting one roundtrip here.
>>
>>Why would anyone want to use the latter approach?  Does it need to be
>>supported?  Are there restrictions on the first exchange which aren't
>>spelled out?
>>
>>I also note that the description in the first exchange implies that sending additional data is allowed only when the authentication is successful,

Correct.

>but I don't see why piggybacking additional data (if sending it is necessary) should be restricted to just the success?

There is no need to send additional data with the indication of
failure.

>Contradicting that, section 3.6 does not specify that additional data may only be sent with a success, rather with any outcome.

I think 3.6 wording meant that the outcome message format may
include a field for this purpose.  It wasn't intended to imply
that a non-successful outcome message instance could contain
data in this field.

Adding:
  This field can only include additional          
  data when the outcome is successful.

would, I think, adequately address this issue.

>>3) how could the client authenticate prior to knowing which authentication
>>mechanism is should use for authentication?  Maybe the following requires
>>clarification. (also s/mechanism/mechanisms/ ?)  Are you referring to some predefined
>>default authentication method or the use of multiple authentications (sect 3.8)?
>>
>>  To detect downgrade attacks, a protocol may allow the client to
>>  discover available mechanism subsequent to the authentication exchange
>>  (and, hence, protected by any data security layer provided by
>>  mechanism) so that downgrade attacks can be detected.

See Jeffrey's comments.

>>
>>4) below you don't specify what how the framework relates if the authentication
>>outcome is successful, but the installation of the security layer fails for
>>some reason.  Just to be on the safe side, should you specify or give some guidance
>>that either (1) the security layer should be installed or somehow tested prior
>>to reporting outcome (and failure would be, .., failure), or (2) if the installation
>>of security layer fails for any reason, the session must be aborted using protocol
>>specific means.
>>
>>What I'm worried about is that a sloppy implementation could report a successful outcome
>>but the layer might not be installed due to whatever reasons, and the user would get a false sense of security.  (This seems to be discussed a bit later, in
>>section 3.7)
>>
>>  If the outcome is successful and a security layer was negotiated, this
>>  layer is then installed.  If the outcome is unsuccessful, or a
>>  security layer was not negotiated, any existing security is left in
>>  place.

As implied by Jeffrey's comment, I thinking this would get into
implementation details.

>>
>>5) is it clear enough which registry are you referring to?
>>Initially I guessed http://www.iana.org/assignments/service-names, but it turned out to be
>>http://www.iana.org/assignments/gssapi-service-names.

I think some clarification would be appropriate here.

>>It also isn't clear why you mention (and refer to) GSSAPI here, as AFAICS these service names need to be used by any SASL mechanism whether it has any relation to GSSAPI or not.
>>
>>     1) A service name, to be selected from the IANA registry of "service"
>>     elements for the GSSAPI host-based service name form [RFC2743].

For consistency across all SASL mechanisms which require a
service name.

>>6) What is the IANA registration policy for gssapi-service-names?
>>The page doesn't tell and the GSSAPI specs don't appear to have
>>IANA considerations section.

See Section 4.1 of RFC 2743.

>Should this doc specify it?

IMO, no.  (It might be appropriate for this to be detailed
separately from GSSAPI specifications, such as in a BCP, but
I don't see this as something we (the SASL WG) needs to address,
at least now.)

>Should the guidance for protocol designers give advice on this?

We can refer specifically to Section 4.1 of RFC 2743 if that
helps.

>>7) Whether or not you are vulnerable to MITM attacks seems to depend on the challenge/response methods used, so the below text seems to be assumptive.  

See Jeffrey's comment.

>An attack example is challenge/response where the server doesn't authenticate the client, so an attacker which is doing MITM when SASL is exchanged can continue to perform MITM after the SASL exchange. I guess it's important to distinguish the cases "MITM attacker after SASL auth" and "MITM attacker modifying the SASL negotiation", as well as look at the security of different challenge/response methods provided.
>>
>>6.1.1. Man-in-the-middle Attacks
>>
>>  When the client selects a security layer with at least integrity
>>  protection, this protects against an active attacker hijacking the
>>  connection and modifying the authentication exchange to negotiate a
>>  plain-text connection.  In this case, it is important that any
>>  security-sensitive protocol negotiations be performed after
>>  authentication is complete.  Protocols should be designed such that
>>  negotiations performed prior to authentication should be either
>>  ignored or revalidated once authentication is complete.
>>
>>7.b) Speaking of which, the document doesn't seem to give any guidance
>>(or I missed it) to the protocol designers on which kind of
>>challenge responses should be supported and why (see section 3.4),
>>particularly the security tradeoffs ?

I wholeheartedly agree with Jeffrey's comment here.  Such guidance
should be provided separately from the technical specification.

>>
>>8) shouldn't there be some recommendations how to avoid the most important
>>passive attacks?

If there are general, mechanism-neutral recommendations that
are supported by consensus, yes.  I am open to expanding
this section.

>>
>>6.2.  Passive Attacks
>>
>>  Many mechanisms are subject to various passive attacks, including
>>  simple eavesdropping of unprotected credential information in
>>  mechanisms, such as PLAIN, to online and offline dictionary attacks.
>>
>>9) I don't know the precedent, but I'm not sure if it's appropriate to
>>include the URLs or addresses in an RFC.

I think the inclusion of the URLs in this RFC are appropriate.

>>Including the template to be >filled here is also suspect;
>would a better approach be advising
>>the IANA to include the template at a web page, and suggesting that
>>whoever wants to fill it, go to the IANA? 

No.  An IANA web page is not the definitive statement of
the procedures for registration of a value.  This document
states what information is to be provided, to whom, and
what actions may or may not be taken based upon that
information.

>That way, if this spec is
>>revised in the future and the template changes, the users (who might be
>>looking at an old spec) are always pointed to the latest
>>version of the template.

If the registration procedures need to be changed, the document
detailing those procedures should be updated appropriately.
IANA should advise anyone using an old template to read
the latest definitive statement of the procedures as stated
in the latest revision of the SASL technical specification.

>>
>>7.1.  SASL Mechanism Registry
>>
>>  SASL mechanism registry is maintained by IANA.  The registry is
>>  currently available at
>>  <http://www.iana.org/assignments/sasl-mechanisms>.
>>...
>> and sending it via electronic mail to <[email-masked]>.
>>...
>>7.1.2.  Comments on SASL Mechanism Registrations
>>
>>  Comments on registered SASL mechanisms should first be sent to the
>>  "owner" of the mechanism and/or to the SASL WG mailing list.
>>
>>  Submitters of comments may, after a reasonable attempt to contact the
>>  owner, request IANA to attach their comment to the SASL mechanism
>>  registration itself by sending mail to <[email-masked]>.  At IANA sole
>>  discretion, IANA may attach the comment to the registration SASL
>>  mechanism.
>>
>>10) The use of passive voice conceals who is allowed to change the status
>>of a mechanism.  Obviously the owner.  I guess the IESG can also do that for
>>any mechanism?

Only the owner.  Of course, IESG may assume or assign
ownership in order to facility such a change.

>Can anyone else change another people's markings?  What's the
>>RFC2434 requirement?  IETF consensus?  IESG Approval?

The change request follows the same procedure as the registration request.

>>
>>  SASL mechanism registrations may not be deleted; mechanisms which are
>>  no longer believed appropriate for use can be declared OBSOLETE by a
>>  change to their "intended usage" field; such SASL mechanisms will be
>>  clearly marked in the lists published by IANA.
>>
>>11) normative reference issues (for the future). I think this spec
>>is intended to be recycled to Draft Standard after being 6 months at
>>PS.

That is the hope but might not necessarily be the reality.

>Please note that the normative references are at PS, so this spec
>>cannot be moved to DS before these also move forward, or some other
>>solution is found.

or we obtain a variance.  I think we can deal with this
when the future arrives.
 
>>
>>  [RFC2743]     Linn, J., "Generic Security Service
>>                Application Program Interface, Version 2, Update 1", RFC
>>                2743, January 2000.
>>
>>  [RFC3454]     Hoffman, P. and M. Blanchet, "Preparation of
>>                Internationalized Strings ('stringprep')", RFC 3454,
>>                December 2002.
>>
>>  [RFC4013]     Zeilenga, K., "SASLprep: Stringprep Profile for User
>>                Names and Passwords", RFC 4013, February 2005.
>>
>>12) are these changes with respect to RFC 2222 backward-compatible?

They are believed to be backwards compatible.

>>If not, a transition strategy or a bit of warning might be warranted.
>>All in all, it might be a good idea to state explicitly whether
>>there are cases where 2222bis (due to new requirements for mechanisms, etc.)
>>would be incompatible with 2222.

The new requirements are upon mechanism/protocol SPECIFICATIONS, not
mechanisms/protocols.  If a mechanism/protocol specification is
changed in a way that changes the mechanism/protocol (whether
done to fulfill new requirements or not), that specification
is responsible to address compatibility issues.

>>
>> RFC 2222, by not stating the authorization identity string was a
>>  string of Unicode characters, let alone character data, implied the
>>  authorization identity string was a string of octets.
>>
>>  - The authorization identity string is now defined as a string of
>>    Unicode characters.  The NUL (U+0000) is prohibited.  While protocol
>>    specifications are responsible for defining the authorization
>>    identity form, as well as the Unicode string syntax and related
>>    semantics, mechanism specifications are responsible for defining how
>>    the Unicode string is carried in the authentication exchange.
>>
>>  The following technical change was made to the EXTERNAL mechanism:
>>
>>  - The authorization identity string is to be UTF-8 encoded.
>>
>>
>>editorial
>>---------
>>
>>  If the outcome is successful and a data layer was negotiated, this
>>  layer is then installed.  Protocols may allow this data to be carried
>>  in the request message.  This applies as well to the following
>>  illustrations.
>>
>>  Some mechanisms specify that the first data sent in the authentication
>>  exchange is from the client to the server.  Protocols may provide an
>>  optional initial response field in the request message to carry this
>>  data.  Where the mechanism specifies the first data data sent in the
>>  exchange is from the client to the server, the protocol provides an
>>  optional initial response field, and the client uses this field, the
>>  exchange is shortened by one round-trip:
>>
>>      C: Request authentication exchange + Initial response
>>      <additional challenge/response messages>
>>      S: Outcome of authentication exchange
>>
>>==> quite a bit of text duplication in the 2nd paragraph?  Basically you say
>>the same thing twice. Is this necessary/useful?
>>
>>This appears to be a stylistic issue, as the following
>>paragraphs have the same as well.

See Jeffrey's comment.

>>
>>==> s/data data/data/
>>
>>==> it is not 100% clear what you mean by the "data layer" and
>>"data to be carried" in the first paragraph?  Is this the same as the Initial
>>Response data in the second paragraph or something else?  If the same,
>>remove as duplicate; if not the same, maybe clarify briefly?

As indicated by Jeffery, the paragraph should read
 If the outcome is successful and a security layer was negotiated,     
 this layer is then installed.  This applies as well to the following
 illustrations.

>>
>>  Where the mechanism specifies the server is to return additional data
>>  to the client with a successful outcome and and this field is

>>
>>==> s/and and/and/
>>
>>  SASL mechanisms names are registered as discussed in Section 7.1.
>>
>>==> s/mechanisms/mechanism/
>>
>>  be provided, and negotiation of a maximum cipher-text buffer size each
>>  size is able to receive in the layer (see Section 3.6).
>>
>>==> s/each size/each side/
>>
>>    - the identity associated with the client's credentials are not
>>      authorized to act as the requested authorization identity,
>>
>>==> s/are/is/
>>
>>  7) If the protocol supports other layered security services, such as
>>     Transport Layer Security (TLS) [RFC2246], the specification MUST
>>     prescribe the order in which security layers are applied to
>>     protocol data.
>>
>>==> the revision of TLS spec appears to be almost complete
>>(draft-ietf-tls-rfc2246-bis), so maybe it could be referred, though
>>for the intents and purposes of this reference this should not matter.

I think we should wait and see on this.

>>
>>  1) The name of the mechanism (see Section 3.1).  This name MUST be
>>     registered as discussed in Section 8.1.
>>
>>==> you mean sect 7.1..
>>
>>  In order to avoid interoperability problems due to differing
>>  normalizations, when a mechanism calls for character data is to be
>>  used as input to a cryptographic and/or comparison function, the
>>
>>==> I cannot parse "calls for character data ..."
>>
>>  generation of any long-term cryptographic keys or hashes as there is
>>  no requirement that the authorization identity string be be
>>  non-canonical.
>>
>>==> s/be be/be/
>>
>>  services.  It is also hoped that future mechanisms will provide more
>>  advance data security services like re-keying (see Section 6.1).
>>
>>==> s/advance/advanced/
>>
>>  Administrative limits on security layers lifetime may take the form of
>>
>>==> s/layers/layers'/ (similar later in the paragraph)
>>
>>      Security considerations: See RFC XXXX, section 9.
>>      Published specification (optional, recommended): RFC XXXX
>>
>>==> it may be blindingly obviously, but should you say that XXXX
>>refers to the number given to this draft? :)
>>
>>    Security considerations: See RFC XXXX, section 9.
>>
>>==> did you mean section 7 or appendix A?
>>Using xml2rfc would help you with these ;-)

Date: Wed, 6 Jul 2005 10:30:08 -0400 (EDT)
From: Jeffrey Hutzelman <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
cc: Sam Hartman <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: A review of SASL base
Sender: [email-masked]

On Tue, 5 Jul 2005, Kurt D. Zeilenga wrote:

> At 02:25 PM 7/5/2005, Sam Hartman wrote:
> >I actually think it would be fine for SASL to update the registration
> >policy for the gss service names registry if it wants to.  I agree
> >with Jeff Hutzelman that it would need review in krb-wg and kitten.
>
> I suggest that the gss service names registry details/policy
> be stated in a BCP.  That way documents, whether they be SASL,
> Kerberos, or other specifications, depending on the
> registry won't get stuck on the normative reference.

Agreed.

Date: Tue, 05 Jul 2005 20:21:38 -0700
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: A review of SASL base
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 02:25 PM 7/5/2005, Sam Hartman wrote:
>I actually think it would be fine for SASL to update the registration
>policy for the gss service names registry if it wants to.  I agree
>with Jeff Hutzelman that it would need review in krb-wg and kitten.

I suggest that the gss service names registry details/policy
be stated in a BCP.  That way documents, whether they be SASL,
Kerberos, or other specifications, depending on the
registry won't get stuck on the normative reference.

Kurt 

To: Jeffrey Hutzelman <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: A review of SASL base
From: Sam Hartman <[email-masked]>
Date: Tue, 05 Jul 2005 17:25:33 -0400
Sender: [email-masked]

I actually think it would be fine for SASL to update the registration
policy for the gss service names registry if it wants to.  I agree
with Jeff Hutzelman that it would need review in krb-wg and kitten.

Date: Tue, 05 Jul 2005 14:11:04 -0700
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: LAST CALL: Simple Authentication and Security Layer (SASL)
Cc: [email-masked]
Sender: [email-masked]

At 06:21 AM 6/24/2005, Simon Josefsson wrote:

>Hello all,
>
>In general, I think the document is pretty good.  It could use a
>re-read, to fix editorial flaws.  I only reviewed my pet problem-area
>of SASLprep below.
>
>Section 4, Protocol Requirements:
>
>     Specifications are encouraged to prescribe use of existing
>     authorization identity forms as well as existing string
>     representations, such as simple user names [RFC4013].  Protocols
>     whose authorization identities are simple user names SHOULD use of
>     SASLprep [RFC4013] (a profile of the StringPrep [RFC3454]
>     preparation algorithm) as their preparation algorithm.
>
>The intention of the requirement appear unclear to me.  For example,
>take IMAP or SMTP authentication, with simple username+password.  Is
>the intention that the transferred authorization identity should be in
>SASLprep:ed form?  If so, I believe it is better to preserve as much
>as possible of what the user typed as long as possible.  Having the
>client apply SASLprep to the authorization identity would violate
>that.
>
>On the other hand, requiring the server to apply SASLprep may be too
>expensive.  There are resource-starvation issues to consider here.
>Customers are asking for optimized versions of my StringPrep
>implementation to be able to use it in a server.
>If the above requirement is going to be present, I believe it should
>either be clear on what is intended, or acknowledge that it is meant
>to be fuzzy and that is leaves things open.  To me, I get the
>impression that it is meant to be fuzzy.

The recommendation was intended only to encourage use of
SASLprep.  The wording purposely avoids details such as
whether the SASLprep, if applied, would be applied by the
client before transfer of the authzid or by the server
upon receipt.  That detail is left to protocol specifications.

For a protocol which recommends (TLS+)PLAIN, server-side
application likely makes the most sense (for consistency with
PLAIN).

For a protocol which recommends DIGEST-MD5, client-side
application likely makes the most sense (for consistency with
DIGEST-MD5).

A protocol which recommends TLS+EXTERNAL, well, its kind of
a toss up.

I note that I support dropping the second sentence of the
above quoted passage.  It seems redundant with the first
which already references SASLprep.

>Adopting parts of the
>following paragraph, from Mechanism Requirements, would acknowledge
>that the fuzziness is intended, and that protocol specifications must
>clarify the details.  What do you think?
>
>  In order to avoid interoperability problems due to differing
>  normalizations, when a mechanism calls for character data is to be
>  used as input to a cryptographic and/or comparison function, the
>  specification MUST detail precisely how and where (client or server)
>  the character data is to be prepared, including all normalizations,
>  for input into the function to ensure proper operation.
>
>Also, there is a typo, s/SHOULD use of/SHOULD use/.

I wouldn't have a problem adding something like:
  In order to avoid interoperability problems due to differing
  normalizations, the protocol specification MUST detail precisely
  the how and where (client or server) non-\empty authorization 
  identity strings are prepared, including all normalizations,
  for comparison and other applicable functions to ensure
  proper function.

as the second paragraph of 4(4).

>Section 5, Mechanism Requirements:
>
>  The mechanism SHOULD NOT use the authorization identity string in
>  generation of any long-term cryptographic keys or hashes as there is
>  no requirement that the authorization identity string be be
>  non-canonical.
>
>I might be picking words here, but 'non-canonical'?  Shouldn't that be
>'canonical'?

Yes.

>Even so, if I understand correctly, what is intended is
>that one user may have different authorization identities in different
>protocols,

No.  Note that document is talking about the authorization identity
STRING of a particular not being canonical.  That is, two different
authorization identity strings in a particular protocol may represent
the same identity.  For instance, [email-masked] and [email-masked]
both may represent the same simple user name.   Using either in a
long-term key/hash would be problematic.

>and that is why mechanisms shouldn't use the authorization
>identities as input to hash functions etc.  If so, I don't think
>"canonical" is a good word here, since one protocol's authzid is as
>good as another protocol's authzid.  There is no "canonical" authzid
>to speak of.

Of course.  This warning was more to the point that there
can be more than one valid string in a particular protocol
that represent the same authorization identity.

>Also, there is a typo, s/be be/to be/.
>
>Cheers,
>Simon

Date: Tue, 5 Jul 2005 14:11:23 -0700
From: Rob Siemborski <[email-masked]>
Reply-To: Rob Siemborski <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Subject: Re: A review of SASL base
Cc: Sam Hartman <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On 7/5/05, Jeffrey Hutzelman <[email-masked]> wrote:

[original message]:
>2) question on applicability of the latter exchange below.
>
>     C: Request authentication exchange
>      S: Initial challenge
>      C: Initial response
>      <additional challenge/response messages>
>      S: Outcome of authentication exchange with
>         additional data with success
>
>....
>
>      C: Request authentication exchange
>      S: Initial challenge
>      C: Initial response
>      <additional challenge/response messages>
>      S: Additional data challenge
>      C: Empty Response
>      S: Outcome of authentication exchange
>
>==> (too bad there aren't names for different kind of exchanges, it's difficult
>to refer which ones you're talking about..)  The spec is clear here,
but I don't
>understand the usefulness of the second SASL conversation.  If the
client's response
>must always be empty, there is no benefit in sending additional data
prior to the
>outcome of the authentication exchange.  You're just wasting one
roundtrip here.

> >> 2) question on applicability of the latter exchange below.
> 
> Punting this to someone who recalls more of the details.

This sort of exchange is necessary when the mechanism is defined to
return additional data with success (for example, mutual
authentication) but the protocol (for whatever reason) does not
support it in its sasl profile.

For example, DIGEST-MD5 over IMAP.

If you don't do this, you essentially require all protocols to support
the last server challenge with their success data, which many legacy
protocols cannot do.

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

Date: Tue, 05 Jul 2005 16:51:38 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Sam Hartman <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Re: A review of SASL base
Originator-Info: login-token=Mulberry:01oU1aoQu1zxXtmNIi1MuKEDi/kcwogdMOwogG180=; token_authority=[email-masked]
Sender: [email-masked]

Replies off the top of my head...

>> 1) just an observation: it would be useful for those protocol designers
>> planning to use SASL to specify in the exchanges how many roundtrips (and
>> possibly additional bytes, but that's more variable) the exchanges are.
>> All the exchange examples have "additional challenge/response messages"
>> but you don't say how many and what that depends on?
>>
>> (There seems to be some useful discussion in section 3.4.  Maybe it
>> should state the minimum number of roundtrips (1?), and 3.4 should be
>> referred from the the start of section 3 where you first mention
>> "additional challenge/response messages"?)

The number of round trips required is going to depend on the mechanism in 
use; in order to support all mechanisms an application must be prepared to 
handle an arbitrary number of round trips.  Further, the nature of some 
mechanisms will be such that you cannot always know the number of round 
trips in advance.

>> 2) question on applicability of the latter exchange below.

Punting this to someone who recalls more of the details.

>> 3) how could the client authenticate prior to knowing which
>> authentication mechanism is should use for authentication?  Maybe the
>> following requires clarification. (also s/mechanism/mechanisms/ ?)  Are
>> you referring to some predefined default authentication method or the
>> use of multiple authentications (sect 3.8)?
>>
>>  To detect downgrade attacks, a protocol may allow the client to
>>  discover available mechanism subsequent to the authentication exchange
>>  (and, hence, protected by any data security layer provided by
>>  mechanism) so that downgrade attacks can be detected.

The intent of this text is to suggest that whatever means a protocol 
provides to discover the set of supported mechanisms should continue to be 
available after authentication, so that a client can fetch the list again 
and verify that it hasn't been subjected to a downgrade attack by an 
attacker modifying the original, unauthenticated list.

>> 4) below you don't specify what how the framework relates if the
>> authentication outcome is successful, but the installation of the
>> security layer fails for some reason.  Just to be on the safe side,
>> should you specify or give some guidance that either (1) the security
>> layer should be installed or somehow tested prior to reporting outcome
>> (and failure would be, .., failure), or (2) if the installation of
>> security layer fails for any reason, the session must be aborted using
>> protocol specific means.

"Installation of the security layer" isn't separately visible on the wire. 
It just means that you start sending and receiving data as specified by 
that security layer.  If you don't (which would be buggy implementation 
behavior), then you won't be able to communicate with the peer at all.

Of course if there is some internal problem that prevents the 
implementation from formatting data for transmission or processing received 
data, then it will need to report that up to the next higher layer, in an 
implementation dependent fashion.

>> 5) is it clear enough which registry are you referring to?
>> Initially I guessed http://www.iana.org/assignments/service-names, but
>> it turned out to be http://www.iana.org/assignments/gssapi-service-names.

Well, if you had to guess, then perhaps it's not clear enough.

>> It also isn't clear why you mention (and refer to) GSSAPI here, as
>> AFAICS these service names need to be used by any SASL mechanism whether
>> it has any relation to GSSAPI or not.
>>
>>     1) A service name, to be selected from the IANA registry of "service"
>>     elements for the GSSAPI host-based service name form [RFC2743].

That's correct, and the same set of service names are to be used for all 
mechanisms.  SASL reuses the registry previously established for GSSAPI and 
Kerberos service names, because they serve the same function and because it 
makes things easier if the same name is used at all three layers.

>> 6) What is the IANA registration policy for gssapi-service-names?
>> The page doesn't tell and the GSSAPI specs don't appear to have
>> IANA considerations section.  Should this doc specify it?  Should the
>> guidance for protocol designers give advice on this?

That registry is older than RFC2434, and so doesn't have a carefully 
defined registration policy.  IMHO it would be inappropriate for this 
document to attempt to set one.  Hopefully the ongoing work in the KITTEN 
WG to clarify GSSAPI v2 will include specifying a registration policy for 
this registry, and I would expect that any such policy would be reviewed in 
the KITTEN, SASL, and KRB-WG working groups.

>> 7) Whether or not you are vulnerable to MITM attacks seems to depend on
>> the challenge/response methods used, so the below text seems to be
>> assumptive.

The text assumes that mechanisms which provide a security layer with 
integrity protection will bind that channel to the authentication used.

>> 7.b) Speaking of which, the document doesn't seem to give any guidance
>> (or I missed it) to the protocol designers on which kind of
>> challenge responses should be supported and why (see section 3.4),
>> particularly the security tradeoffs ?

No, I don't think the framework gives guidance to application developers on 
mechansim selection, and I don't think it should.  This document is the 
technical specification of what is supposed to be a mechanism-independent, 
applicaiton-agnostic framework, and as such should not be bound to specific 
mechansims.  I agree that advice from the security community on selection 
of SASL mechansims (and indeed, on choosing between SASL, GSS, EAP, etc) 
would be useful, but I don't think it belongs in this document.

In fact, I think there is some such work underway already, but I'm not 
going to spend the time to search for it just now.  Perhaps in a later 
followup...

>> 8) shouldn't there be some recommendations how to avoid the most
>> important passive attacks?
>>
>> 6.2.  Passive Attacks
>>
>>  Many mechanisms are subject to various passive attacks, including
>>  simple eavesdropping of unprotected credential information in
>>  mechanisms, such as PLAIN, to online and offline dictionary attacks.

You mean, other than not using those mechanisms, or using SASL-over-TLS as 
suggested in the first paragraph on page 18?  Does that text need to be 
expanded a bit?

>> 9) I don't know the precedent, but I'm not sure if it's appropriate to
>> include the URLs or addresses in an RFC.

Both the registry URL and the [email-masked] address are pretty stable 
references, so I don't see any problem with including them here.

>> Including the template to be
>> filled here is also suspect; would a better approach be advising
>> the IANA to include the template at a web page, and suggesting that
>> whoever wants to fill it, go to the IANA?

I don't believe this is the first document to do so; in fact, I believe 
RFC2222 includes the same template (so really, we are not creating a new 
registry here).

I believe what usually happens is that IANA copies the template out of the 
latest spec and includes it in the registry page.

I'm not sure that referring to the "SASL WG mailing list" is a good idea.

>> 10) The use of passive voice conceals who is allowed to change the status
>> of a mechanism.  Obviously the owner.  I guess the IESG can also do that
>> for any mechanism?  Can anyone else change another people's markings?
>> What's the RFC2434 requirement?  IETF consensus?  IESG Approval?

You appear to be speaking specifically to the text about declaring a 
mechansim "OBSOLETE", since I can't find anything else that's at all 
unclear.  Lacking any text to the contrary, I would expect this change to 
fall under the same rules as any other, as defined earlier in the same 
section.  Namely, only the owner may make changes, except that the IESG can 
change an owner.

>> 12) are these changes with respect to RFC 2222 backward-compatible?
>> If not, a transition strategy or a bit of warning might be warranted.
>> All in all, it might be a good idea to state explicitly whether
>> there are cases where 2222bis (due to new requirements for mechanisms,
>> etc.) would be incompatible with 2222.
>>
>> RFC 2222, by not stating the authorization identity string was a
>>  string of Unicode characters, let alone character data, implied the
>>  authorization identity string was a string of octets.
>>
>>  - The authorization identity string is now defined as a string of
>>    Unicode characters.  The NUL (U+0000) is prohibited.  While protocol
>>    specifications are responsible for defining the authorization
>>    identity form, as well as the Unicode string syntax and related
>>    semantics, mechanism specifications are responsible for defining how
>>    the Unicode string is carried in the authentication exchange.
>>
>>  The following technical change was made to the EXTERNAL mechanism:
>>
>>  - The authorization identity string is to be UTF-8 encoded.

This is a messy issue, and transition strategies, to the extent that they 
are needed, will depend on the specific application protocols involved.  I 
don't expect there are deployed applications for which this will actually 
matter very much (particularly WRT prohibiting NUL), but perhaps I am 
underestimating the scope of the problem.

>> editorial
>> ---------
>>
>>  If the outcome is successful and a data layer was negotiated, this
>>  layer is then installed.  Protocols may allow this data to be carried
>>  in the request message.  This applies as well to the following
>>  illustrations.
>>
>>  Some mechanisms specify that the first data sent in the authentication
>>  exchange is from the client to the server.  Protocols may provide an
>>  optional initial response field in the request message to carry this
>>  data.  Where the mechanism specifies the first data data sent in the
>>  exchange is from the client to the server, the protocol provides an
>>  optional initial response field, and the client uses this field, the
>>  exchange is shortened by one round-trip:
>>
>>      C: Request authentication exchange + Initial response
>>      <additional challenge/response messages>
>>      S: Outcome of authentication exchange
>>
>> ==> quite a bit of text duplication in the 2nd paragraph?  Basically you
>> say the same thing twice. Is this necessary/useful?

Actually, we don't, though I'll admit the text is poorly worded.  What it 
says is this:

(a) The mech can specify client-speaks-first
(b) The protocol can provide an optional initial response field
(c) If (a) and (b) are both true, and the client chooses to use the
    optional field, then you save a round trip [example].

>> ==> s/data data/data/
>>
>> ==> it is not 100% clear what you mean by the "data layer" and
>> "data to be carried" in the first paragraph?  Is this the same as the
>> Initial Response data in the second paragraph or something else?  If the
>> same, remove as duplicate; if not the same, maybe clarify briefly?

Ugh.  I'm pretty sure "data layer" should be "security layer".
I think the whole sentence containing "allow this data to be carried" 
should be struck entirely, as it is redundant with the next paragraph and 
meaningless without its antecedent, which appears there.

>>  In order to avoid interoperability problems due to differing
>>  normalizations, when a mechanism calls for character data is to be
>>  used as input to a cryptographic and/or comparison function, the
>>
>> ==> I cannot parse "calls for character data ..."

s/is to be used/to be used/

-- Jeff

To: [email-masked]
Cc: [email-masked]
Subject: A review of SASL base
From: Sam Hartman <[email-masked]>
Date: Tue, 05 Jul 2005 15:28:49 -0400
Sender: [email-masked]

Date: Tue, 5 Jul 2005 09:44:28 -0700
To: [email-masked]
From: Ted Hardie <[email-masked]>
Subject: Fwd: Re: SASL review?

Pekka's comments on the SASL docs.
				ted

>Date: Sat, 2 Jul 2005 16:41:21 +0300 (EEST)
>From: Pekka Savola <[email-masked]>
>To: Ted Hardie <[email-masked]>
>Subject: Re: SASL review?
>
>Feel free to pass the comments along and include me in the followups.
>
>.......
>
>I liked the spec, it was mostly very fluent to read and to understand. I don't think there are any showstoppers, but I noticed a number of places which could use improvement. As I've never read any SASL specs in the past, be gentle.
>
>(I wrote the comments as I read the spec, and added a few notes afterwards; there seemed to be some need for adding more forward pointers.)
>
>substantial
>-----------
>
>1) just an observation: it would be useful for those protocol designers
>planning to use SASL to specify in the exchanges how many roundtrips (and
>possibly additional bytes, but that's more variable) the exchanges are.  All
>the exchange examples have "additional challenge/response messages" but you don't
>say how many and what that depends on?
>
>(There seems to be some useful discussion in section 3.4.  Maybe it should state
>the minimum number of roundtrips (1?), and 3.4 should be referred from the the start
>of section 3 where you first mention "additional challenge/response messages"?)
>
>2) question on applicability of the latter exchange below.
>
>     C: Request authentication exchange
>      S: Initial challenge
>      C: Initial response
>      <additional challenge/response messages>
>      S: Outcome of authentication exchange with
>         additional data with success
>
>....
>
>      C: Request authentication exchange
>      S: Initial challenge
>      C: Initial response
>      <additional challenge/response messages>
>      S: Additional data challenge
>      C: Empty Response
>      S: Outcome of authentication exchange
>
>==> (too bad there aren't names for different kind of exchanges, it's difficult
>to refer which ones you're talking about..)  The spec is clear here, but I don't
>understand the usefulness of the second SASL conversation.  If the client's response
>must always be empty, there is no benefit in sending additional data prior to the
>outcome of the authentication exchange.  You're just wasting one roundtrip here.
>
>Why would anyone want to use the latter approach?  Does it need to be
>supported?  Are there restrictions on the first exchange which aren't
>spelled out?
>
>I also note that the description in the first exchange implies that sending additional data is allowed only when the authentication is successful, but I don't see why piggybacking additional data (if sending it is necessary) should be restricted to just the success? Contradicting that, section 3.6 does not specify that additional data may only be sent with a success, rather with any outcome.
>
>3) how could the client authenticate prior to knowing which authentication
>mechanism is should use for authentication?  Maybe the following requires
>clarification. (also s/mechanism/mechanisms/ ?)  Are you referring to some predefined
>default authentication method or the use of multiple authentications (sect 3.8)?
>
>  To detect downgrade attacks, a protocol may allow the client to
>  discover available mechanism subsequent to the authentication exchange
>  (and, hence, protected by any data security layer provided by
>  mechanism) so that downgrade attacks can be detected.
>
>4) below you don't specify what how the framework relates if the authentication
>outcome is successful, but the installation of the security layer fails for
>some reason.  Just to be on the safe side, should you specify or give some guidance
>that either (1) the security layer should be installed or somehow tested prior
>to reporting outcome (and failure would be, .., failure), or (2) if the installation
>of security layer fails for any reason, the session must be aborted using protocol
>specific means.
>
>What I'm worried about is that a sloppy implementation could report a successful outcome
>but the layer might not be installed due to whatever reasons, and the user would get a false sense of security.  (This seems to be discussed a bit later, in
>section 3.7)
>
>  If the outcome is successful and a security layer was negotiated, this
>  layer is then installed.  If the outcome is unsuccessful, or a
>  security layer was not negotiated, any existing security is left in
>  place.
>
>5) is it clear enough which registry are you referring to?
>Initially I guessed http://www.iana.org/assignments/service-names, but it turned out to be
>http://www.iana.org/assignments/gssapi-service-names.
>
>It also isn't clear why you mention (and refer to) GSSAPI here, as AFAICS these service names need to be used by any SASL mechanism whether it has any relation to GSSAPI or not.
>
>     1) A service name, to be selected from the IANA registry of "service"
>     elements for the GSSAPI host-based service name form [RFC2743].
>
>6) What is the IANA registration policy for gssapi-service-names?
>The page doesn't tell and the GSSAPI specs don't appear to have
>IANA considerations section.  Should this doc specify it?  Should the guidance for protocol designers give advice on this?
>
>7) Whether or not you are vulnerable to MITM attacks seems to depend on the challenge/response methods used, so the below text seems to be assumptive.  An attack example is challenge/response where the server doesn't authenticate the client, so an attacker which is doing MITM when SASL is exchanged can continue to perform MITM after the SASL exchange. I guess it's important to distinguish the cases "MITM attacker after SASL auth" and "MITM attacker modifying the SASL negotiation", as well as look at the security of different challenge/response methods provided.
>
>6.1.1. Man-in-the-middle Attacks
>
>  When the client selects a security layer with at least integrity
>  protection, this protects against an active attacker hijacking the
>  connection and modifying the authentication exchange to negotiate a
>  plain-text connection.  In this case, it is important that any
>  security-sensitive protocol negotiations be performed after
>  authentication is complete.  Protocols should be designed such that
>  negotiations performed prior to authentication should be either
>  ignored or revalidated once authentication is complete.
>
>7.b) Speaking of which, the document doesn't seem to give any guidance
>(or I missed it) to the protocol designers on which kind of
>challenge responses should be supported and why (see section 3.4),
>particularly the security tradeoffs ?
>
>8) shouldn't there be some recommendations how to avoid the most important
>passive attacks?
>
>6.2.  Passive Attacks
>
>  Many mechanisms are subject to various passive attacks, including
>  simple eavesdropping of unprotected credential information in
>  mechanisms, such as PLAIN, to online and offline dictionary attacks.
>
>9) I don't know the precedent, but I'm not sure if it's appropriate to
>include the URLs or addresses in an RFC.  Including the template to be
>filled here is also suspect; would a better approach be advising
>the IANA to include the template at a web page, and suggesting that
>whoever wants to fill it, go to the IANA?   That way, if this spec is
>revised in the future and the template changes, the users (who might be
>looking at an old spec) are always pointed to the latest
>version of the template.
>
>7.1.  SASL Mechanism Registry
>
>  SASL mechanism registry is maintained by IANA.  The registry is
>  currently available at
>  <http://www.iana.org/assignments/sasl-mechanisms>.
>...
> and sending it via electronic mail to <[email-masked]>.
>...
>7.1.2.  Comments on SASL Mechanism Registrations
>
>  Comments on registered SASL mechanisms should first be sent to the
>  "owner" of the mechanism and/or to the SASL WG mailing list.
>
>  Submitters of comments may, after a reasonable attempt to contact the
>  owner, request IANA to attach their comment to the SASL mechanism
>  registration itself by sending mail to <[email-masked]>.  At IANA sole
>  discretion, IANA may attach the comment to the registration SASL
>  mechanism.
>
>10) The use of passive voice conceals who is allowed to change the status
>of a mechanism.  Obviously the owner.  I guess the IESG can also do that for
>any mechanism?  Can anyone else change another people's markings?  What's the
>RFC2434 requirement?  IETF consensus?  IESG Approval?
>
>  SASL mechanism registrations may not be deleted; mechanisms which are
>  no longer believed appropriate for use can be declared OBSOLETE by a
>  change to their "intended usage" field; such SASL mechanisms will be
>  clearly marked in the lists published by IANA.
>
>11) normative reference issues (for the future).  I think this spec
>is intended to be recycled to Draft Standard after being 6 months at
>PS.  Please note that the normative references are at PS, so this spec
>cannot be moved to DS before these also move forward, or some other
>solution is found.
>
>  [RFC2743]     Linn, J., "Generic Security Service
>                Application Program Interface, Version 2, Update 1", RFC
>                2743, January 2000.
>
>  [RFC3454]     Hoffman, P. and M. Blanchet, "Preparation of
>                Internationalized Strings ('stringprep')", RFC 3454,
>                December 2002.
>
>  [RFC4013]     Zeilenga, K., "SASLprep: Stringprep Profile for User
>                Names and Passwords", RFC 4013, February 2005.
>
>12) are these changes with respect to RFC 2222 backward-compatible?
>If not, a transition strategy or a bit of warning might be warranted.
>All in all, it might be a good idea to state explicitly whether
>there are cases where 2222bis (due to new requirements for mechanisms, etc.)
>would be incompatible with 2222.
>
> RFC 2222, by not stating the authorization identity string was a
>  string of Unicode characters, let alone character data, implied the
>  authorization identity string was a string of octets.
>
>  - The authorization identity string is now defined as a string of
>    Unicode characters.  The NUL (U+0000) is prohibited.  While protocol
>    specifications are responsible for defining the authorization
>    identity form, as well as the Unicode string syntax and related
>    semantics, mechanism specifications are responsible for defining how
>    the Unicode string is carried in the authentication exchange.
>
>  The following technical change was made to the EXTERNAL mechanism:
>
>  - The authorization identity string is to be UTF-8 encoded.
>
>
>editorial
>---------
>
>  If the outcome is successful and a data layer was negotiated, this
>  layer is then installed.  Protocols may allow this data to be carried
>  in the request message.  This applies as well to the following
>  illustrations.
>
>  Some mechanisms specify that the first data sent in the authentication
>  exchange is from the client to the server.  Protocols may provide an
>  optional initial response field in the request message to carry this
>  data.  Where the mechanism specifies the first data data sent in the
>  exchange is from the client to the server, the protocol provides an
>  optional initial response field, and the client uses this field, the
>  exchange is shortened by one round-trip:
>
>      C: Request authentication exchange + Initial response
>      <additional challenge/response messages>
>      S: Outcome of authentication exchange
>
>==> quite a bit of text duplication in the 2nd paragraph?  Basically you say
>the same thing twice. Is this necessary/useful?
>
>This appears to be a stylistic issue, as the following
>paragraphs have the same as well.
>
>==> s/data data/data/
>
>==> it is not 100% clear what you mean by the "data layer" and
>"data to be carried" in the first paragraph?  Is this the same as the Initial
>Response data in the second paragraph or something else?  If the same,
>remove as duplicate; if not the same, maybe clarify briefly?
>
>  Where the mechanism specifies the server is to return additional data
>  to the client with a successful outcome and and this field is
>
>==> s/and and/and/
>
>  SASL mechanisms names are registered as discussed in Section 7.1.
>
>==> s/mechanisms/mechanism/
>
>  be provided, and negotiation of a maximum cipher-text buffer size each
>  size is able to receive in the layer (see Section 3.6).
>
>==> s/each size/each side/
>
>    - the identity associated with the client's credentials are not
>      authorized to act as the requested authorization identity,
>
>==> s/are/is/
>
>  7) If the protocol supports other layered security services, such as
>     Transport Layer Security (TLS) [RFC2246], the specification MUST
>     prescribe the order in which security layers are applied to
>     protocol data.
>
>==> the revision of TLS spec appears to be almost complete
>(draft-ietf-tls-rfc2246-bis), so maybe it could be referred, though
>for the intents and purposes of this reference this should not matter.
>
>  1) The name of the mechanism (see Section 3.1).  This name MUST be
>     registered as discussed in Section 8.1.
>
>==> you mean sect 7.1..
>
>  In order to avoid interoperability problems due to differing
>  normalizations, when a mechanism calls for character data is to be
>  used as input to a cryptographic and/or comparison function, the
>
>==> I cannot parse "calls for character data ..."
>
>  generation of any long-term cryptographic keys or hashes as there is
>  no requirement that the authorization identity string be be
>  non-canonical.
>
>==> s/be be/be/
>
>  services.  It is also hoped that future mechanisms will provide more
>  advance data security services like re-keying (see Section 6.1).
>
>==> s/advance/advanced/
>
>  Administrative limits on security layers lifetime may take the form of
>
>==> s/layers/layers'/ (similar later in the paragraph)
>
>      Security considerations: See RFC XXXX, section 9.
>      Published specification (optional, recommended): RFC XXXX
>
>==> it may be blindingly obviously, but should you say that XXXX
>refers to the number given to this draft? :)
>
>    Security considerations: See RFC XXXX, section 9.
>
>==> did you mean section 7 or appendix A?
>Using xml2rfc would help you with these ;-)