Subject: comments on draft-ietf-sasl-anon-00

From: Philip Guenther <[email-masked]>
Date: Wed, 19 Feb 2003 23:54:04 -0800

The syntax for UTF-8 characters in the draft permits "non-shortest form"
encodings and encodings for characters outside the range of the Unicode
character set.  Neither may be interpreted by a program conforming to
the Unicode 3.2 specification, which the draft references.

Paragraph 5 of section 4 (security consideration), suggests the use of
an idle timeout on servers that place a limit on the number of
concurrent anonymous users in order to combat a denial-of-service
attack.  As keeping a connection from being considered idle will
generally require simply sending a request (possibly even a malformed
request), it's unlikely that an idle timeout will actually prevent an
intentional DOS attack from succeeding.  A hard timeout on connection
duration, network access limitations, or (where appropriate) a limit on
the number of requests permitted on an anonymous connection may be
required to provide a minimal service guarantee in the face of malicious
access.

The ANONYMOUS mechanism does not provide a means for the client to
supply an optional realm in which the anonymous authentication should
take place.  This makes the ANONYMOUS mechanism unusable by servers that
support multiple realms on a single communication end-point; it cannot
supplant the "anonymous@domain" login supported by, for example, some
IMAP servers.

Philip Guenther

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 20 Feb 2003 05:33:31 -0700

Philip Guenther wrote:

> support multiple realms on a single communication end-point;

See below.

> it cannot supplant the "anonymous@domain"

Which conforms to the syntax for "email", isn't it?

> login supported by, for example, some IMAP servers.

Server is not supposed to verify "email", so anything that looks like
"email" just works fine.

Regards,
Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 20 Feb 2003 10:04:34 -0800

At 11:54 PM 2/19/2003, Philip Guenther wrote:
>encodings

I'm not exactly sure what you are referring to here.  The
draft says that the trace information is transferred as
string of UTF-8 encoded Unicode characters.  A non-shorted
form UTF-8 encoding of a Unicode character is invalid per
RFC 2247.  I believe draft-yergeau-rfc2279bis-04.txt is
more clear on this, so I'll change the reference.

If, however, you mean that the string of Unicode characters
is not normalized using an algorithm which produces the
minimum number of code points, yes.  This is as intended.

>and encodings for characters outside the range of the Unicode
>character set.

Unassigned code points may be transferred.  I will clarify
that as I noted in another post.  However, I believe the
specification is clear that characters "outside the range",
e.g. not in the repertoire of characters, are invalid.

>Neither may be interpreted by a program conforming to

Which is exactly why the specification restricts the string
to a particular repertoire of characters.

Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 20 Feb 2003 11:24:58 -0700

> more clear on this, so I'll change the reference.

I believe Philip was referring to ABNF which allows for overlong UTF8
sequences.

Regards,
Alexey

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 20 Feb 2003 11:09:07 -0800

>I believe Philip was referring to ABNF which allows for overlong UTF8

I gather that you are saying that ABNF is not precise enough.
(please correct me if I wrongly gathered).  While I can
see that if you ignored all other text and the comments within
the ABNF, one could presume that the message, in hex, 0C 30
was valid.... if one actually ignored all the other text
and the comments they could also presume that the invalid
messages 00 (in hex), foo"bar"@x (in ASCII), and many others
were valid.

Obviously, the grammar is not intended to be taken out of
context.  It is provided as a tool for understanding the
text of the specification.
  
Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 20 Feb 2003 12:18:34 -0700

> I gather that you are saying that ABNF is not precise enough.

Correct.

> text of the specification.

I've seen the version of the grammer that deals with overlong sequence.
Check draft-yergeau-rfc2279bis-04.txt section 4.

Regards,
Alexey Melnikov

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 20 Feb 2003 11:30:21 -0800

At 11:54 PM 2/19/2003, Philip Guenther wrote:
>take place.

Correct, it doesn't.  (The trace information has no semantical
value.)

>This makes the ANONYMOUS mechanism unusable by servers that

Maybe so. 

Are you asking for the WG to consider adding realm support
to ANONYMOUS mechanism?  Or asking the WG to consider
clarifications to the ANONYMOUS mechanism that it is not
applicable in scenarios allowing different anonymous
associations to be established?

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 20 Feb 2003 11:55:11 -0800

