Subject: [kitten] Another small update to naming exts

From: Nico Williams <[email-masked]>
Date: Mon, 5 Dec 2011 14:37:53 -0600

The security considerations section says:

  The security of the application may be critically dependent on the
  security of the attributes.  This document classifies attributes as
  asserted or authenticated.  Asserted (non-authenticated) attributes
  MUST NOT be used if the attribute has security implications for the
  application (eg authorization decisions) since asserted attributes
  may easily be controlled by the peer directly.

I want to relax this somewhat from "MUST NOT be used" to "MUST NOT be
used in any way except to reduce granted privilege ...".

Consider an assertion regarding process privileges (Solaris) /
capabilities (Linux).  The peer should use such an assertion only to
reduce privilege that would otherwise have been granted to the other.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 05 Dec 2011 16:19:32 -0500

I support relaxing the security considerations text for asserted
attributes to permit reduction in privilege.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 05 Dec 2011 22:48:07 +0100

> attributes to permit reduction in privilege.

+1

---

From: Martin Rex <[email-masked]>
Date: Tue, 6 Dec 2011 03:13:36 +0100 (MET)

> reduce privilege that would otherwise have been granted to the other.

That sounds like a bad idea and *will* confuse apps developers,
create a false sense of security and cause security problems.

Like many of those "client-side" security features that Microsoft
had in SMB/CIFS, such as not seeing shares with a $ char at the end
in the "net view" output and not being able to cd upwards in a share
when using a Windows client rather than a samba client.

-Martin

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 6 Dec 2011 02:45:08 +0000

>create a false sense of security and cause security problems.

Is the general provision on differentiating treatment of "unauthenticated"
attributes any less likely to confuse the same developers?

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Tue, 06 Dec 2011 10:23:17 -0500

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> That sounds like a bad idea and *will* confuse apps
    Martin> developers, create a false sense of security and cause
    Martin> security problems.

Martin, I think it is valuable to be able to represent mechanism
features such as ap-req authorization data in Kerberos.