Subject: Identity terminology in 2222bis

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 01 Oct 2004 11:21:13 -0700

Historically, there was a bit of hand waving in regards
to identities.  In trying to nail down what identities
are involved in the SASL framework, where each identity
comes from and what are they used for, we ended up with
3 identities:
 - the "authentication identity" to refer to the
   identity associated with the users credentials,
 - the "requested identity" to refer to identity which
   the user requests to act as, and
 - "authorization identity" to refer to identity
   used by the server in making authorization decisions.
   (The latter being derived from by former two.)

However, we now face is that what we've historically
called an authorization identity is not the precise
identity used in making authorization decisions.

The amount of 2222bis editing to implement the WGLC
conclusion is actually minor in comparison to the
impact upon other documents, including most mechanism
specifications and application profiles.  If it was
only 2222bis, I'd be inclined to just bit the
bullet and make the terminology changes.  But given
the broader impact this terminology change would have,
we need to consider other approaches to resolving our
terminology woes.

In particular, I think this can be done by separating
how identities are used conceptually from how they
are used in practice and, in particular, their form.

Below is a 3.2 rewrite which, I think, demonstrates
how we can avoid the terminology problem.  I do think
other portions need work as well, but this should give
you reasonable idea of the approach I suggest we take.

Comments?

-- Kurt (as an individual contributor)

3.2 Identity Concepts

Conceptually, SASL framework involves two identities:
	1) an identity associated with the authentication
	credentials (termed the authentication identity), and
	2) an identity to act as (termed the authorization
	identity).

The client provides its credentials and, optionally, a
string representing the requested authorization identity
as part of the SASL exchange.  When this string is not
provided, the client is requesting to act as the identity
associated with the credentials (e.g., the user is
requesting to act as the authentication identity).

The server is responsible for verifying the user's
credentials and verifying that the user is able to
act as the authorization identity.  A SASL exchange
is successful if and only if both of these verifications
are successful.

While SASL mechanisms specify the form of credentials
used to authenticating users and SASL application
profiles specify the form of authorization identities
transferred as part of authentication exchange, the
precise form(s) of the authentication identities (used
within the server in its verifications, or otherwise)
and the precise form(s) of the authorization identities
(used in making authorization decisions, or otherwise) is
beyond the scope of the SASL and this specification.  In
some circumstances, the precise identity forms used
outside of the SASL exchange may be dictated by other
specifications.  For instance, the authorization policy
specification for an application protocol may dictate the
precise form that an authorization identity is to be
represented in the authorization policy.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 01 Oct 2004 23:05:31 +0200

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

> beyond the scope of the SASL and this specification.

I'm worried by how this new text interact with string normalization
like SASLPrep.  To me, it sounds as if the above leave the precise
form of authentication/authorization identities up to either, or both,
of application profiles and mechanisms.  Is that a correct
interpretation?

If so, the new text would appear to permit, e.g., mechanisms to
perform SASLPrep on the authorization identity.  And to permit
application profiles to apply perform SASLPrep on the authentication
identity.  Here, SASLPrep could even be some other function, like
Unicode NFKC, or SASLPrep2, or some proprietary normalization
procedure.

For comparison, here is part of the old text:

   Any normalization of the authentication identity is defined by a
   particular SASL mechanism, the protocol profile doesn't influence it.

   The mechanism MUST preserve Unicode codepoint when transferring
   authorization identity (e.g. the mechanism cann't apply any form of
   normalization).

Read in contrast to each other, this seem like a major design change.

Instead, I propose to clarify the terminology.  Further, the
requirements on application profile and mechanisms should be
specified, and not left "beyond the scope of 2222bis".  One concrete
approach is to require that, for IETF application profiles and
mechanisms, both authentication and authorization identities MUST be
SASLPrep strings, and that the SASL library, the application profile,
and the mechanism may all perform SASLPrep on the identities.

Thanks,
Simon

---

From: Sam Hartman <[email-masked]>
Date: Fri, 01 Oct 2004 18:38:33 -0400

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

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

    >> While SASL mechanisms specify the form of credentials used to
    >> authenticating users and SASL application profiles specify the
    >> form of authorization identities transferred as part of
    >> authentication exchange, the precise form(s) of the
    >> authentication identities (used within the server in its
    >> verifications, or otherwise) and the precise form(s) of the
    >> authorization identities (used in making authorization
    >> decisions, or otherwise) is beyond the scope of the SASL and
    >> this specification.

    Simon> I'm worried by how this new text interact with string
    Simon> normalization like SASLPrep.  To me, it sounds as if the
    Simon> above leave the precise form of
    Simon> authentication/authorization identities up to either, or
    Simon> both, of application profiles and mechanisms.  Is that a
    Simon> correct interpretation?

