Re: [Ietf-krb-wg] Review of draft-sorce-krbwg-general-pac-02

[Nico Williams <[e-mail]>]

On Tue, Jun 21, 2011 at 7:12 AM, Josh Howlett <[e-mail]> wrote:
> I took an action at the Prague meeting to review this document.
>
> 0. Attribute definition
>
> The document defines a set of attributes, and outlines an extensibility
> mechanism for incorporating other attributes. While the semantics
> associated with the attributes defined in section 4 seem entirely
> reasonable, I am curious why the authors chose to define a
> document-specific attribute schema rather than adopt the semantics from
> existing attribute schema (e.g. RFC 2307) where equivalent semantics may
> have already been defined.

I think it's because RFC2307's attributes are not necessarily what we
want to use in raw form.  For example, in the PAD we want names and
IDs, but RFC2307 doesn't give us a single name+ID attribute, thus to
use RFC2307 we might have to actually store... what? ASN.1 encoded
LDAP responses to searches?  That's not a terrible idea, but it does
strike me as very odd; we should think about it, even if only to
dismiss it.

One nice thing about including verbatim LDAP searches and responses is
that the system would be inherently extensible.  But the result would
be rather verbose!

> 1. Encoding

I don't care that much about encoding.  I'd prefer an encoding that
produces small size over all other considerations because ticket size
is an important consideration here.  I like ASN.1 (though I dislike
DER), and in particular I like Heimdal's ASN.1 compiler, which makes
it easier to handle new ASN.1 modules.

> 2. Attribute semantics
>
> The use-case that motivates the document is authorisation in cross-realm
> scenarios. The document notes that there are some challenges with some of
> the proposed authorisation semantics in cross-realm scenario (e.g.
> identifier collisions), and that local manipulation of incoming attribute
> values may be necessary.
>
> In contemporary federated deployments, it is common to manage this
> manipulation explicitly by passing 'entitlement' values rather than
> explicit authorisations: the privileges associated with an entitlement are
> derived locally.

That's pretty much with Simo's proposal does: it's the end node's
responsibility (or the last hop realm's) to map remote authorization
data to local authorization data.

I would like additional authorization data elements besides UID and
GIDs.  I'm thinking of: netgroups, labels (think Smack, MLS, ...), and
privileges.  See
http://tools.ietf.org/html/draft-ietf-nfsv4-rpcsec-gssv3-00 for more
information.

> I encourage the authors to consider the potential of attributes with
> entitlement semantics, and also entitlement values that may have general
> applicability.

+1, though I think we'll need specific examples in order to get the
discussion going.

Nico
--
_______________________________________________
ietf-krb-wg mailing list
[e-mail]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg