Subject: Half-anonymous authentication

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 6 Apr 2004 22:05:16 +0200

As far as I can tell, a SASL authentication method may make the
authentication ID _or_ the authorization ID anonymous, but not the
other one.  Is that correct?  Should it be correct?

Non-anonymous authentication ID + anonymous authorization ID seems
useful for the ANONYMOUS mechanism.  Currently, servers that implement
ANONYMOUS must make a special case to ensure that they don't give any
access to apparently authenticated users who used this method.  However,
if ANONYMOUS sets the authorization ID to anonymous, servers will give
anonymous access by default.  That seems a lot safer, though whether it
is a good idea or not depends on what the mechanism is intended to be
used for.  I suggested that some time ago, but got no response - it
drowned in another subthread.

OTOH, I can't think of a use for anonymous authentication ID with
non-anonymous authorization ID, other than those which could just as
well be fulfilled by setting the authentication ID as well.  Like
EXTERNAL.  Don't know if that is any reason to forbid it, though.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 6 Apr 2004 22:25:40 +0200

Uh... OTOH, on second reading of rfc2222bis, I can't see that a
mechanism may make either ID anonymous at all.  It was just so "obvious"
that it could do so, that I didn't notice that it couldn't.  Anyway, is
that intended?

I wrote:

> other one.

Also a bit unfortunate wording.  Of course it may make both
non-anonymous (or anonymous?) too:-)

-- 
Hallvard

---

From: Sam Hartman <[email-masked]>
Date: Wed, 07 Apr 2004 12:41:04 -0400

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

    Hallvard> Uh... OTOH, on second reading of rfc2222bis, I can't see
    Hallvard> that a mechanism may make either ID anonymous at all.
    Hallvard> It was just so "obvious" that it could do so, that I
    Hallvard> didn't notice that it couldn't.  Anyway, is that
    Hallvard> intended?

I believe the authorization ID of all users authenticated using the
anonymous mechanism is the same.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 7 Apr 2004 19:30:40 +0200

> anonymous mechanism is the same.

Not that I can see.  However, Security Considerations refer to 'the
anonymous user'.  Looks like a good idea for the section which defines
the mechanism.

However, for SASL in general I was thinking of explicitly setting up the
connection to have the same authorization or authentication ID as
unauthenticated connections, not setting them to a special 'anonymous
user'.  The former is called 'anonymous' in LDAP.  Sorry about bringing
the term over here without explaining.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 09 Apr 2004 17:06:16 -0700

>anonymous mechanism is the same.

"users authenticated using the anonymous mechanism", I think,
is a odd phrase.  The anonymous mechanism doesn't provide any
authentication service.  (Not all SASL mechanisms provide
authentication services.)  I also find it odd the implication
(in Hallvard's comments) that an anonymous user has an
established identity.  I take the view that an anonymous user
is one whose's identity has not been established (or is
concealed).

While some implementations (and maybe even some application
protocols) might associate a particular identity representation
to users who are anonymous (have no established identity), this
by no means implies that anonymous mechanism establishes
(authenticates) the identity of the user.  It doesn't.

Hallvard: I'm not sure what your question is (in your last
response).  If your asking whether SASL itself or the
ANONYMOUS mechanism defines a particular identity representation
to refer to anonymous users (users which have no established
identity), I think the answer is no.  If your asking whether
SASL or ANONYMOUS explicitly provides a facility for a user
to authenticate oneself and assume the authorization of an
anonymous user, I think the answer is no.

I note, nothing explicitly prevents application protocol
specifications from providing such facilities, including
by means of defining a particular identity representation
to refer to users who have not established their identity.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 10 Apr 2004 16:53:53 +0200

Kurt D. Zeilenga writes:
> authentication services.)

That's not what rfc2222bis says.  It describes SASL mechanisms as
authentication mechanisms, and describes everything about these in terms
of authentication.  So according to rfc2222bis, ANONYMOUS is an
authentication mechanism.  One which doesn't authenticate, from what you
say.  (BTW, note the command 'A002 AUTHENTICATE ANONYMOUS' in the
example in the ANONYMOUS draft.)

Anyway, at first I thought this meant the identity sent with ANONYMOUS
had to be the authentication ID, but I now notice that this is wrong.

However, I think the ANONYMOUS draft does need to say explicitly how it
affects the authentication and authorization IDs.

Also, I now wonder how clients typically implement ANONYMOUS.  If they
support several SASL mechanisms, do clients expect the identity to send
with ANONYMOUS in the same command line option or whatever which they
use for the authentication IDs for other SASL mechanisms, or do they use
some other field?

Anyway, 

> I also find it odd the implication (in Hallvard's comments) that an
> anonymous user has an established identity.  I take the view that an
> anonymous user is one whose's identity has not been established

See above.  Also, Sam's statement that all ANONYMOUS users have the
_same_ authorization ID, not _no_ authorization ID.  Which made me
realize that anonymous auth is not a SASL term, but one I'm used to from
LDAP, where it means the same as no auth.  OTOH, FTP (at least on Unix)
implements anonymous auth the way Sam describes: A specific user on the
server's system, with limited access.

> (or is concealed).

Oh dear.  I wish you hadn't added that.  Which identity do you mean?
Authentication or authorization identity, after all?  And who is
it concealed from?  The server, or other users?

> anonymous user, I think the answer is no.

Almost...  I'm wondering if SASL even allows an authentication
mechanism to revert the authentication and authorization IDs back
to unauthenticated - that is, the same state as before the first
authentication.  But perhaps it would be problematic if the did,
since it would mess up for protocols that require authentication.
Maybe an 'anonymous user' is a better concept, which protocols
can treat either the same way as unauthenticated or as a normal
user with limited access.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 10 Apr 2004 09:12:40 -0700

At 07:53 AM 4/10/2004, Hallvard B Furuseth wrote:
>of authentication.

Which is a problem.  rfc2222bis should be likely use more
generic terms, like "SASL mechanism" when referring to a
SASL mechanism.

>So according to rfc2222bis, ANONYMOUS is an authentication mechanism.

rfc2222bis shouldn't imply that all SASL mechanisms provide
authentication services.

>One which doesn't authenticate, from what you say.

I would hope it obvious that ANONYMOUS does not authenticate anything.

>had to be the authentication ID, but I now notice that this is wrong.

The only information ANONYMOUS transfers is for trace purposes.
It has no semantical value to the mechanism.

>affects the authentication and authorization IDs.

How any mechanism affects authentication and authorization IDs
outside of the mechanism is beyond the scope of that mechanism.
It should be obvious that this mechanism does not itself
establish an authentication identity nor transfer an authorization
identity.  However, if more clarity is needed, I would suggest
replacing the paragraph: 
  This mechanism does not provide a security layer.
with:
  This mechanism does not establish the identity of the
  client (or user) nor the server (or service); does not
  support transfer of an authorization identity; nor
  provide a security layer.

and relocate this paragraph more towards the top of the section.

>use for the authentication IDs for other SASL mechanisms, or do they use

I suggest you look at some existing implementations.  But
I would hope the user would not be asked or expected to
provide their credentials (or portions of their credentials)
when using this mechanism.

>_same_ authorization ID, not _no_ authorization ID.

I think Sam's statement is problematic in that implies that the
mechanism is establishing or authenticating the user's identity.
The server might be associating an identity with anonymous
users, but the server certainly is not establishing
or authenticating the user's identity.

>Which made me realize that anonymous auth is not a SASL term, but one I'm used to from

But it should be clear that anonymous methods in LDAP, FTP,
and elsewhere are not authenticating the user's identity.

>> (or is concealed).
>
>Oh dear.  I wish you hadn't added that.

RFC 2828:
   $ anonymous
      (I) The condition of having a name that is unknown or concealed.

>Which identity do you mean?

The identity of the user (or a user).

>Authentication or authorization identity, after all?

Both, as they both refer to identities of users.

>And who is it concealed from?  The server, or other users?

In this case, they are concealed from (at least) the server.

>authentication.

SASL doesn't support "revert", it supports moving to a new
authorization state.  That new authorization state could be
an anonymous one (one where the identity of the user is not
established (authenticated)).

>But perhaps it would be problematic if the did,

ANONYMOUS allows protocols which previously required authentication
of the user to support processing without authentication of the
user.  That is, it allows the "authenticate" command to be used
in a fashion which doesn't actually authenticate anything.

Which, BTW,
>(BTW, note the command 'A002 AUTHENTICATE ANONYMOUS' in the

is what's happening here.  This AUTHENTICATE command does not
cause anything to be authenticated.

---

From: Sam Hartman <[email-masked]>
Date: Sat, 10 Apr 2004 12:58:01 -0400

Hallvard> See above.  Also, Sam's statement that all ANONYMOUS
    Hallvard> users have the _same_ authorization ID, not _no_
    Hallvard> authorization ID.  Which made me realize that anonymous
    Hallvard> auth is not a SASL term, but one I'm used to from LDAP,
    Hallvard> where it means the same as no auth.  OTOH, FTP (at least
    Hallvard> on Unix) implements anonymous auth the way Sam
    Hallvard> describes: A specific user on the server's system, with
    Hallvard> limited access.

I think my statement is still generally true.  It may happen that the
authorization ID of anonymous users is also the same as the
authorization ID of users who have engaged in no authentication
exchange.

It may be the case (and generally is) that the authorization ID of
anonymous users cannot be represented as a string transmitted over the
wire.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Sat, 10 Apr 2004 13:00:01 -0400

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

    Kurt> Which is a problem.  rfc2222bis should be likely use more
    Kurt> generic terms, like "SASL mechanism" when referring to a
    Kurt> SASL mechanism.

I don't tend to agree with this.  IT seems that viewing anonymous
authentication as authentication is a smaller change at this date than
assuming not all SASL mechanisms authenticate.

>From a practical standpoint, I believe they are isomorphic models.
Should I would prefer to choose the model that is most consistent with
our documents.

--Sam

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 10 Apr 2004 19:33:31 +0200

Kurt D. Zeilenga writes:
>>> The anonymous mechanism doesn't provide any
>> authentication mechanisms, and describes everything about these in
>> terms of authentication.
> 

rfc2222 does the same thing.  Did it incorrectly describe existing
implementations, or were mechanisms like ANONYMOUS added later?

> I would hope it obvious that ANONYMOUS does not authenticate anything.

If it affects the authorization or authentication IDs, it... well,
un-authenticates, I suppose.  If it doesn't, it seems to violate rfc2222
and rfc2222bis.

> outside of the mechanism is beyond the scope of that mechanism.

Beyond the scope of any mechanism, I think.

Correction: It needs to say which authentication and authorization IDs
it _requests_.  Or provides, or whatever is the correct term.  Hopefully
these IDs will be treated just like IDs from other SASL mechanisms.  Or
like no ID (unauthenticated), if that's what the mechanism requests.

>   provide a security layer.

I think either 'It requests anonymous authentication and authorization
identities.  How to treat the anonymous ID is up to the protocol or
implementation.', or 'It does not affect the authentication and
authorization identities'.

> I suggest you look at some existing implementations.

I don't know where to find any...

> But

If you mean e.g. a password, I agree.  However, I was thinking of
clients that authenticate to the server and then grant access to
something on the client side depending on whether or not authentication
succeeds.  Such a client must not treat the ID sent with ANONYMOUS as an
authentication ID.  Or it could refuse the user to specify the ANONYMOUS
mechanism, of course.

> or authenticating the user's identity.

I don't see why not.  The user just doesn't have anything to do with any
information sent in the authentication requests.  Instead the user is
built into the mechanism itself.  Once it is established, it has the
access which the server grants that user, just like with authenticated
users.

>> Which made me realize that anonymous auth is not a SASL term, but one
>> I'm used to from LDAP, where it means the same as no auth.  OTOH, FTP
>> (at least on Unix) implements anonymous auth the way Sam describes: A
>> specific user on the server's system, with limited access.
> 

In LDAP it does not authenticate.  In FTP it does, to the server.  The
anonymous user has the access which the filesystem grants to a specific
user on the filesystem.

> In this case, they are concealed from (at least) the server.

Uh... An authorization identity concealed to the server is not
a concept I can quite wrap my head around.  The server grants
access based on some specific authorization identity.

> authorization state.

Replace "revert" back to "unauthenticated", then.

> That new authorization state could be an anonymous one (one where the
> identity of the user is not established (authenticated)).

I can't find any place in rfc2222bis which says so.  Where?

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 10 Apr 2004 10:38:45 -0700

>authorization ID of users who have engaged in no authentication

But here you are talking about some authorization ID which the
service merely associates with the state of being anonymous
(having an unknown or concealed identity).  This is quite different
than saying that anonymous users have established (authenticated)
THEIR identity in the service.

Kurt

---

From: Sam Hartman <[email-masked]>
Date: Sat, 10 Apr 2004 14:09:29 -0400

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

    Kurt> At 09:58 AM 4/10/2004, Sam Hartman wrote:
    >>  I think my statement is still generally true.  It may happen
    >> that the authorization ID of anonymous users is also the same
    >> as the authorization ID of users who have engaged in no
    >> authentication exchange.

    Kurt> But here you are talking about some authorization ID which
    Kurt> the service merely associates with the state of being
    Kurt> anonymous (having an unknown or concealed identity).  

Agree.d

    Kurt> This
    Kurt> is quite different than saying that anonymous users have
    Kurt> established (authenticated) THEIR identity in the service.

I don't see the difference.  IN both cases, the identity (or
non-identity) you are authorized as establishes your privileges in the
system.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 10 Apr 2004 13:03:52 -0700

At 10:33 AM 4/10/2004, Hallvard B Furuseth wrote:

>rfc2222 does the same thing.

RFC 2222 only once used the term "authentication mechanism".
This was in the security consideration section, when referring to
relative strengths of various mechanisms.  It failed to
distinguish that some mechanisms do not provide authentication
services.  That should be corrected.

Everywhere else in RFC 2222, RFC 2222 used generic terms.

>Did it incorrectly describe existing

Often one describes features of protocols based upon what
purpose they generally serve even though they might not
always be used for that purpose.  See say "security layer"
even though the feature (say data compression) may not used
to provide non-security layer .

The fact that we name these features as we do, it should be
made clear that they do not always provide the function the
names imply.  This should be made clear in RFC 2222.

>If it affects the authorization or authentication IDs, it... well,

yes.

>un-authenticates, I suppose.

I prefer to say that the ANONYMOUS mechanism, like all mechanisms,
is used to establish a new authorization state which displaces
the previous authorization state.  In particular, ANONYMOUS is
used to establish an anonymous authorization state.  That is,
the purpose of ANONYMOUS is to provide access of that of a
user without requiring the user to establish their identity.

>If it doesn't, it seems to violate rfc2222 and rfc2222bis.

I think ANONYMOUS is fairly consistent with RFC 2222 and
2222bis.  I think 2222bis needs some further clarification
here and there.

>these IDs will be treated just like IDs from other SASL mechanisms.
>Or like no ID (unauthenticated), if that's what the mechanism requests.

ANONYMOUS doesn't request nor provide an authentication ID nor an authorization ID.

Note that there could be other mechanisms would also do not
provide such IDs to the server.  Consider a mechanism which
only authenticated the server to the client.

Anyways, I think it sufficient for the mechanism to say what it
provides (no IDs in the case of ANONYMOUS).  How that's used
in application protocol (or implementations thereof) is simply
beyond the scope of the mechanism specification.

>identities.

I assume It == user here.  I'm describing what the mechanism
establishes and not (in this paragraph) what the user may or
may not request using this mechanism.

>How to treat the anonymous ID is up to the protocol or

The latter is especially dangerous because confusing between
whether we're talking about the identity established by the
user through authentication, and some identity value which
represents the user has not established THEIR identity through
authentication.

>I don't know where to find any...

Cyrus SASL?

>If you mean e.g. a password, I agree.

I mean credentials.  Credentials may include many things...
and generally (but not necessarily) includes a representation of
the identity they are used to establish.  For instance, in
PLAIN, the credentials include both a representation of
the user's identity and a password.  The user has to know
both to gain access as that user.

>However, I was thinking of
>clients that authenticate to the server

Who are they authenticating?  Themselves or whatever entity is
using the client?  SASL general function is to authenticate
the client (or entity which is using a client) to the server.
It's not to authenticate the entity using the client to the
client.

This is not to say that clients cannot do that, but the
security considerations for using SASL in this fashion are
broad and wide.

>and then grant access to
>succeeds.

Such a client would need to treat ANONYMOUS as not establishing
the user's entity.  Here, at least, the client can just disallow
the mechanism.  A client which uses PLAIN, CRAM-MD5, etc., for
such has it far worse.  They need to know which user names
have widely known passwords or user names are granted access
regardless of what password is provided.  How many PLAIN
deployments out there accept any password for "anonymous"?

>Such a client must not treat the ID sent with ANONYMOUS as an
>authentication ID.

Whether the trace information provided by the client
has any semantical value to the client is beyond the
scope of the mechanism.  The mechanism is quite clear
that the email address, if provided, as no semantical
value to the mechanism and should only be used by
the server for trace purposes.

>Or it could refuse the user to specify the ANONYMOUS
>mechanism, of course.

If a client is going to use mechanisms to authorize users
to access services AT the client, then it needs to understand
not only the services provided by the mechanism, but
protocol/implementation/deployment details of the server
it using in support of user authentication to the client.

>access which the server grants that user, just like with authenticated

The distinction is wether or not the mechanism is authenticating
the user's identity or whether the server-side implementation of
the mechanism is merely associating some identity representation
that indicates that the user's identity has not been established
by the mechanism.  That latter is an implementation detail.

>anonymous user has the access which the filesystem grants to a specific

The problem with your statement, in my opinion, is the
implication that the user's identity seeking anonymous
access has THEIR identity authenticated.  No, the user
seeking anonymous access is asserting a well-known account
name which grants access to anyone and everyone regardless
of what password is provided.  So, while one is going
through a login process, it is an anonymous login process.
That is, the user is not required to provide THEIR credentials
for authentication.  They are granted access without
authentication of who THEY are.

It should be clear in ANONYMOUS that there is no well-known
identity representation transferred to obtain anonymous
access nor is any particular identity representation implies
to have been transferred to the server by use of ANONYMOUS.

>access based on some specific authorization identity.
Or lack thereof.

But more to the point is that the authorization identity it
uses is something it constructs (possible directly from information
provided in the exchange).

A user can be said to be anonymous to the server if the
identity of THAT user (a particular user) is not known
to the server.  That is, the identity of the user has
been concealed by the user, the client, and the choice
of mechanism.

Hence, where a server might associate some special authorization
identity representation to all users who have not established
their identity as implying that the special identity representation
used by the server is authenticated or identifies the particular
user.

>Replace "revert" back to "unauthenticated", then.

That would make even less sense: unauthenticate the authentication ID?

>I can't find any place in rfc2222bis which says so.  Where?

As I said before, RFC 2222bis needs work here.  A number
of the clarifications added to RFC 2222bis are causing
confusion.  Those clarifications need refinement.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 10 Apr 2004 13:25:22 -0700

>non-identity) you are authorized as establishes your privileges in the