The consensus of this working group is that the mechanism must
transport the requested authorization identity so that all unicode
code points are preserved.  I.E. the mechanism can use any bijective
transformation it desires; transforms like utf8-encode are assumed to
be bijective on the set of unicode code points.

Trying to be a bit more clear, mechanisms choose the encoding, but
must preserve the unicode code points given to them by the protocol.

The authentication identity is completely a matter for the mechanism;
it may (and often should) normalize it.

The normalization and interpretation of the requested authorization
identity is a protocol matter.

--Sam

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 02 Oct 2004 00:58:33 +0200

Sam Hartman <[email-masked]> writes:

> code points are preserved.

Then I propose to keep the following in section 3.2:

Otherwise, I cannot find any normative text reflecting the consensus.

> it may (and often should) normalize it.

Then I propose to keep the following in section 3.2:

Kurt D. Zeilenga proposed to remove both paragraphs, if I understood
him correctly.

Thanks,
Simon

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 01 Oct 2004 16:12:05 -0700

Simon,

Note that the text I offer is not a direct replacement for
Section 3.2.  Additional work, including moving key
imperatives from the existing 3.2 to other sections, would
have to be undertaken.

>> beyond the scope of the SASL and this specification.

This may need some slight rewording.  The intent is for
the mechanism specification to detail how to verify
the credentials and for the application protocol profile
to specify the precise form of the authorization identity
(within the Unicode restrict) but to make it clear that
there are many uses of these identities which SASL simply
doesn't not control.

>like SASLPrep.

I presume the existing recommendations here will remain.

>To me, it sounds as if the above leave the precise
>of application profiles and mechanisms.

The precise form of the credentials is a mechanism detail.
The mechanism generally details how the credentials are to
be verified.  The precise form of the authorization
identity is, excepting the Unicode restriction, is a
application protocol detail.

Other uses of identities are outside the scope of SASL.

>   particular SASL mechanism, the protocol profile doesn't influence it.

Though I think this needs to be slightly reworded, I agree
with the intent of the statement to say that protocol
profiles should leave of aspects of credentials and their
verification to the mechanism.  However, this in no way
implies that an application protocol specification, or
its implementations, cannot detail the form of authentication
identity the application protocol (or implementation) might
use otherwise.  For instance, an application protocol
specification could detail how to represent authentication
identities in an identity assumption authorization policy.

>Instead, I propose to clarify the terminology.

I think you propose a major design change.

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 02 Oct 2004 01:25:32 +0200

> imperatives from the existing 3.2 to other sections, would

OK, I must have misread your initial post then.

Thanks,
Simon

---

From: Sam Hartman <[email-masked]>
Date: Fri, 01 Oct 2004 18:38:33 -0400

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Sat, 02 Oct 2004 14:52:58 -0400

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

    Kurt> be verified.  The precise form of the authorization identity
    Kurt> is, excepting the Unicode restriction, is a application
    Kurt> protocol detail.

This isn't quite right.  The form of the requested authorization
identity--the bits that are transferred over the wire--is a mechanism
detail.  The protocol profile feeds in unicode codepoints and the
mechanism decides how those codepoints will appear on the wire.  The
semantics of these codepoints is what is a protocol detail.

--Sam

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 02 Oct 2004 12:27:46 -0700

At 11:52 AM 10/2/2004, Sam Hartman wrote:

>This isn't quite right.

By "form" above, I am referring to the shape of the Unicode
string and not the encoding of that Unicode string.  The shape
(Kerberos principal, LDAP DN, LDAP authzid, email address,
etc.) of the string is an application protocol matter, its
encoding (UTF-8, UTF-32, other) is a mechanism matter.

>The form of the requested authorization

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 15 Oct 2004 03:19:42 +0200

> as part of the SASL exchange.

>                                When this string is not

No, authentication identity may not even have a syntax which is valid
for an authorization identity.  The client is requesting that the
authorization identity is derived from the authentication identity.

