Subject: Re: 2222bis: identities and authorization

From: Alexey Melnikov <[email-masked]>
Date: Thu, 09 Sep 2004 22:15:02 +0100

[Sorry about the delay, I've integrated all other comments received so far.]

Kurt D. Zeilenga wrote:

>>Would you mind explaining the problem you had with this section in
>>better detail?  I thought it flowed fairly well and is a significant
>>improvement on our previous attempts to describe this issue.  However
>>I might well miss problems because as someone who has been following
>>SASL I'm familiar with the issue.  I am not always good at reading a
>>document as someone new to a technology.
>>    
>>
>
>Sure.  The following 3.2 text:
>  
>
>>  The processing model is as follows.  A server, upon completion of the
>>  authentication mechanism, uses the results produced by the
>>  authentication mechanism, the client-provided authorization identity
>>  value (which may be the empty string), and local policy information
>>  to derive an authorization identity.
>>    
>>
>
>clearly shows the document is using the term 'authorization identity'
>to refer, at times, to the client-provided authorization identity
>and, at times, to a derived authorization identity.  However, in
>other portions of the document, the term 'authorization identity'
>is mostly used unqualified.
>
Right. I agree this is an issue.

>
>While qualification of the term would likely resolve this
>issue, that solution would likely be cumbersome.  As the
>'authorization identity' more properly refers to the identity
>directly used in authorization, it seems more appropriate
>to call the value referred to here as the 'client-provided
>authorization identity' as the 'proxied identity'.
>  
>
[...]

>I've been trying to come with a new term to call the derived
>identity to allow us unambiguously use the term 'authorization
>identity' to refer to the client provided value, as the WG
>seems to have some attachment to this usage.  The best I
>have come with here is 'subject identity' (the identity which
>is the subject in access control decisions). 
>
>I do not recommend this approach myself as I believe it
>would be more proper to use the term 'authorization identity'
>to refer to the subject of access control decisions.
>
I would actually strongly prefer not to do that, as this will make 
everybody very confused. At least I am pretty sure I will be.

"Subject identity" might be a bit ugly, but it is not so bad ;-)

>However, I am far more concerned about ambiguous use of
>the term (using the term to refer to two different values)
>than I am about which of the two uses continues to this
>term.  That is, I can live with calling the client provided
>value an 'authorization identity' if we don't also use that
>term to refer to the derived identity.
>  
>
Ok, I will do the change.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 10 Sep 2004 17:56:43 +0100

Jeffrey Hutzelman wrote:

> When a client requests a specific identity, do we consider it 
> desirable for the server to be able to use some arbitrary other 
> identity instead?

No. The server should either "obey" or fail authentication.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 10 Sep 2004 12:45:19 -0400

>> authorization identity' as the 'proxied identity'.

Ugh.  Have I mentioned how much I hate the use of the word "proxy" to 
describe a relationship that frequently has nothing whatsoever to do with 
one entity acting for another.

Sure, if I connect to one of the cyrus.andrew IMAP backends using a 
requested authorization ID of 'jhutz' and provide credentials proving I am 
a front end, then there is a proxy relationship.  However, if I make the 
same request with credentials belonging to the Kerberos principal 
[email-masked], there is _no_ proxy relationship.  And in either case, 
the client is not _authenticating_ as 'jhutz' at all -- the only 
authentication is of the authentication ID provided by the mechanism, and 
all the client is doing here is asking the server to allow it to _act- as 
the user 'jhutz'.

It's bad enough that people use the confusing phrase "proxy authentication" 
to refer to this situation when it is neither authentication nor 
necessarily involves any proxy relationship.  Let's not compound the 
problem by introducing additional confusing uses of the word 'proxy'.

Instead, let's refer to the identity provided by the client and transported 
by SASL over the wire as the 'requested' identity.  Then the server derives 
the authorization identity based on the authentication identity, the 
requested identity, and local policy.

In case it is not clear, I fully agree here that the phrase "authorization 
identity" should be used to refer to the identity actually used in making 
authorization decisions, and not that requested by the client.  While some 
of us may need to get used to the new usage, I don't think that's as big a 
problem as will be caused by implementors and protocol designers being 
confused into thinking they should used the requested identity rather than 
the derived one for authorization decisions.

Incidentally, this whole discussion reminds me of an issue that occurred to 
me while re-reading the document earlier this week.  It is not at all clear 
to me that the requested and derived identities are permitted to be 
different, except in the case where the requested identity is the empty 
string.  Operationally, my expectation has always been that you have two 
choices - either allow the server to derive an identity from the 
authentication ID, or ask for a specific one which the server can either 
accept or reject.

When a client requests a specific identity, do we consider it desirable for 
the server to be able to use some arbitrary other identity instead?

-- Jeff

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 10 Sep 2004 18:08:15 +0100

Jeffrey Hutzelman wrote:

> Instead, let's refer to the identity provided by the client and 
> transported by SASL over the wire as the 'requested' identity.  Then 
> the server derives the authorization identity based on the 
> authentication identity, the requested identity, and local policy. 

The document is mostly talking about the requested identity. The 
identity used for access control *after* a successful SASL 
authentication is out of scope for the SASL framework.

> In case it is not clear, I fully agree here that the phrase 
> "authorization identity" should be used to refer to the identity 
> actually used in making authorization decisions, and not that 
> requested by the client.