The difference is that, when using ANONYMOUS, users don't
establish THEIR identity, they establish some factor in the
server which allows them access without requiring that they
establish THEIR identity.  Sure, a system can associate
some identity representation to all users which have not
established THEIR identity, but that imply the user has
established THEIR identity.

And, I would hope, we can agree on whether or not the
system does associate some identity representation to
all users which not established THEIR identities or
not, or what that identity representation might be,
is completely beyond the scope of this mechanism.
Just as what authorization identity representation the
system might associate with an user who DOES establish
their identity is beyond the scope of the mechanism.

---

From: Sam Hartman <[email-masked]>
Date: Sat, 10 Apr 2004 16:58:21 -0400

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

    Kurt> This is quite different than saying that anonymous users
    Kurt> have established (authenticated) THEIR identity in the
    Kurt> service.
    >> non-identity) you are authorized as establishes your privileges
    >> in the system.

    Kurt> The difference is that, when using ANONYMOUS, users don't
    Kurt> establish THEIR identity, they establish some factor in the
    Kurt> server which allows them access without requiring that they
    Kurt> establish THEIR identity.  
That sort of depends on your model for identity.

It seems completely reasonable to say something along the following
lines.  Anonymous establishes the anonymous identity with no
confidence in that identity.  IP address-based authentication
establishes an identity based on the IP address with low confidence in
that identity.  AUthentication by assertion establishes the asserted
identity with low confidence in that assertion.  External
authentication with a client TLS certificate establishes the
SubjectName of the certificate as the identity with reasonably high
confidence in that identity.