Also, I suggest /not provided/omitted or empty/.

> act as the authorization identity.

s/user('s)/authentication identity('s)/.
s/able/allowed/.

> A SASL exchange

Security layer negotiation can also fail.
Or something can just plain break a specification.

> transferred as part of authentication exchange, the

This sentence needs to be broken up.

  SASL mechanisms specify the form of credentials
  used to authenticating users, and SASL application
  profiles specify the form of authorization identities
  transferred as part of authentication exchange.
  However, the

> precise form(s)

  and semantics  

> of the authentication identities (used
> and the precise form(s)

  and semantics

> of the authorization identities

> In

Or the protocol profile may specify that authorization identities
are to be checked e.g. in a case-insensitive manner.

Finally, what is the word 'application' doing here?  What is an
'application profile'?  Or an 'application protocol' as opposed to a
protocol'?

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 14 Oct 2004 19:10:17 -0700

At 06:19 PM 10/14/2004, Hallvard B Furuseth wrote:
>for an authorization identity.

An identity can be represented in many different ways.
Here I am using the terms "authentication identity"
and "authorization identity" conceptional, and
generally without regards to how they might be represented
at any given time or place.  When I referred to a "string
representing the requested authorization identity", I
referred to a particular representation of an identity.
But when I said, "the client is requesting to act as the
[authentication identity]", I didn't talk about how that
identity would be represented.

>The client is requesting that the

Conceptionally, the client is requesting the act as the
identity associated with credentials.  This identity
might have many different representations.

>s/user('s)/authentication identity('s)/.

Since authentication identity is defined here as
being the identity associated the credentials, would
be effective saying:
        s/user's credentials/credentials of the identity
        associated with the credentials/

>s/able/allowed/.

Okay.

>Or something can just plain break a specification.

It may be better to reverse the statement:
        A SASL exchange fails if either (or both) of these
        verifications fails.

>> transferred as part of authentication exchange, the

I note that s/SASL mechanisms specify/SASL mechanism
specifications describe/, s/profiles specify/profiles
describe/.   That is, we need to be careful not to use
the term "mechanism" to refer to a mechanism's
specification. 

>  transferred as part of authentication exchange.

Noting my above note would apply here as well, I think
this suggestion is a good one.

>> within the server in its verifications, or otherwise)

I have some concern here.  In particular, the mechanism
specification may cover some authentication identity
semantics.  Or, as you note below, the application
profile may detail matching semantics.   I think talking
adding "and semantics" will just confuse things.

>'application profile'?  Or an 'application protocol' as opposed to a

I mean application-level protocol.   I generally find the
bare use of the term 'protocol' to be somewhat unclear.
I rather quality the term with 'application-level'.  However,
that likely should be done consistently or not at all.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 21 Oct 2004 15:39:29 +0200

Sorry about the late replies; I thought I had addressed this.

> might have many different representations.

I hadn't quite caught on to the 'conceptual' part, but it seems rather
confusing to have the same names for 'conceptual' and 'represented'
identities.

But even so, authorization identities and authentication identities seem
to me to be 'conceptually' different types of entities; defined by
different standards and used in different ways.  So whether we talk of
conceptual or represented identities, I'd still prefer to say that the
authorization id is derived from the authentication id rather than it is
the authentication id.

>         associated with the credentials/

Well, I'd still like to get rid of that 'user'.  'User' is used
elsewhere as merely one kind of identity.
Maybe s/user's credentials/presented credentials/,
or s/users's credentials/credentials/, s/user/authentication identity/?

>         A SASL exchange fails if either (or both) of these

Yes.

  >  particular SASL mechanism, the protocol profile doesn't influence it.

  That's a bit misleading from the protocol's point of view.  From
  discussions elsewhere I gather the protocol may normalize the ID as it
  pleases for its own use, including when it locates the server-side
  secret matching the authentication ID, as long as this does not affect
  the ID which the authentication mechanism sees.

Your text doesn't seem to be clear on that.

> that likely should be done consistently or not at all. 

Do you mean the OSI model application layer?  If so, it needs a
reference to the OSI model.  If not, I'm still not sure what you mean.
BTW, I notice that there are several other uses of 'application' in
rfc2222bis which I'm not quite sure of, now that it's bought up.

Also, I would have thought SASL could be used at the presentation layer
as well.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 21 Oct 2004 11:40:50 -0700

