Subject: Update on RFC 2222bis (soon to be draft-ietf-sasl-rfc2222bis-06.txt)

From: Alexey Melnikov <[email-masked]>
Date: Wed, 11 Feb 2004 16:17:08 +0000

I've recently submitted draft-ietf-sasl-rfc2222bis-05 which addressed 
most of the editorial issues raised by Kurt Zeilenga.

I am planning to submit a new revision before the submission deadline.

Question:

Kurt raised a question about removing the following paragraph from the 
Security Considerations section. Sam has agreed with Kurt.
(This text is not something specific to SASL. After discussing this 
issue in relationship to XMPP, I thought that it would be a nice idea to 
add it)

   SASL implementations might be subject to online dictionary attacks
   (e.g. username harvesting, password guessing). In order to mitigate
   the attacks a server implementation is encouraged to implement a
   policy when after a number of failed authentication attempts it
   returns errors to all subsequent authentication attempts on the same
   connection.  Alternatively, the server may implement a policy whereby
   the connection is dropped after a number of failed authentication
   attempts. If a server implementation chooses to do so, it should not
   drop the connection until at least 3 authentication attempts have
   failed.

Before I do any changes I would like to hear at least 2 more voices in 
favor of keeping or removing this paragraph.

The changes between 05 and 06 are outlined below:

 1). New section 5.2 was introduced that list guidelines for a SASL 
mechanism designer.
 
5.2.  Mechanism profile guidelines

   Designers of new SASL mechanism should be aware of the following
   issues:

   1) Authorization identity.

   While some legacy mechanisms are incapable of transmitting an
   authorization identity (which means that for these mechanisms the
   authorization identity is always the empty string), newly defined
   mechanisms SHOULD be capable of transmitting a non-empty
   authorization identity. See also section 4.2.

   2) Character string issues

   Authentication mechanisms SHOULD encode character strings in UTF-8
   [UTF-8] (see [CHARSET-POLICY] for IETF policy regarding character
   sets in IETF protocols).  In order to avoid interoperability problems
   due to differing normalizations, when a mechanisms specifies that
   character data is to be used as input to a cryptographic and/or
   comparison function, the mechanism specification MUST detail how the
   data is to be represented, including any normalizations or other
   preparations, to ensure proper function.  Designers of mechanisms
   SHOULD use the "SASLprep" profile [SASLPrep] of the "stringprep"
   algorithm [StringPrep] where applicable.

   The preparation can be potentially performed on the client end (upon
   getting user input or retrieving a value from configuration) or on
   the server end (upon receiving the value from the client, retrieving
   a value from its authentication database or generating a new value in
   order to store in in the authentication database).  SASL mechanisms
   must define which entity (or entities) must perform the preparation.
   If preparation fails or results in an empty string, the entity doing
   the preparation SHALL fail the authentication exchange.

   Implementation note: A server end can be represented by multiple
   processes. For example, it may consist of the server process itself
   that communicated with a client, and a command line utility (a server
   agent) that is able to store passwords/hashes in a database that can
   be later used by the server. For the server agent the requirement to
   "fail the authentication exchange" should be interpreted as a
   requirement to refuse to store the data in the database.

2). I've added a SASL profile requirement that tells that if the 
protocol supports an initial response, it must specify how an empty 
initial response is encoded.
This was prompted by a recent discussion on XMPP mailing list.

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

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

Personal Home Page: http://www.melnikov.ca
__________________________________________

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 11 Feb 2004 10:50:27 -0600

> favor of keeping or removing this paragraph.

Hi Alexey,

This seems like an issue that should be addressed by the using protocol
(e.g., the XMPP specs should say something about this), not something
that should be addressed by SASL. So I agree with Kurt and Sam.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.php

---

From: Rob Siemborski <[email-masked]>
Date: Wed, 11 Feb 2004 12:36:11 -0500 (EST)

> that should be addressed by SASL. So I agree with Kurt and Sam.

I also agree -- this isn't something specific to sasl, it is more
applicable to the application's specific authentication policy.

-Rob

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 11 Feb 2004 17:44:51 +0000

>applicable to the application's specific authentication policy.
Ok, we have 4 votes. Seems like a consensus. I will remove this.

Alexey

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 11 Feb 2004 13:44:41 -0500

On Wednesday, February 11, 2004 16:17:08 +0000 Alexey Melnikov 
<[email-masked]> wrote:

> Security Considerations section. Sam has agreed with Kurt. (This text is
> not something specific to SASL. After discussing this issue in
> relationship to XMPP, I thought that it would be a nice idea to add it)
>

I'll have to agree with others here.  Particularly, since SASL negotiation 
is acheived via an exchange of data which it is the application protocol's 
responsibility to transport in an application-specific manner, the SASL 
implementation is in no position to detect whether two exchanges occur "on 
the same connection", let alone drop a connection.  This is clearly an 
issue for the application protocol and for site policy.

-- Jeff

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 11 Feb 2004 10:50:27 -0600

Hi Alexey,

Peter

---

From: Rob Siemborski <[email-masked]>
Date: Wed, 11 Feb 2004 12:36:11 -0500 (EST)

-Rob

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 11 Feb 2004 17:44:51 +0000

Alexey

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 11 Feb 2004 13:44:41 -0500

-- Jeff