Now in this working group we don't really care about the properties of
the identity established by anonymous authentication.  For example, we
don't care if the identities resulting from two different anonymous
authentications compare to be equal or are guaranteed to be distinct.
You probably want one of the two to be true and for most purposes you
don't care which.

Again, I think we are arguing about isomorphic models.
Conceptually,believe there is an identity and some factor indicating
whether the identity has been established.  I believe that one class
of identity is the unestablished identity.

So why am I arguing over isomorphisms?  Unfortunately, the particular
conceptual model we use seems to appear at least in part in the text
of the base specification.  I believe that treating everything as
authentication will make that base specification easier to understand
at the cost of hiding conceptual complexity in anonymous.  I may be
wrong; this may confuse people to much and be important to change.

I'm also arguing to show that this is not an editorial correction to
the base specification.  You're proposing changing how we think about
SASL or at least expanding an area of thought about SASL where our
previous thinking was vague.  Making that change is a reasonable thing
for the working group to do, but it does need to meet a slightly
higher bar than an editorialclarification.

    Kurt> Sure, a system can associate some
    Kurt> identity representation to all users which have not
    Kurt> established THEIR identity, but that imply the user has
    Kurt> established THEIR identity.

    Kurt> And, I would hope, we can agree on whether or not the system
    Kurt> does associate some identity representation to all users
    Kurt> which not established THEIR identities or not, or what that
    Kurt> identity representation might be, is completely beyond the
    Kurt> scope of this mechanism.  Just as what authorization
    Kurt> identity representation the system might associate with an
    Kurt> user who DOES establish their identity is beyond the scope
    Kurt> of the mechanism.