>confusing to have the same names for 'conceptual' and 'represented'

Would it help if the conceptional discussion was moved to the
Introduction?

The problem is that, in the SASL framework, no identity
representation may be explicitly transferred.  However,
regardless of what's transferred.

>to me to be 'conceptually' different types of entities;

I disagree.  An identity (authorization or authentication) refers
to a human or application entity.  The qualification, authorization
or authentication, refers not to kind of entity, but to the usage
of the identity.

>defined by

The 'derived' language is problematic.  Consider the authorization
identity (and when its explicitly transferred).  A user wishes
to act as some other user that it identifies as some particular
identity.  The user enters a representation of that identity
to the client which then, knowing the application protocol
requirements, translates the user provided identity string
into form required by the application protocol specification.
Then the server might take this form and translate it some
other representation of the identity to make identity assumption
policy decision, and then do some other translation of the
representation of the identity to produce the identity
representation actually used to make authorization decisions.

Regardless of the identity abstraction (DN, Kerberos principle,
etc.) and the encoding of values of that abstraction (LDAPDN,
DER DN, GSER DN, DCE DN) used here and there, there is
conceptional one authorization identity.

For instance, consider an LDAP client which offers an input
dialog allowing the user to input a character string
representing the desired authorization identity and
a indicator of the format of that string.  The user inputs
the string "[email-masked]" and selects the form identifier
marked "user name".  The LDAP client, knowing the requirements
of the LDAP's SASL profile, takes this information and constructs
the string "u:[email-masked]" and transfers it as the
authorization identity string in some mechanism (say EXTERNAL).
The server needs to determine whether the user associated
with the credentials is authorized to act as "u:[email-masked]",
but the server's identity assumption policy subsystem happens
to requires identities to represented as email addresses
with the domain part in upper case.  So, the server produces
the string "[email-masked]" and feeds this (and other
information) to the identity assumption policy subsystem.
Assuming success, the server now needs to produce an
representation suitable for use in making authorization
decisions.  That subsystem might happen to require identities
to be presented as DER encoded DNs.  So the server somehow
produces that.  And in the actual policy, maybe DNs are
presented using the LDAP DN string format.

That is, one identity concept in authorization identity:
        the identity to act as
with multiple identity representations.

If we were to try to name each of distinct identity
representations of the authorization identities that were
likely evident in any application (both client and server)
use of SASL, things will get confused.  Developers will
start to think that the form of the identity transferred
on the wire is the actual form used elsewhere and, in
particular, used in making authorization decisions.  That
is not necessarily so.

For instance, I know of no LDAP server implementation
that uses the particular form of authorization identity
required by LDAP SASL profile in making authorization
decisions.  They all map the LDAP authzId string (even
if the dnAuthzid variant is used) to some other format,
such as an LDAP DN string.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 21 Oct 2004 13:11:23 -0700

At 12:03 PM 10/21/2004, Hallvard B Furuseth wrote:
>I'll be reading this - and the draft - later, but first:
>
>Kurt D. Zeilenga writes:
>That last sentence seems to have been truncated.

I think I was going to note that regardless of identity
abstract (DN,Kerberos principal,other) and encoding
(for DNs: RFC 2253 string, RFC 2829 authzid, DCE DN
format, base64 of the DER encoding, other) used in
transfer, the transferred value refers to some identity.
Later, that identity may be represented using other
abstractions and/or encodings.

If we talk conceptually, we can say the authorization
identity value input of the user, the value transferred
by the SASL mechanism, the value used in determining
whether the user associated with the credentials may
act as specified identity, the value used in making
authorization identities, and the values used in
specifying identity assumption and/or authorization
policies are all refer to the same identity, the
identity to act as, the authorization identity.

If, however, we talk in terms of how this and other
identity concept is represented here and there, we'll
have to come up with numerous terms and over-specify
the details of identity management.  Most of the
details of identity management are simply beyond
the scope of the SASL framework.

Kurt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 21 Oct 2004 18:25:53 -0400

On Thursday, October 21, 2004 15:39:29 +0200 Hallvard B Furuseth 
<[email-masked]> wrote:

>>> [...]
> [...]

Agree.  Use the "is derived from" language; it's less likely to confuse 
people into thinking in terms of blindly copying strings around.

> or s/users's credentials/credentials/, s/user/authentication identity/?

