Subject: [kitten] Status of naming extensions

From: Sam Hartman <[email-masked]>
Date: Fri, 01 Apr 2011 03:27:55 -0400

I'm not sure if I will be in the session today.
So I wanted to give a status of naming extensions.

We submitted a new version that had updates based on my comments in
Beijing.  We've received some comments from Scott about whether the
clarity was sufficient.  Now that Scott has implemented against the
spec, I think he's in a good position to say either that it looks good
or it needs more detail.

We had a last call.
Simon raised significant comments not against the new text, but against
the text we all thought was OK last time around.

Unfortunately it's clear we were wrong.
The authors need to make a pass over the API details and fix Simon's
issues and similar issues.

We need to coordinate and get the chairs a new milestone date.

---

From: "Cantor, Scott E." <[email-masked]>
Date: Fri, 1 Apr 2011 18:09:46 +0000

>spec, I think he's in a good position to say either that it looks good

My recollection is that the part I found a bit unclear was the section
about attribute naming. I think that's mainly because it spends some time
discussing how one shouldn't name SAML attributes but doesn't actually
suggest an explicit way to do so. Since we're in the middle of coming up
with conventions for that in Moonshot, it seems timely to ask whether we
shouldn't propose a separate RFC or OASIS draft to nail that down.

This draft mentions the need for a context indicator that is clearly
separable from the NameFormat/Name. My preference is for a fixed string
because I think the names should be consistent and deriveable, but a truly
contextual name that's still fairly generatable would be the issuer, of
course.

In terms of my coding, I was mainly following header files from Kerberos
(and managed to get that aspect right the first time, so I guess it wasn't
that hard).

We did have the issue that we really need a way to export and import a
composite gss_name_t that preserves the attributes, and I guess the
problem there is an OID that's yet to be defined...

-- Scott

---

From: Luke Howard <[email-masked]>
Date: Sat, 2 Apr 2011 10:48:21 +1100

> problem there is an OID that's yet to be defined...

This should happen when the draft becomes an RFC, unfortunately it doesn't help our implementation in the meantime.

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Sat, 2 Apr 2011 16:16:26 +1100

> because I think the names should be consistent and deriveable, but a truly

+1

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Sat, 2 Apr 2011 16:31:17 +1100

>> because I think the names should be consistent and deriveable, but a truly

A consistent attribute name for retrieving the underlying assertion would be a big boon for the (EAP to Kerberos) SAML protocol transition project I'm working on now.

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Sat, 2 Apr 2011 19:44:55 +1100

> A consistent attribute name for retrieving the underlying assertion would be a big boon for the (EAP to Kerberos) SAML protocol transition project I'm working on now.

Maybe even with a constant like GSS_C_ATTR_SAML_ASSERTION.

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Sun, 3 Apr 2011 01:11:29 +1100

> This should happen when the draft becomes an RFC, unfortunately it doesn't help our implementation in the meantime.

If there's a way of getting this OID sooner rather than later, that would very useful.

-- Luke

---

From: Sam Hartman <[email-masked]>
Date: Sat, 02 Apr 2011 17:58:41 -0400

>>>>> "Luke" == Luke Howard <[email-masked]> writes:

    Luke> On 02/04/2011, at 4:16 PM, Luke Howard wrote:

    >>> separable from the NameFormat/Name. My preference is for a fixed
    >>> string because I think the names should be consistent and
    >>> deriveable, but a truly
    >> 
    >> +1

    Luke> A consistent attribute name for retrieving the underlying
    Luke> assertion would be a big boon for the (EAP to Kerberos) SAML
    Luke> protocol transition project I'm working on now.

There's a fair amount of text in the draft explaining why this is
probably a bad idea.  See the section on context.  For example a
KDC-issued assertion as an attribute container within a local realm has
very different semantics than an assertion from AAA.

I think it's fine to use the same attribute for any of the AAA contexts.
It's quite probable that SAML-EC2 and gss-eap can share the same
attribute names as well, and so perhaps they need a better name.

---

