Subject: naming extensions issues

From: Leif Johansson <[email-masked]>
Date: Sun, 8 Mar 2009 17:32:17 +0100

Hello all,

Jumping right in as if everybody remembers exactly where we are with 
the naming extensions draft:

I'll update the current version of the draft with new boilerplate in a few 
minutes. The 4 major issues I have with the current model are:

* The critical flag
* The mapped flag

I don't see the usefulness of this flag. The model I'd like to work from is 
one where the authorization decisions are always pushed up the stack 
to the application - i.e the security context is established regardless of
weather attributes are understood or even available. It is then up to the
application to figure out if the context carries enough extra information 
to be useful.

In this model the application will understand the semantics of each 
attribute including the fact that it is derived (in other words the mapped
flag is a property of the attribute schema - not the context) from other
attributes or it won't care!

* The negative flag

Negative assertions are dangerous (I claim with my poker face on) If 
there isn't a use-case for them I think they should be removed on general 
principle. At least there should be a single example of a "native" claims-
based identity technology we would like to map to GSS-API naming 
extensions where negative assertions are used :)

* The use of OIDs

Clearly OIDs are nice and a well established  part of GSS-API. However
in many of the cases where attributes will arise naturally the "native"
naming is based on UR*'s. Requiring OIDs implies the creation of an
IANA registry for the mapping! The alternative is to pass names using 
gss_buffer_t (i.e octet strings).

	Cheers Leif

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 9 Mar 2009 00:32:32 -0500

> application to figure out if the context carries enough extra information 

I agree.  I had hoped that the system could do common mapping
operations, and indeed, it can, but those need to be initiated by the
application, not the mechglue.

> extensions where negative assertions are used :)

We don't need a "negative" flag, but we do need a "complete" flag so
that an application can evaluate negative ACL entries, particularly ones
where the subject of the ACE is a group.  I believe negative ACL entries
with group subjects are dangerous precisely because it's difficult to
ensure that full group membership context is always available, but
because such ACEs are used we do need a way to convey whether a name's
attributes are complete.

> gss_buffer_t (i.e octet strings).

Applications should use symbols to refer to these things.  Whether those
symbols resolve internally to OIDs or strings I don't really care.  If
they be strings then don't bother with gss_buffer_t since we're talking
about attribute names, which can be C strings in the C API (const char *).

I'm not sure that an IANA registry can be avoided though.  Can you
expand on that?

Nico
--

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 09 Mar 2009 09:44:48 +0000

>application to figure out if the context carries enough extra information 
I agree with you on this. So the critical flag can definitely go.

>flag is a property of the attribute schema - not the context)
>
I am not sure about the mapped flag yet. Do you have information to 
support the last claim?

> from other
Removing this looks fine to me.

>gss_buffer_t (i.e octet strings).
Can we use one of Nico's tricks to encode any string as an OID under a 
registered prefix ;-)?

A new registry would be fine with me, if people would bother 
registrering stuff in it.

---

From: Leif Johansson <[email-masked]>
Date: Wed, 11 Mar 2009 09:49:12 +0100

On Monday 09 March 2009 06:32:32 Nicolas Williams wrote:
> > I'll update the current version of the draft with new boilerplate in a
> > few minutes. The 4 major issues I have with the current model are:
> >
> > * The critical flag
> > * The mapped flag
> >
> > I don't see the usefulness of this flag. The model I'd like to work from
> > is one where the authorization decisions are always pushed up the stack
> > to the application - i.e the security context is established regardless
> > of weather attributes are understood or even available. It is then up to
> > the application to figure out if the context carries enough extra
> > information to be useful.
>
> > principle. At least there should be a single example of a "native"
> > claims- based identity technology we would like to map to GSS-API naming

I'm not sure I understand this. Are you saying there are negative ACLs
in the wild  that naming extensions need to support? Could you expand on
the semantics of the complete flag?

> I'm not sure that an IANA registry can be avoided though.  Can you

Because we can refer to existing registries - possibly this is an IANA 
registry registries but in any case it will be a smaller management load
than a full table of all urn:s people use in SAML (say) mapped to OIDs
which will be but a small part of the registry if we use OIDs.

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Wed, 11 Mar 2009 09:55:55 +0100