>   While some of us may need to get used to the new usage, I don't 
> think that's as big a problem as will be caused by implementors and 
> protocol designers being confused into thinking they should used the 
> requested identity rather than the derived one for authorization 
> decisions.
>
>
>
> Incidentally, this whole discussion reminds me of an issue that 
> occurred to me while re-reading the document earlier this week.  It is 
> not at all clear to me that the requested and derived identities are 
> permitted to be different, except in the case where the requested 
> identity is the empty string.

If you are talking about semantics of the two - you are right, they are 
referring to the same entity. But of course the syntax of the derived 
identity is implementation specific and out of scope for SASL and 
doesn't have to be the same as the protocol specific syntax for 
authorization (requested) identities.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 10 Sep 2004 13:04:17 -0400

> No. The server should either "obey" or fail authentication.

OK.  I'm inclined to agree, and I think the document should state this more 
explicitly.

Further, if that is the case, then I think the distinction between the 
requested and derived identities is much less significant -- if there is a 
requested ID, they will be the same or the exchange will fail.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 10 Sep 2004 10:33:09 -0700

At 09:45 AM 9/10/2004, Jeffrey Hutzelman wrote:
>Ugh.  Have I mentioned how much I hate the use of the word "proxy" to describe a relationship that frequently has nothing whatsoever to do with one entity acting for another. 

I wouldn't object to use of another term, such as 'asserted identity'
or something.

My concern is that the document uses confusing terminology to
refer to the three distinct identities (the identity associated
with credentials, a client provide identity, the identity the
server uses to make authorization decisions) it discusses.
The document should use three distinct terms for refer to
each distinct identities it discusses.

(Note that in my use of distinct above, I do not intend to
imply that each of these identities could not refer the same
user (or application entity).  I intend to imply that they
each has distinct characteristics (as discussed in the I-D)
within the SASL identity model).

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 10 Sep 2004 10:55:06 -0700

At 10:08 AM 9/10/2004, Alexey Melnikov wrote:
>The document is mostly talking about the requested identity.

Expecting the document explicitly says the identity used in
making authorization decisions is derived from the credentials
and the requested identity.  (Note that I have suggested that
even this statement be clarified as being 'conceptional' in
nature.)

>The identity used for access control *after* a successful SASL authentication is out of scope for the SASL framework. 

Yes, as are the particulars of the derivation.

Note that LDAP is a protocol where, in most implementations
(LDAP doesn't have standardized schema for representing
authorization policy), the identity form used in making
authorization decisions (generally a DN) is not the same form
of the SASL requested identity (a LDAP authzId [RFC2829]).

(Below I am going to refer to the identity used in making
authorization decisions as the subject identity.)

I also note that derivation also allows a level of indication
which some implementations may take advantage of.  For instance,
consider a server which has two groups of users.  Though each
user authenticates as themselves, and requests implicitly or
explicitly to assume their own identity, the server is free
to map all users in one group to an identity associated with
the group.  That is, there may be a many-to-1 relationship
between requested and subject identities.  Also, it is
allowed that the server base the mapping of requested to
subject identities on other factors.  This implies that
there is also a 1-to-many relationship between requested
and subject identities.

I think it best for the particulars of identity mappings
to be left out-of-scope.

Kurt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 10 Sep 2004 14:08:44 -0400

> authorization decisions as the subject identity.)

Maybe it would be best if we avoided the term "authorization identity" at 
all.  Or maybe not.

Given that a server is expected to either use the identity provided by the 
user (possibly mapped to some internal form) or reject the exchange 
entirely, I'm beginning to suspect that making the distinction between 
requested and subject identity may be more confusing than not....

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 10 Sep 2004 11:07:05 -0700

>I wouldn't object to use of another term, such as 'asserted identity'

or 'requested identity'.  I'm fine with your terminology
suggestion.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 10 Sep 2004 11:47:15 -0700

At 11:08 AM 9/10/2004, Jeffrey Hutzelman wrote:
>On Friday, September 10, 2004 10:55:06 -0700 "Kurt D. Zeilenga" <[email-masked]> wrote:
>
>Maybe it would be best if we avoided the term "authorization identity" at all.  Or maybe not.

I prefer to use the term "authorization identity" to refer
to the subject of authorization decisions in the I-D.  For
the client-provided identity, I prefer "requested identity".

(I only used the term "subject identity" in my email to
avoid ambiguity of the I-D terms, and didn't intend to
suggest that this term be used in the I-D.)

>Given that a server is expected to either use the identity provided by the user (possibly mapped to some internal form) or reject the exchange entirely, I'm beginning to suspect that making the distinction between requested and subject identity may be more confusing than not....

I think it appropriate to outlining the identity concepts
while being clear that the described relationship between
the identities is only conceptual.  Protocol specifications
and their implementation have a lot of freedom (and that
freedom, I would argue, is necessary to make things work).

Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 09 Sep 2004 22:15:02 +0100

[...]

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 10 Sep 2004 17:56:43 +0100

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 10 Sep 2004 12:45:19 -0400

-- Jeff

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 10 Sep 2004 18:08:15 +0100

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 10 Sep 2004 13:04:17 -0400

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 10 Sep 2004 10:33:09 -0700

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 10 Sep 2004 10:55:06 -0700

Kurt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 10 Sep 2004 14:08:44 -0400

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 10 Sep 2004 11:07:05 -0700

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 10 Sep 2004 11:47:15 -0700

Kurt