Agreed.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 10 Apr 2004 17:49:02 -0700

>That sort of depends on your model for identity.

I think it depends more on who is establishing what, and by what means.

When ANONYMOUS is being used, the USER is not required to establish
THEIR identity.

Whether or not the server-side mechanism implementation represents,
or how it represents, to the server-side protocol implementation that
the USER has requested access be granted on an anonymous-basis
(e.g, with requiring the USER to establish THEIR identity), as well
as how that server-side protocol implementation might then use this
information in authorization decisions is a separate (and separable)
issue.

>confidence in that identity.

In the three non-anonymous examples you provide, each requires the
user to disclose its identity.  In the anonymous case, the user is not
required to disclose information its identity (though the user might
be identifiable otherwise).  So, I think, your analogy is a bit flawed.

But, what concerns me is implication that the ANONYMOUS mechanism
establishes through the exchange an identity representation that refers
users who have not established their entity.  I find that implication
misleading and confusing.  If such a representation is to be established,
it's being established by, for, and within server implementation.
That is, such is being manufactured outside of the mechanism exchange
as defined by this specification.

>authentications compare to be equal or are guaranteed to be distinct.

I agree.

>So why am I arguing over isomorphisms?

I think we're arguing over whether "to authenticate" means
"to verify" or whether it means "to login (with our without
verification)".

