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

[Simo Sorce <[e-mail]>]

On Tue, 2011-06-21 at 12:12 +0000, Josh Howlett 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.

This is a good suggestion, we were still working out some of the
necessary fields, and as you can see there are more than what RFC2307
defines. But I think it is a good idea to redefine those that match by
pointing at RFC2307. Although there are some attributes that may require
further explanation.

For example I haven't mentioned names case-sensitivity, and although I
really would like to define all names as case insensitive I am sure some
people may object because theoretically POSIX define user and group
names as case sensitive.

So if it is ok to refer to RFC2307 and then further explain/define some
aspects of the attributes I think we can do that.

> 1. Encoding
> 
> The document specifies the use of ASN.1 encoding of attributes, on the
> basis that this is what Kerberos uses. As a general principle the choice
> of encoding should, IMO, be determined principally by the preferences of
> the parties expected to issue and consume the PAD. For the purposes of
> this document, I would expect those to be the KDC (issuer) and -- for
> modern usage of Kerberos -- the GSS acceptor (consumer). So, in the former
> case the choice of ASN.1 is reasonable. However, in the second case I
> would expect that application developers would prefer to use GSS-API
> naming extensions, rather than parse the PAD directly. Quoting
> draft-ietf-kitten-gssapi-naming-exts:
> 
> "The goal is to make information modelled as "name attributes" available
> to applications.  Such information MAY for instance be used by
> applications to make authorization-decisions.  For example, Kerberos V
> authorization data elements, both in their raw forms, as well as mapped to
> more useful value types, can be made available to GSS-API applications
> through these interfaces."

Luke Howard also proposed in private conversations to also expose PAD
attributes through named extensions, the way the PAD is encoded should
not be an obstacle to that, and I genewrally agree it is a good idea.

> GSS naming extensions is encoding agnostic and so GSS implementations
> could in principle be extended to support the proposed PAD format, but in
> practice it may be more efficient to re-use encodings that GSS acceptor
> implementations already (or are likely to) support, such as SAML, rather
> than invent a new one.

While GSS may find SAML slightly easier, we have to consider also the
KDC implementations. And space constraints. In the KDC SAML parsers are
not available, plus SAML tends to be quite more verbose and eat more
space (the PAD is attached to the ticket and we do not want overly large
tickets if possible). Plus there is the signatures part, which requires
us to treat the PAD as a buffer.

> It is worth noting that the SAML Assertion element has the semantics
> described in section 5.1 ("PAD Format"); consequently, in principle a SAML
> attribute assertion could be used as the PAD payload.

It could, but I didn't want to add SAML as a dependency for a KDC. ASN.1
while not fancy is available already in both the KDC and the Kerberos
client libraries, so it seems a more common denominator.

> 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.
> 
> I encourage the authors to consider the potential of attributes with
> entitlement semantics, and also entitlement values that may have general
> applicability.

I wanted to push this kind of authorization attributes as an optional
extension. The reason is that POSIX like attributes are quite easy to
agree on, their use and need is well understood and the need for mapping
is also well understood.

I didn't want to go beyond that in this first standard because it would
require much more work to reach consensus. That's why the format allows
for optional additional buffers, there is where I see additional future
work adding more complex authorization attributes, including, possibly
SAML assertions and entitlement semantics.

> 3. Summary
> 
> I recommend that the authors consider the use of SAML encoding for the
> PAD, and whether exposing these values through GSS-API naming extensions
> provides a better integration story for application developers. The
> authors should also consider whether section 4 could be re-factored to
> make greater use of existing attribute schema. In particular, it might be
> useful to consider the use of entitlements in addition to explicit
> authorisations.
> 
> Hope this helps.

It certainly hepls, and I welcome further thoughts along these lines.
This is exactly the kind of feedback I am looking forward to.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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