> I am not sure about the mapped flag yet. Do you have information to

Have you ever seen a single example where it was un-awkward to consume
authorization below the application - eg in the TLS or TCP layer of the stack?
Even consuming authz in the webserver is often un-intuitive for most web-
apps even if that often leads to nicer separation of concerns. Imagine telling
a webapp developer that authz is now pushed further down the stack :-)

> Can we use one of Nico's tricks to encode any string as an OID under a

That still requires a registry :-) On the other hand all OIDs are UR*s

> registrering stuff in it.

Another problem is that most GSS implementations define OIDs at compile-
time (correct me If I'm wrong please!) so if you need to add an attribute then 
you need to redeploy your app  which is a definite non-starter. Attributes 
need to be able to change at configure-time for apps.

	Cheers Leif

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 11 Mar 2009 11:09:42 +0000

>a webapp developer that authz is now pushed further down the stack :-)
I am not sure I understand this comment in relationship to my earlier comment.
All I was thinking is that if an attribute is constructed based on the value of 2 or more other attributes, the caller might want to know whether that was the case, or if the attribute was included with data itself.

But I might be forgetting what "mapped" means.

---

From: Leif Johansson <[email-masked]>
Date: Wed, 11 Mar 2009 21:22:12 +0100

On Wednesday 11 March 2009 12:09:42 Alexey Melnikov wrote:
> >authorization below the application - eg in the TLS or TCP layer of the
> > stack? Even consuming authz in the webserver is often un-intuitive for
> > most web- apps even if that often leads to nicer separation of concerns.
> > Imagine telling a webapp developer that authz is now pushed further down
> > the stack :-)
>
> I am not sure I understand this comment in relationship to my earlier
> comment. All I was thinking is that if an attribute is constructed based on
> the value of 2 or more other attributes, the caller might want to know
> whether that was the case, or if the attribute was included with data
> itself.
>

No you're right that is what mapped means. I misread your comment!

My response to _:this_ comment is that the attribute consumer (the 
application) already must know the semantics of the attributes it needs to 
consume. 

This knowledge involves much more than knowing if an attribute was derived 
or not and I'm not sure it can be encoded in a protocol. Put another way: 
mapped doesn't do enough to convey semantics of attributes.

	Cheers Leif

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 11 Mar 2009 15:36:34 -0500

> the semantics of the complete flag?

NT/NFSv4/ZFS-style ACLs allow you to have entries that DENY access to
the ACL entry (ACE) subject.

If the subject of a DENY ACE is a user then that's easy to check for
when doing file access authorization -- you always know the user ID of
the client.

If the subject of a DENY ACE is a group then you need to know with
certainty whether the client user is a member of that group.

If krb5 ticket authorization-data includes group membership data for the
client principal then it's crucial to know whether that group membership
list is complete.  If it is not complete then the server may want to
deny access to files when evaluating DENY ACEs with groups as subjects.

The Windows "PAC" contains a user's group memberships.  It is also
complete within the user's forest (and, IIRC, groups cannot have members
from other forests).

> which will be but a small part of the registry if we use OIDs.

Well, maybe, but I'd like to see concrete examples.  Not every use of
naming extensions will be for SAML things...

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 11 Mar 2009 15:39:18 -0500

> a webapp developer that authz is now pushed further down the stack :-)

Agreed.

> That still requires a registry :-) On the other hand all OIDs are UR*s

Does it?  Why?

> need to be able to change at configure-time for apps.

Hmmm, no, you can add OIDs at run-time.  There's a pair of deprecated
functions, gss_oid_to_str() and gss_str_to_oid(), that help with this,
but I don't see why they should have been deprecated (basically, it made
it possible to implement gss_release_oid() as a no-op, but the memory
mgmt can be dealt with anyways, so we can always undeprecate these).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 11 Mar 2009 15:41:06 -0500

> But I might be forgetting what "mapped" means.

Originally "mapped" was for things like the Windows PAC being used on a
Unix system: you might want to extract the individual items from the PAC
(user SID, group SIDs, home directory UNC, ...) and then have them mapped to
local equivalents (UID, GIDs, /net/...).