SASL mechanisms are login mechanisms: some provide authenticated
login capabilities, some provide anonymous login capabilities.

>Unfortunately, the particular
>of the base specification.

I think the base specification has problems in three areas (that
impact this discussion):

1) The base specification does not use terms consistently,
2) The base specification doesn't always define the terms it uses, and
3) The base specification is not clear that as to the range of
function that a SASL mechanism can provide.

>I believe that treating everything as
>at the cost of hiding conceptual complexity in anonymous.

To a certain degree I agree that some of the conceptual complexity
can be hidden in ANONYMOUS, excepting the base specification needs to
be clear that not everything fits the easier to understand model which
the base specification puts forth.

Anyways, in regards to the ANONYMOUS specification, I'm going to offer a
slightly revised intro text for the WG to consider here shortly.

However, I think the base specification needs work to be more easily
understood.  For instance, 2222bis uses of the terms:
        SASL authentication mechanism,
        SASL mechanism,
        authentication mechanism, and
        mechanism
generally in an interchangeable fashion.  However, in some uses in the
document where it obvious that they are not interchangeable.  This
confuses all the uses which the author used them interchangeable,
leaving a mess for the reader to decipher.

I think it would be far better if we would consistently use the term
"SASL mechanism" (and "mechanism" only where it is clear we're referring
to a SASL mechanism) as RFC 2222 generally did.  And I think we should be
more clear as to what functions SASL mechanisms generally provide
(and how some may offer vastly different functions than other mechanisms).

>I may be wrong; this may confuse people to much and be important to change.

At the moment, some readers of 2222bis are going to be confused as some
of the terminology is new and different than what was used in RFC 2222,
BUT the largest problem is that much of the terminology (new and old)
is not well-defined and/or not used consistently.

>previous thinking was vague.

I don't think I am arguing that we change how we think about SASL.
I am mostly arguing that we clean up our terminology.  And I am
objecting to use of language which is not consistent with our
terminology.  Of course, "what is our terminology" is a bit of
an open question given that 2222bis does well-define our
terminology.

>Making that change is a reasonable thing

Inconsistent use of poorly-defined terminology is, I think, not just
an "editorial clarification" concern, it's a general technical quality
concern.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 11 Apr 2004 20:33:45 +0200

Kurt D. Zeilenga writes:
> This was in the security consideration section,

Sorry, I should have said I looked for 'authentication' and
'authorization' in general.  In particular the term 'authentication
protocol exchange' is recurring.
E.g.:

  3.    Introduction and Overview
    The Simple Authentication and Security Layer (SASL) is a method for
    adding authentication support to connection-based protocols.
    (...)
    If a server supports the requested mechanism, it initiates an
    authentication protocol exchange.
    (...)
    During the authentication protocol exchange, the mechanism performs
    authentication, transmits an authorization identity (...)

  5.3.  Multiple authentications

  4.    Profiling requirements
    5. A specification of how the authorization identity passed from the
       client to the server is to be interpreted.

[ANONYMOUS] does not fulfill that requirement.

> names imply.  This should be made clear in RFC 2222.

True.  (I approached this whole thing from the point of view of a user
of a SASL library, who knows SASL but may not be aware that there are
mechanisms that do not provide what the SASL spec might make one assume
it provides.)

> ANONYMOUS doesn't request nor provide an authentication ID nor an

There has to be _some_ way to say that ANONYMOUS changes the
authentication ID, or requests a change of it, or however you wish to
say that, and what that new ID is, or that the new ID is absent, or
however you wish to say that.  Could you please provide a wording for
that which you will accept, so we can at least talk about how it relates
to the authentication ID?  Maybe just some wording to satisfy the SASL
'Profiling requirements' requirement above.

I'll hold off replying to part of your message (if a reply to the rest
still seems relevant) until then.

> provide such IDs to the server.

See the section from '4. Profiling requirements' quoted above.

> Consider a mechanism which

Hmm - I suppose the mechanism could specify that the authentication ID
is the one which was already in use.

> beyond the scope of the mechanism specification.

Yes.

> I assume It == user here.

I meant it = mechanism.  Though it's on behalf of the user, if that's
what you mean.

> I'm describing what the mechanism

