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

From: Josh Howlett <[email-masked]>
Date: Tue, 21 Jun 2011 12:12:43 +0000

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
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simo Sorce <[email-masked]>
Date: Tue, 21 Jun 2011 08:44:31 -0400

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

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

> implementations already (or are likely to) support, such as SAML, rather

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.

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

> entitlement semantics, and also entitlement values that may have general

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.

> useful to consider the use of entitlements in addition to explicit

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

---

From: Josh Howlett <[email-masked]>
Date: Tue, 21 Jun 2011 13:24:20 +0000

>us to treat the PAD as a buffer.

...

>client libraries, so it seems a more common denominator.

I'm certainly sympathetic to those arguments, but would be interested to
hear the opinions of implementors. I think Luke has already implemented
something for MIT...?

Another consumer that I forgot to mention is the n-tier, but I don't think
that's different in this context from the first GSS acceptor.

(On entitlements)
>require much more work to reach consensus.

Sounds reasonable to me.

Josh.

---

From: "Cantor, Scott E." <[email-masked]>
Date: Tue, 21 Jun 2011 15:20:14 +0000

>client libraries, so it seems a more common denominator.

Perhaps somebody should simply define an ASN.1 encoding for SAML
assertions.

The encoding is unimportant. The semantics are where all the interesting
code lives.

-- Scott

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 21 Jun 2011 13:49:44 -0700

> The encoding is unimportant. The semantics are where all the interesting

+1

Also +1 to direct reference to RFC2307.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Martin Rex <[email-masked]>
Date: Wed, 22 Jun 2011 01:22:41 +0200 (MEST)

> Perhaps somebody should simply define an ASN.1 encoding for SAML

Please DON'T!  In the end, everyone would have to implement
both, making that part of the problem at least twice as bad,
and one would have to constantly maintain/update a mappings spec.

This would only result in massive code bloat all over the place
and amplify inconsistencies between independent codebases.

-Martin

---

From: "Cantor, Scott E." <[email-masked]>
Date: Wed, 22 Jun 2011 01:01:11 +0000

>and one would have to constantly maintain/update a mappings spec.

Everyone is already forced to implement "both", the only question is
whether there's any commonality at the logical level.

"Both" isn't even accurate, since OAuth is reinventing the same stuff
already, with yet another encoding.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Jun 2011 09:00:55 -0400

>>>>> "Cantor," == Cantor, Scott E <[email-masked]> writes:

    Cantor,> On 6/21/11 8:44 AM, "Simo Sorce" <[email-masked]> wrote:
    >>> 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.

    Cantor,> Perhaps somebody should simply define an ASN.1 encoding for
    Cantor,> SAML assertions.

    Cantor,> The encoding is unimportant. The semantics are where all
    Cantor,> the interesting code lives.
<hat role="individual">

I agree with Scott.  I don't care about the encoding.  However I do
believe this document should give explicit guidance for how PAD
attributes are surfaced through naming extensions.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simo Sorce <[email-masked]>
Date: Wed, 22 Jun 2011 13:03:54 -0400

> attributes are surfaced through naming extensions.

Are you willing to provide or point to sample language for one of the
attributes?
I am willing to integrate that guidance if examples are provided.

Simo.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Jun 2011 15:21:28 -0400

Yes.
I think holding off until some of the bigger issues settle (say a week
or two) would be good then I can work with you on this.

I think Luke will also be interested in helping here, but he's fairly
busy through end of summer.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simo Sorce <[email-masked]>
Date: Wed, 22 Jun 2011 15:26:25 -0400

> busy through end of summer.

Ack, I'll wait for your input then.

Simo.