Okay, how about I replace the grammar and the paragraph before
it as follows:

  A formal grammar for the client message using Augmented BNF [ABNF]
  is provide below as a tool for understanding this technical
  specification.

  message     = [ email / token ]
                ;; MUST be prepared in accordance with Section 2

  UTF1        = %x00-3F / %x41-7F ;; less '@' (U+0040)
  UTF2        = %xC2-DF UTF0        
  UTF3        = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /               
                %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)               
  UTF4        = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /                 
                %xF4 %x80-8F 2(UTF0)          
  UTF0        = %x80-BF

  TCHAR       = UTF1 / UTF2 / UTF3 / UTF3 / UTF4                  
              ;; any UTF-8 encoded Unicode character
              ;; except '@' (U+0040)

  email       = addr-spec
              ;; as defined in [IMAIL], except with no free
              ;; insertion of linear-white-space, and the
              ;; local-part MUST either be entirely enclosed in
              ;; quotes or entirely unquoted

  token       = 1*255TCHAR

and add an appropriate acknowledgement.

Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 20 Feb 2003 13:09:57 -0700

> Okay, how about I replace the grammar and the paragraph before

This mostly works, see below.

>               ;; any UTF-8 encoded Unicode character

Hmm, this suggests a typo in draft-yergeau-rfc2279bis-04.txt (UTF3 is
shown twice).

Also note, that this doesn't have UTF5 & UTF6 that you currently have:

      UTF5        = %xF8-FB 4(UTF0)
      UTF6        = %xFC-FD 5(UTF0)

(but they have to be cleaned up to prevent overlong sequences).

Regards,
Alexey Melnikov

---

From: Philip Guenther <[email-masked]>
Date: Thu, 20 Feb 2003 11:56:34 -0800

"Kurt D. Zeilenga" <[email-masked]> writes:
...
>messages 00 (in hex), foo"bar"@x (in ASCII), and many others

No, the latter is not valid by the grammar.

My dislike for the current formulation is two-fold:

TCHAR, as defined, isn't actually "any UTF-8 encoded Unicode character
except '@' (U+0040)" as described in the comment.  The UTF5 and UTF6
definitions do not match any legal UTF-8 character and the UTF3 and UTF4
definitions match illegal UTF-8 characters.

I would prefer to find all the restrictions on what characters are legal
in a token in a single location.  The grammar could simply define TCHAR
as a UTF-8 encoded character (perhaps using the productions in the draft
Alexey mentioned) while the stringprep profile could handle all the
restrictions on content at the level of Unicode characters.  Yes, this
makes the grammar ambiguous, but even rfc2822, the first 'target' for
ABNF, has an amibiguous grammar that is only resolved by semantic
restrictions in the general text.

>text of the specification.

As always, clarity and correctness are the goals.  IMHO, defining a
non-terminal that's neither a superset nor a subset of UTF-8, with
additional restrictions elsewhere, makes it more difficult to
understand.

Philip Guenther

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 20 Feb 2003 12:23:36 -0800

>required to provide a minimal service guarantee in the face of malicious

I'm thinking the problem starts in paragraph 4 with the
suggestion that servers should restrict the numbers of
anonymous users.  How about replacing both paragraph 4 and
5 with:

  If the anonymous user can run many expensive operations (e.g., an
  IMAP SEARCH BODY command), this could enable a denial of service 
  attack. Servers are encouraged to reduce the priority of anonymous
  users or limit their resource usage.

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 20 Feb 2003 12:32:52 -0800

>Hmm, this suggests a typo in draft-yergeau-rfc2279bis-04.txt (UTF3 is

Or an error on my part.  UTF3 should only be listed once here.

>(but they have to be cleaned up to prevent overlong sequences).

Yes.  There are a couple of 4 v 6 octet cleanups to be made as well.

---

From: Philip Guenther <[email-masked]>
Date: Thu, 20 Feb 2003 12:25:16 -0800

...
>associations to be established?

The latter, not the former.

While a mechanism that supports multiple anonymous identities may have
its place in the SASL 'cookbook', I don't currently have a clear idea of
what would be generally useful in that direction to suggest changing the
current ANONYMOUS mechanism at this time.

Philip Guenther

---

From: Philip Guenther <[email-masked]>
Date: Thu, 20 Feb 2003 12:26:41 -0800

>anonymous users.  How about replacing both paragraph 4 and
<elided>

Looks good to me.

Philip Guenther

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 20 Feb 2003 13:39:15 -0700

"Kurt D. Zeilenga" wrote:

> to ANONYMOUS mechanism?

Just to clarify: the solution can be as simple as saying that domain part
of an "email" can be parsed by the server in order to figure out realm.

> Or asking the WG to consider

Cheers,
Alexey

---

From: Philip Guenther <[email-masked]>
Date: Thu, 20 Feb 2003 12:34:41 -0800

...
>of an "email" can be parsed by the server in order to figure out realm.

I don't think an rfc should suggest automated parsing of trace
information.  Such a practice would arguably make the non-address form a
second-class citizen and possibly lead to the use of placeholder
addressees when a general text string would have been more appropriate.

Philip Guenther

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 20 Feb 2003 12:52:24 -0800

>of an "email" can be parsed by the server in order to figure out realm. 

I would rather clarify that the trace information has
no semantical value.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 20 Feb 2003 12:49:52 -0800

>The latter, not the former.

Okay.  I suggest you (or another proponent of the clarification)
offer text for the WG to consider.

Kurt

---

From: Philip Guenther <[email-masked]>
Date: Fri, 21 Feb 2003 13:04:07 -0800

>offer text for the WG to consider.

How about the following sentence for addition to section 1, perhaps
right after the 'no security layer' paragraph?

"The ANONYMOUS mechanism is not applicable to servers that support
 multiple anonymous identities and that do not have enough information
 from before the SASL exchange (for example, from previous protocol
 exchanges or the connection addresses) to determine which identity to
 use."

Philip Guenther

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 21 Feb 2003 13:49:52 -0800

> exchanges or the connection addresses) to determine which identity to