But 'establishes' is wrong - as you said, how any mechanism affects
authentication and authorization IDs outside of the mechanism is beyond
the scope of that mechanism.

> The latter is especially dangerous

Well, I hoped that was not what it does.  Your recent messages in this
thread just made me wonder if it did.

>> I don't know where to find any...

Yes.  But a client and a server which uses the mechanism?
Anyway, I kind of hoped someone who already use SASL could tell me,
so I won't have to compile and install stuff just to find out.
The only example I know of is openldap ldapsearch.  It does not
treat auth(c/z) ID as trace ID.

> both to gain access as that user.

OK.

> the client (or entity which is using a client) to the server.

Sure.

> security considerations for using SASL in this fashion are

Perhaps they should be discussed in rfc2222bis?

> deployments out there accept any password for "anonymous"?

Do you mean such things come with the default SASL setup with some
implementations?  That sounds scary enough that it might be an idea to
warn about it in rfc2222bis.  Otherwise I don't see the problem.  The
client will authenticate against a server which it knows is set up to
authenticate the possible users of that clients.  Other user names will
not be recognized.  Except ANONYMOUS "user names", if the client treats
the trace information sent with ANONYMOUS the same way it treats user
names for other mechanisms.  Anyway, I simply wondered if clients do
that.  I hope not.

> it using in support of user authentication to the client.

OK.

> access has THEIR identity authenticated.  (...)

I don't think so.

Users of shared accounts don't authenticate as THEIR identities either.

My nearest public library has the public account's username and password
taped to the public computers, so people can reboot the beasts without
running to a librarian for help.  That's not the user's identity either.

All that any SASL mechanism authenticates is that the client provided
sufficient credentials to authenticate in the manner it did.  Which is
none at all, in the ANONYMOUS case.  The administrator who allowed
that authentication is the one who knows what it means that someone
authenticated that way, and what access to grant.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 11 Apr 2004 20:40:56 +0200

Grumble.  Read through a message two times before sending, then discover
a mistake just after sending:-(

> [ANONYMOUS] does not fulfill that requirement.

I meant, [ANONYMOUS] as currently described, or as you describe it,
does not provide such an authorization identity for the protocol to
interpret.  Even if it is not 'passed from the client', the protocol
spec needs to get an authorization identity from the SASL mechanism
in order to fulfill this requirement.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 11 Apr 2004 14:00:12 -0700

As I noted in my response, we use often use the terms based on
"to authenticate" to mean "to login" instead of "to verify".
I think the "A"authentication in SASL is commonly used in
the "to login" fashion.

rfc2222bis needs to be more clear here, as it is dangerous to say
things are "authenticated" when they are not "verified".

And, I think, we should avoid using terms such as "authentication
mechanism" when there are reasonable alternatives (such as
"SASL mechanism").

At 11:33 AM 4/11/2004, Hallvard B Furuseth wrote:
>(I approached this whole thing from the point of view of a user

The SASL specification should be more clear that not all mechanisms
verify (or even establish) the user's identity, not all mechanisms
pass authorization identity information, not all mechanism support
security layers, etc..  That is, the range of function that mechanisms
offer can vary widely.

And, I think, it very important that to be clear that SASL does not
abstract away the differences between mechanisms.  Something in the
client/server protocol implementation needs to deal with them.  Maybe
the implementation uses a SASL library that abstracts away some of
these differences, but it should be clear something at both the client
and the server has to deal with the differences.  SASL framework
doesn't hide mechanism particulars from protocols.

>however you wish to say that.

By use of the ANONYMOUS mechanism, the client communicates to the server
that the user wishes to access the services/resources provided by server
on an anonymous basis (e.g., without disclosing its identity to the server).

If the server is willing and able, it responds accordingly to the request
and takes appropriate actions within its authorization system to grant
that access.

Note here the separation between what information is communicated by the
mechanism and what the server implementation does with that information.

Details of how identity information (including lack of knowing the user's
identity) is represented by the server are outside the scope of the
mechanism specification.

>Could you please provide a wording for
>to the authentication ID?

In respect to the mechanism, no authentication ID is communicated.
How a server implementation represents that no authentication ID was
communicated by the mechanism is its business.

>Maybe just some wording to satisfy the SASL

Above you called this profiling requirement:
    A specification of how the authorization identity passed from the
    client to the server is to be interpreted.

This requirement means that protocol (not mechanism) specifications
are to define the form used to representation the proxy authorization
identity.  It should not be viewed as requiring all mechanisms to
actually pass a proxy authorization identity information from
client-to-server.

>> beyond the scope of the mechanism specification.

Noted.

>the scope of that mechanism.

I think you are not seeing the separation between what information
a mechanism may or may not provide to the client/server, and how that
information might be used by the client/server.  In the above text,
I was referring to what information the mechanism provides to the
client/server as opposed to affects which are outside the mechanism.

>Yes.  But a client and a server which uses the mechanism?

I believe you can configure OpenLDAP to make use of the mechanism.
Likely Cyrus SASL's own sample client/server may use this mechanism.

>so I won't have to compile and install stuff just to find out.

It's no different than supporting any other mechanism.  You need
to understand what information the mechanism provide, its semantics,
and then map that information into your authorization system.
SASL itself doesn't abstract away mechanism differences (but
your SASL library might).