From: Sam Hartman <[email-masked]>
Date: Sat, 02 Apr 2011 18:01:57 -0400

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

    Cantor,> This draft mentions the need for a context indicator that
    Cantor,> is clearly separable from the NameFormat/Name. 

I don't think it does, and I'm not actually convinced that's desirable.
The draft mentions that  names need to have context.
I don't want to disallow singleton names like the URN we plan to
register for the gss-eap (or broader if they share the same context)
SAML assertion.

---

From: "Cantor, Scott E." <[email-masked]>
Date: Sat, 2 Apr 2011 22:06:34 +0000

> very different semantics than an assertion from AAA.

I don't think it's a good idea to try and make up for the limited bandwidth of the API here by burying information in the attribute names, particularly since using different names is a significant cost for deployers. If using "fixed" SAML attribute names isn't appropriate for some deployments because of these concerns, that's where local mapping and filtering mechanisms should take over, by processing a SAML assertion directly.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Sun, 03 Apr 2011 10:19:58 -0400

>> KDC-issued assertion as an attribute container within a local
    >> realm has very different semantics than an assertion from AAA.

    Cantor,> I don't think it's a good idea to try and make up for the
    Cantor,> limited bandwidth of the API here by burying information in
    Cantor,> the attribute names, particularly since using different
    Cantor,> names is a significant cost for deployers. If using "fixed"
    Cantor,> SAML attribute names isn't appropriate for some deployments
    Cantor,> because of these concerns, that's where local mapping and
    Cantor,> filtering mechanisms should take over, by processing a SAML
    Cantor,> assertion directly.

I'd like to explicitly ask the chairs to make a call for whether this is
re-opening a new issue.  I believe that between Beijing and the last
call, the basic direction for how to deal with context should be closed
at this point.

As I've said before, I don't think local filtering and mapping is
appropriate because:

1) Absent context in the name I don't think we have a rich enough
mechanism to have high confidence that local filtering could be done
reasonably.

2) I think it's important that we be able to standardize attribute
behavior in some applications.
I don't think we can do this while depending on local filtering

3) The consequences of failing insecure seem bad. The consequences of
failing to expose the attributes without explicit configuration also
seem very problematic.

It's possible this is all broken and we'll be revisiting the whole
approach in a couple of years.
However, I personally have two hard constraints.
First, I want to see us publish something that permits the IETF to
standardize attributes for use in IETf protocols and expect them to be
there.
I think that means some level of context and not depending on filtering.
Second, I'd like to see us publish something that is an incremental
evolution of what we've been working with and what people have shipped.

It's my personal opinion that from a process standpoint, we've already
had this discussion and that no new information has come forward.
Scott may be right that we'll end up revisiting our approach.
However, I know I don't have the energy to start over on this spec right
now, and I think that we've demonstrated enough value that publishing
what we have as a proposed standard is far better than giving up.

---

From: Sam Hartman <[email-masked]>
Date: Sun, 03 Apr 2011 11:58:06 -0400

>>>>> "Sam" == Sam Hartman <[email-masked]> writes:

    >>> There's a fair amount of text in the draft explaining why this
    >>> is probably a bad idea.  See the section on context.  For
    >>> example a KDC-issued assertion as an attribute container within
    >>> a local realm has very different semantics than an assertion
    >>> from AAA.

>     Cantor,> I don't think it's a good idea to try and make up
> for the Cantor,> limited bandwidth of the API here by burying
> information in Cantor,> the attribute names, particularly since
> using different Cantor,> names is a significant cost for
> deployers. If using "fixed" Cantor,> SAML attribute names isn't
> appropriate for some deployments Cantor,> because of these
> concerns, that's where local mapping and Cantor,> filtering
> mechanisms should take over, by processing a SAML Cantor,>
> assertion directly.

    Sam> I'd like to explicitly ask the chairs to make a call for
    Sam> whether this is re-opening a new issue.  

I realize I was not clear on what I meant by this.
I believe that the question of whether we will embed context in names is
already decided.

To what extent SAML names share a context I think is very much something
we still need to discuss.

I think that GSS-EAP, SAML-EC and the browser SAML mechanism can almost
certainly all use the same context.