I think that was too ambitious.

---

From: Leif Johansson <[email-masked]>
Date: Thu, 12 Mar 2009 09:14:11 +0100

> > That still requires a registry :-) On the other hand all OIDs are UR*s

Do you have an algorithm for mapping urns to oids? If you don't there
will be a table lookup somewhere... Or am I missing something?

> > time (correct me If I'm wrong please!) so if you need to add an attribute
> > then you need to redeploy your app  which is a definite non-starter.
> > Attributes need to be able to change at configure-time for apps.
>

So there is a way to keep oids in play. I guess we need other opinions on
un-deprecating those... 

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Thu, 12 Mar 2009 09:26:39 +0100

On Wednesday 11 March 2009 21:36:34 Nicolas Williams wrote:
> > > > there isn't a use-case for them I think they should be removed on
> > > > general principle. At least there should be a single example of a
> > > > "native" claims- based identity technology we would like to map to
> > > > GSS-API naming extensions where negative assertions are used :)
> > >
> > > that an application can evaluate negative ACL entries, particularly
> > > ones where the subject of the ACE is a group.  I believe negative ACL
> > > entries with group subjects are dangerous precisely because it's
> > > difficult to ensure that full group membership context is always
> > > available, but because such ACEs are used we do need a way to convey
> > > whether a name's attributes are complete.
> >

OK I see. The problem is that in many cases it will be impossible to know
if the attribute set (eg group membership) represents a complete view of
the user. In general the users identity (as represented by the attributes
carried by the user) may be spread out over several "attribute providers".

The complete flag as I understand it assumes that the attribute provider
(eg idp) knows it is authoritative for a user. That may be true in certain
situations but in most cases it will not.

Of course that doesn't mean the flag is useless :) In non-federated
deployments it will still work. I pity the fool (TM) who tries to deploy 
negative ACLs in a federated setting though :-)

>
> > > Applications should use symbols to refer to these things.  Whether
> > > those symbols resolve internally to OIDs or strings I don't really
> > > care.  If they be strings then don't bother with gss_buffer_t since
> > > we're talking about attribute names, which can be C strings in the C
> > > API (const char *).
> > >

Correct. However OIDs are mappable to strings (eg as URNs) wo 
requiring the use of tables but the reverse isn't true.

	Cheers Leif

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Mar 2009 08:31:22 -0500

> carried by the user) may be spread out over several "attribute providers".

I'm perfectly happy if the complete flag is never set in practice
(though the PAC is a complete flag, in effect, so if the implementation
treats the contents of the PAC as indicidual attributes then the
complete flag must be set).

> situations but in most cases it will not.

That's fine.

> negative ACLs in a federated setting though :-)

Negative ACEs with groups as subject are bad.

> requiring the use of tables but the reverse isn't true.

Yes it is true: you can encode strings of characters as OID arcs (I
posted on the SASL WG about this).

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 13 Mar 2009 15:41:33 -0400

> posted on the SASL WG about this).

Yes, there is a way to represent any OID as a URN (and thus as a string), 
and a way to represent any string (incluing a URN) as an OID.  However, the 
mappings in question are not inverses of each other.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 16 Mar 2009 22:56:12 +0100

> mappings in question are not inverses of each other.

The sheer geeky-ness of the thing boggles the mind :-) and yet we are not
any closer to consensus.

	Cheers Leif

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 16 Mar 2009 17:01:20 -0500

> The sheer geeky-ness of the thing boggles the mind :-) and yet we are not

Make a proposal.  Include a C bindings snippet.

---

From: Leif Johansson <[email-masked]>
Date: Thu, 19 Mar 2009 13:08:44 +0100

On Monday 16 March 2009 23:01:20 Nicolas Williams wrote:
> > > Yes, there is a way to represent any OID as a URN (and thus as a
> > > string), and a way to represent any string (incluing a URN) as an OID. 
> > > However, the mappings in question are not inverses of each other.
> >

My proposal is that we use const char * and leave it up to the implementation
to decide how to interpret the attribute but that it SHOULD be either a string 
representation of an OID, a URN or a URI (those can easily be distinguished
from each other).

	Cheers Leif