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

[Josh Howlett <[e-mail]>]

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.

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."

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.

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.

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.

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.

Josh.



JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

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