I think that cases where a domain-local policy authority such as a KDC
has applied additional policy (discussed at the Kerberos consortium
conference and long ago on the kaml mailing list) need a separate
context.
It might well be appropriate in this case to also echo the names into
the context used by SAML-EC, GSS-EAP and the browser mechanism.
I'm not aware of anyone proposing standardizing this context or
implementing at this time.

---

From: "Cantor, Scott E." <[email-masked]>
Date: Sun, 3 Apr 2011 19:44:40 +0000

> call, the basic direction for how to deal with context should be closed

The reason I said something is that you asked me if I thought the spec was clear now. This was the issue I felt was unclear at the time. I'm happy to let it lie, but see below.

> I don't think we can do this while depending on local filtering

I agree, that's basically the point I was making.

> failing to expose the attributes without explicit configuration also

This is my concern. It doesn't seem like you can add this context to the names of the attributes and then expect that they'll be accessible to applications without explicit configuration. Where is the context going to come from?

-- Scott

---

From: Luke Howard <[email-masked]>
Date: Mon, 4 Apr 2011 09:06:32 +1000

> we still need to discuss.

Note my specific concern (although it may amount to the same thing) was not how attributes extracted from the assertion were named, but how the assertion itself (if available directly) was named.

-- Luke

---

From: Sam Hartman <[email-masked]>
Date: Mon, 04 Apr 2011 07:49:16 -0400

>> To what extent SAML names share a context I think is very much
    >> something we still need to discuss.

    Luke> Note my specific concern (although it may amount to the same
    Luke> thing) was not how attributes extracted from the assertion
    Luke> were named, but how the assertion itself (if available
    Luke> directly) was named.

I think this is effectively the same, although the text string may
differ slightly.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 04 Apr 2011 08:34:57 -0400

>> I'd like to explicitly ask the chairs to make a call for whether
    >> this is re-opening a new issue.  I believe that between Beijing
    >> and the last call, the basic direction for how to deal with
    >> context should be closed at this point.

    Cantor,> The reason I said something is that you asked me if I
    Cantor,> thought the spec was clear now. This was the issue I felt
    Cantor,> was unclear at the time. I'm happy to let it lie, but see
    Cantor,> below.

    >> 2) I think it's important that we be able to standardize
    >> attribute behavior in some applications.  I don't think we can do
    >> this while depending on local filtering

    Cantor,> I agree, that's basically the point I was making.

I think we may be differing in how much context we think is necessary
here.

    >> 3) The consequences of failing insecure seem bad. The
    >> consequences of failing to expose the attributes without explicit
    >> configuration also seem very problematic.

    Cantor,> This is my concern. It doesn't seem like you can add this
    Cantor,> context to the names of the attributes and then expect that
    Cantor,> they'll be accessible to applications without explicit
    Cantor,> configuration. Where is the context going to come from?

In all the discussions across krb-wg, kitten, kaml, moonshot, and abfab,
I've seen what I would consider few contexts discussed:

1) Unauthenticated: The security mechanism has no confirmation where the
attributes come from. Possibly useful for restrictions or preferences,
but definitely not entitlements or auditing.

2) Federated: We know who asserted the attribute, we've checked things
like scope. However we have not actually applied local policy or
filtering.

3) Kerberos KDC issued/PAC/PAD: Someone in our domain has made policy
decisions about the attributes. They recommend we trust them; absent
local policy it would be reasonable to do so.

4) Local: Local policy has explicitly asserted or mapped something to
this attribute.

I believe that these sorts of contexts are hard coded.

I believe these contexts also have the property that if an application
does not understand the context, it should generally not try to
interpret the attribute.
Well, actually, the above seem to be ordered. It would generally be OK
if an application would accept a lower numbered context to accept a
higher-numbered context. However, it would be better for a
Kerberos-style application to completely ignore federated attributes
than to interpret them if it does not understand them.

So, I think these contexts can be hard-coded in IETF specs.
I do think that local policy may need to tune things: filtering out
attributes that are present in some cases, remapping things fand
indicating trust in others.