Subject: ANONYMOUS

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

[anon] section 4 (Security Considerations) says:

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

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

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

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

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

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

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

Also,

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

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

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

That reminds me:

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

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

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 15 Dec 2003 19:28:44 +0100

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

OK.

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

-- 
Hallvard

---

From: Sam Hartman <[email-masked]>
Date: Mon, 15 Dec 2003 13:20:08 -0500

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

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

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

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

---

From: Sam Hartman <[email-masked]>
Date: Mon, 15 Dec 2003 14:13:11 -0500

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

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

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 15 Dec 2003 11:09:01 -0800

>docs/specifications, explain what behavior you have and why you chose

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 15 Dec 2003 12:00:24 -0800

>not an implementation imperative justified for security reasons?

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

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

Kurt

---

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

Also,

That reminds me:

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 15 Dec 2003 19:28:44 +0100

OK.

-- 
Hallvard

---

From: Sam Hartman <[email-masked]>
Date: Mon, 15 Dec 2003 13:20:08 -0500

---

From: Sam Hartman <[email-masked]>
Date: Mon, 15 Dec 2003 14:13:11 -0500

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 15 Dec 2003 11:09:01 -0800

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 15 Dec 2003 12:00:24 -0800

Kurt