>treat auth(c/z) ID as trace ID.

GOOD.

>Perhaps they should be discussed in rfc2222bis?

Like, in my best Elmer Fudd voice, "be very, very careful" :-)

>warn about it in rfc2222bis.

I think we need a brief warning.  SASL purpose is to "login" the client
to the server.  It's not designed "login" the user to the client.
What the server might find acceptable, may not be acceptable to the client.

>Client's using SASL for the purposes of granting access to services/resources
>at the client should be "very, very careful" not to make invalid assumptions
>about the success (or failure) of a SASL mechanism exchange.

>authenticated that way, and what access to grant.

Noting that you are using the "to authenticate" (and variants) to
mean "to login", I would have to agree with this statement.  In
particular, I agree that client does not provide any credentials
when using the ANONYMOUS mechanism.  This has been one of my
points through this discussion.

Kurt

---

From: Sam Hartman <[email-masked]>
Date: Mon, 12 Apr 2004 12:03:59 -0400

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

    Kurt> As I noted in my response, we use often use the terms based
    Kurt> on "to authenticate" to mean "to login" instead of "to
    Kurt> verify".  I think the "A"authentication in SASL is commonly
    Kurt> used in the "to login" fashion.

    Kurt> rfc2222bis needs to be more clear here, as it is dangerous
    Kurt> to say things are "authenticated" when they are not
    Kurt> "verified".

With my security hat on, I have to disagree.  Not verified at all is
just one point along the continuum of verification.  The security
difference between not verified and poorly verified is not
particularly significant.

I'm going to try and say less on this issue as making a consensus call
is already going to be challenging.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 12 Apr 2004 10:44:09 -0700

>    Kurt> used in the "to login" fashion.

I like to replace "to login" in the above comment with "to identify".

I don't may describing ANONYMOUS mechanism as identifying the
user as an anonymous user.  I have a problem saying the that
the ANONYMOUS verifies the user's identity is anonymous.

The latter gives off a number of false impressions.  It particular,
the latter can be read as implying the ANONYMOUS mechanism is
providing verified user identity privacy.

>particularly significant.

I agree to your statement as it applies to verification.
I would also agree that there is wide continuum of identification.
However, I disagree that the terms verification and identification
are synonymous.  Whether any harm can be caused to inappropriate
interchange depends on the particular case.

My particular gripe with rfc2222bis is not defining well its
terminology and it not terrible self consistent with its use
of that terminology.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 6 Apr 2004 22:25:40 +0200

-- 
Hallvard

---

From: Sam Hartman <[email-masked]>
Date: Wed, 07 Apr 2004 12:41:04 -0400

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 7 Apr 2004 19:30:40 +0200

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 09 Apr 2004 17:06:16 -0700

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 10 Apr 2004 16:53:53 +0200

Anyway, 

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 10 Apr 2004 09:12:40 -0700

RFC 2828:
   $ anonymous

Which, BTW,

---

From: Sam Hartman <[email-masked]>
Date: Sat, 10 Apr 2004 12:58:01 -0400

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Sat, 10 Apr 2004 13:00:01 -0400

--Sam

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 10 Apr 2004 19:33:31 +0200

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 10 Apr 2004 10:38:45 -0700

Kurt

---

From: Sam Hartman <[email-masked]>
Date: Sat, 10 Apr 2004 14:09:29 -0400

Agree.d

    Kurt> This

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 10 Apr 2004 13:03:52 -0700

yes.

Cyrus SASL?

Or lack thereof.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 10 Apr 2004 13:25:22 -0700

---

From: Sam Hartman <[email-masked]>
Date: Sat, 10 Apr 2004 16:58:21 -0400

Agreed.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 10 Apr 2004 17:49:02 -0700

I agree.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 11 Apr 2004 20:33:45 +0200

Yes.

OK.

Sure.

OK.

I don't think so.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 11 Apr 2004 20:40:56 +0200

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 11 Apr 2004 14:00:12 -0700

Noted.

GOOD.

Kurt

---

From: Sam Hartman <[email-masked]>
Date: Mon, 12 Apr 2004 12:03:59 -0400

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 12 Apr 2004 10:44:09 -0700

Kurt