Subject: 2222bis: identities and authorization

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 13 Aug 2004 09:34:04 +0200

I have completed my review of draft-ietf-sasl-rfc2222bis-08.txt,
resulting in mostly minor editorial comments (which I have
separately sent to the Editor).  This note discussions problems
I found related to identities and authorization.

The 'Authorization and authentication identities' section (3.2)
starts off by stating that 'SASL authentication deals with
two identities' but then describes the processing model to
involve three identities, two of which it simply refers to
as 'authorization' identities.  I believe we either need
better distinguish these identities within the document,
by through qualification (proxy authorization identity
v. application authorization identity) or by use of
replacement terminology (proxied identity v. authorization
identity).  I prefer the latter approach as the former
qualifications are themselves a bit confused and the
latter seems more in step with RFC 2828.

I am willing to prepare replacement text for consideration.

Kurt

---

From: Sam Hartman <[email-masked]>
Date: Fri, 13 Aug 2004 13:17:09 -0400

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

    Kurt> I have completed my review of
    Kurt> draft-ietf-sasl-rfc2222bis-08.txt, resulting in mostly minor
    Kurt> editorial comments (which I have separately sent to the
    Kurt> Editor).  This note discussions problems I found related to
    Kurt> identities and authorization.

    Kurt> The 'Authorization and authentication identities' section
    Kurt> (3.2) starts off by stating that 'SASL authentication deals
    Kurt> with two identities' but then describes the processing model
    Kurt> to involve three identities, two of which it simply refers
    Kurt> to as 'authorization' identities.  I believe we either need
    Kurt> better distinguish these identities within the document, by
    Kurt> through qualification (proxy authorization identity
    Kurt> v. application authorization identity) or by use of
    Kurt> replacement terminology (proxied identity v. authorization
    Kurt> identity).  I prefer the latter approach as the former
    Kurt> qualifications are themselves a bit confused and the latter
    Kurt> seems more in step with RFC 2828.

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.

--Sam

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 15 Aug 2004 07:13:04 +0200

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.

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'.

While I am working on a more complete replacement text, here is
glimpse of the suggested clarification:
  Conceptually, the SASL framework deals with three identities:
        - the authentication identity,
        - the proxied identity, and
        - the authorization identity.

  The authentication identity is derived from client's authentication
  credentials.  The proxied identity is optionally provided by the
  client seeking to assume the identity of another user (or entity).
  The authorization identity is the server-produced primary identity
  used for making access control and other policy decisions.
  
  These identities are managed as follows:  The server uses the
  authentication identity established through the authentication
  exchange, the proxied identity (if provided), and possibly other
  information to produce the authorization 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.
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.

Kurt

---

From: Sam Hartman <[email-masked]>
Date: Fri, 13 Aug 2004 13:17:09 -0400

--Sam

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 15 Aug 2004 07:13:04 +0200

Kurt