A few comments.

I think "anonymous identity" is an oxymoron.  And, of course,
the ANONYMOUS mechanism is not intended to determine any identity.

One possible alternative wording, which would at avoid these issues,
would be:
        The ANONYMOUS mechanism is not applicable where
        application-level protocols and/or their implementations
        offer more than one kind/type/level of anonymous
        associations between the client and the server as the
        mechanism provides no facility to indicate the kind/type/level
        of associate desired.  No semantics should be associated
        with the trace information.

Kurt

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 Feb 2003 22:24:30 -0500

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

    >> of an "email" can be parsed by the server in order to figure out realm. 

    Kurt> I would rather clarify that the trace information has
    Kurt> no semantical value.

    Kurt> Kurt 

I tend to agree that if a clarification is made it should be in the
direction of no semantic value for the trace component.

This is just another rehash of the authorization name vs
authentication name problem all over again.  There is exactly one
anonymous authentication name in the universe.  It may have trace
information associated with it but anonymous logins are all the same.

The anonymous identity may be authorized for several different
authorization identities--these identities may even correspond to
different realms.

Our current mechanism does not provide a way to express this
authorization identity and expanding the mechanism now is probably a
bad idea and possible out of scope.

It may be appropriate for some future anonymous mechanism to support
authorization identity if that is useful.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 20 Feb 2003 05:33:31 -0700

See below.

Regards,
Alexey

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 20 Feb 2003 10:04:34 -0800

Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 20 Feb 2003 11:24:58 -0700

Regards,
Alexey

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 20 Feb 2003 11:09:07 -0800

Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 20 Feb 2003 12:18:34 -0700

Correct.

Regards,
Alexey Melnikov

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 20 Feb 2003 11:30:21 -0800

Maybe so. 

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 20 Feb 2003 11:55:11 -0800

email       = addr-spec

  token       = 1*255TCHAR

Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 20 Feb 2003 13:09:57 -0700

UTF5        = %xF8-FB 4(UTF0)
      UTF6        = %xFC-FD 5(UTF0)

Regards,
Alexey Melnikov

---

From: Philip Guenther <[email-masked]>
Date: Thu, 20 Feb 2003 11:56:34 -0800

Philip Guenther

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 20 Feb 2003 12:23:36 -0800

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 20 Feb 2003 12:32:52 -0800

---

From: Philip Guenther <[email-masked]>
Date: Thu, 20 Feb 2003 12:25:16 -0800

...

Philip Guenther

---

From: Philip Guenther <[email-masked]>
Date: Thu, 20 Feb 2003 12:26:41 -0800

<elided>

Looks good to me.

Philip Guenther

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 20 Feb 2003 13:39:15 -0700

Cheers,
Alexey

---

From: Philip Guenther <[email-masked]>
Date: Thu, 20 Feb 2003 12:34:41 -0800

...

Philip Guenther

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 20 Feb 2003 12:52:24 -0800

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 20 Feb 2003 12:49:52 -0800

Kurt

---

From: Philip Guenther <[email-masked]>
Date: Fri, 21 Feb 2003 13:04:07 -0800

Philip Guenther

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 21 Feb 2003 13:49:52 -0800

A few comments.

Kurt

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 Feb 2003 22:24:30 -0500

Kurt> Kurt