s/user/client/  and be done with it.

> Your text doesn't seem to be clear on that.

The syntax and semantics of authentication ID's are determined entirely by 
the authentication mechanism; the protocol has no say in the matter.  All 
mechanisms are protocol-independent, and all protocol profiles are 
mechanism-independent.

A particular _implementation_ must be able to perform the authorization 
check (can this authid use the requested autzid) and must be able to derive 
an authorization ID from an authentication ID.  These operations depend on 
both the mechanism and protocol profile in use, and their details are 
deliberately left to the implementation and to local policy.

> Do you mean the OSI model application layer?

No; he's using the term in a generic sense and there does not need to be a 
reference to the OSI model, which in any case is only of limited use.  For 
example, if you look, you'll find that SASL does not correspond to any 
layer in the OSI model.

The distinction here is between SASL-using protocols (most of which are, in 
fact, "application" protocols in the narrower sense) as opposed to SASL 
itself or the underlying authentication mechanisms, all of which are also 
"protocols" in the generic sense.

The use of the phrase "application protocol" in this sense is common in 
discussions about security frameworks, and should not cause confusion.  In 
fact, I agree with Kurt that the use of the unqualified term "protocol" is 
confusing in this document, because in a document which defines a framework 
consisting of N+M+1 protocol components, the term is highly ambiguous, our 
definition notwithstanding.

However, I also agree that we need consistent usage throughout the 
document.  Either use "application protocol" everywhere, or not at all.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 21 Oct 2004 16:13:56 -0700

At 03:25 PM 10/21/2004, Jeffrey Hutzelman wrote:
>The syntax and semantics of authentication ID's are determined entirely by the authentication mechanism;

If you were to say the syntax and semantics of any
authentication identity information carried in the
exchange is specified by the mechanism's specification,
I would agree.

But, without that qualification, I would have to
disagree.  For instance, an application protocol can
certainly detail how authentication identities are to
represented in identity-assumption policy information
carried by the protocol, and associated semantics.

>All mechanisms are protocol-independent, and all protocol profiles are mechanism-independent.

 From the perspective of the SASL framework, yes.

>A particular _implementation_ must be able to perform the authorization check (can this authid use the requested autzid) and must be able to derive an authorization ID from an authentication ID.

Which requires may involve deriving an authentication ID from
credential information.   It is not appropriate to assume the
particular form of authentication identity in the credentials,
are the form used to establish this authorization identity.
For instance, consider EXTERNAL with TLS X.509 authentication.
The authentication identity might be the subject DN, or it
might be viewed as being one of the altSubjNames, or something
derived from this (and possible other stuff).

>These operations depend on both the mechanism and protocol profile in use, and their details are deliberately left to the implementation and to local policy.

And possible aspects of the application-level protocol specification.

For instance, it is reasonable for an application-level protocol
specification to specify how mechanism-specific authentication
identity forms relate to protocol-specific authentication forms,
as necessary say to detail how mechanism-specific credentials
(or associated policies) are to managed using the application-level
protocol.  Of course, an application-level protocol specification
detailing such things should not unnecessarily preclude use of
the mechanisms not explicitly discussed in the application-level
protocol specification.

Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 22 Oct 2004 14:29:44 +0100

Jeffrey Hutzelman wrote:

> The syntax and semantics of authentication ID's are determined 
> entirely by the authentication mechanism; the protocol has no say in 
> the matter.  All mechanisms are protocol-independent, and all protocol 
> profiles are mechanism-independent.
>
> A particular _implementation_ must be able to perform the 
> authorization check (can this authid use the requested autzid) and 
> must be able to derive an authorization ID from an authentication ID.  
> These operations depend on both the mechanism and protocol profile in 
> use, and their details are deliberately left to the implementation and 
> to local policy.

Do I need to change anything in the document?

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 22 Oct 2004 16:56:52 -0400

> Do I need to change anything in the document?

I'll answer a narrower question...
I'm not proposing any change to the document in relation to this item.
I was simply trying to clarify what looked like a point of confusion in
the ongoing discussion.

-- Jeff

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 23 Oct 2004 19:13:53 +0100

> s/user/client/  and be done with it.

I've done the change.

---

From: Sam Hartman <[email-masked]>
Date: Sun, 24 Oct 2004 17:13:15 -0400

Kurt> At 03:25 PM 10/21/2004, Jeffrey Hutzelman wrote:
    >> entirely by the authentication mechanism;

    Kurt> If you were to say the syntax and semantics of any
    Kurt> authentication identity information carried in the exchange
    Kurt> is specified by the mechanism's specification, I would
    Kurt> agree.

    Kurt> But, without that qualification, I would have to disagree.
    Kurt> For instance, an application protocol can certainly detail
    Kurt> how authentication identities are to represented in
    Kurt> identity-assumption policy information carried by the
    Kurt> protocol, and associated semantics.

I agree that they can do so in the sense that if the IESG approved it,
it would be a protocol action.  Application protocols should not say
anything about authentication identities though, because doing so
would tie them to a particular mechanism.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 24 Oct 2004 19:16:13 -0700

At 02:13 PM 10/24/2004, Sam Hartman wrote:

>it would be a protocol action.

LDAP and IMAP ACLs.

What's good is a standardize access control policy if
the standard does say how identities used in the
authentication exchange relate to identities appearing
in the policy?

Say an administrative client has created a Kerberos
principal for a user and then wants to authorize that
user to access an object on an LDAP server.  What DN
should the administrative client use as the subject
of the LDAP access control statement?

Without a standard of some kind here, it is not possible
to independently develop such a client.

>Application protocols should not say

No, it would require an update of the application protocol
specification to state how to manage identities associated
with that particular mechanism relate to identities in
the application protocol.  (This doesn't mean that one
cannot use new mechanisms in the protocol in absence of
this update, it says that one cannot use certain policy
features of that mechanism until its updated to deal
with the new mechanism.)

Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 25 Oct 2004 12:17:55 +0100

>identities in an identity assumption authorization policy.
I've updated the existing sentence as follows (I am still not satisfied 
with how it looks):

Any normalization of the authentication identity (for the purposes
of conducting authentication exchange) is defined by a particular
SASL mechanism, the protocol profile doesn't influence it.
Note, that the mechanism specification doesn't control how
authentication identity information is represented elsewhere.

I think we need to expand on "elsewhere" part.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Oct 2004 09:24:47 -0400

>>  I agree that they can do so in the sense that if the IESG
    >> approved it, it would be a protocol action.

    Kurt> LDAP and IMAP ACLs.

    Kurt> What's good is a standardize access control policy if the
    Kurt> standard does say how identities used in the authentication
    Kurt> exchange relate to identities appearing in the policy?

    Kurt> Say an administrative client has created a Kerberos
    Kurt> principal for a user and then wants to authorize that user
    Kurt> to access an object on an LDAP server.  What DN should the
    Kurt> administrative client use as the subject of the LDAP access
    Kurt> control statement?

I was thinking too narrowly.

--Sam

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 01 Oct 2004 23:05:31 +0200

Thanks,
Simon

---

From: Sam Hartman <[email-masked]>
Date: Fri, 01 Oct 2004 18:38:33 -0400

--Sam

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 02 Oct 2004 00:58:33 +0200

Thanks,
Simon

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 01 Oct 2004 16:12:05 -0700

Simon,

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 02 Oct 2004 01:25:32 +0200

Thanks,
Simon

---

From: Sam Hartman <[email-masked]>
Date: Fri, 01 Oct 2004 18:38:33 -0400

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Sat, 02 Oct 2004 14:52:58 -0400

--Sam

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 02 Oct 2004 12:27:46 -0700

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 15 Oct 2004 03:19:42 +0200

and semantics  

  and semantics

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 14 Oct 2004 19:10:17 -0700

Okay.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 21 Oct 2004 15:39:29 +0200

Yes.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 21 Oct 2004 11:40:50 -0700

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 21 Oct 2004 13:11:23 -0700

Kurt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 21 Oct 2004 18:25:53 -0400

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 21 Oct 2004 16:13:56 -0700

Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 22 Oct 2004 14:29:44 +0100

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 22 Oct 2004 16:56:52 -0400

-- Jeff

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 23 Oct 2004 19:13:53 +0100

I've done the change.

---

From: Sam Hartman <[email-masked]>
Date: Sun, 24 Oct 2004 17:13:15 -0400

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 24 Oct 2004 19:16:13 -0700

LDAP and IMAP ACLs.

Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 25 Oct 2004 12:17:55 +0100

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Oct 2004 09:24:47 -0400

--Sam