Subject: [abfab] Comments on draft-ietf-abfab-gss-eap-naming-01

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 28 Nov 2011 15:52:04 +0000

Just some small editorial suggestions...

Section 3, third paragraph, "However for other name formats,
including...", strike "for".

Same paragraph, the sentence "So, based on who is named by the name, the
semantics
   of the attribute can be determined." doesn't read terribly well. Which
"name" are we talking about? I think you mean the name of the issuer, not
the name of the attribute, but it's unclear since the document as a whole
is mostly about attribute naming.

Section 4, fourth paragraph, "trust context is an important part of the
context", I suggest "trust context is an important part of this overall
context".

Same paragraph, there's a "AA" missing a third A.

Substantive questons on section 6:

I think you're proposing the name
"urn:ietf:params:gss-eap:saml-aaa-assertion" be shared by both GSS-EAP and
GSS-SAML-EC? I'm not a name bigot, I don't much care about it, but I
wonder about the use of both gss-eap and moreso "-aaa-" in a name used
with a mechanism that's neither EAP nor AAA. Is there a reason not to just
use a more generic name? I note in particular the "-aaa-" part is missing
from the SAML attribute section 6.2 constant, so maybe this was an
oversight. They should be consistent in any case.

There's also the question of value representation. Is the intent here to
capture the value as expressed in XML directly, or the value subsequent to
local processing such as a SAML implementation might perform? I think we
need to say something, but I'll refrain from suggesting anything until we
answer that question.

Finally, I would add a third section to cover SAML NameID elements. A lot
of SAML implementations do a poor job with attributes, and I've tended to
always cover NameIDs in a consistent way to make sure those are handled
uniformly so relying parties can deal with either. The value issue is also
a consideration here, so I can propose text once we settle that. In terms
of naming, the <NameID>'s Format attribute is essentially the unique name
you want, so it's a two part name, probably
"urn:ietf:params:gss-eap:saml-nameid" and then the Format.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Mon, 28 Nov 2011 11:04:25 -0500

The actual URNs in the current doc are completely wrong. In particular
for anything shared I don't think the string gss-eap should appear.

GSS-API naming extensions has two value forms.  The first is intended as
a raw form, presumably XML.  The second is a display value and is
implementation dependent.  You get both when you get a name
attribute. (Well, you can request one or both).

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 28 Nov 2011 16:16:37 +0000

>for anything shared I don't think the string gss-eap should appear.

Ok.

>attribute. (Well, you can request one or both).

Ok, then I suspect we should probably provide guidance, possibly going so
far as a MUST as to how to handle that. In particular, you presumably want
the XML to be well-formed, so that creates additional work for the
mechanism or whatever's creating the name attribute to serialize it safely.

If the XML is the "raw" form, then the question is what the display form
would be. When something like Shibboleth decodes the XML into something
easily string-able, it does that by turning it from SAML into a local
attribute, which wouldn't address this question.

It could be left implementation dependent what the display name for the
raw SAML is, or one could say that for the common case of a simple-valued
element, you just use the text content of the element, otherwise undefined.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Mon, 28 Nov 2011 11:43:37 -0500

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

    Cantor,> On 11/28/11 11:04 AM, "Sam Hartman" <[email-masked]> wrote:
    >> The actual URNs in the current doc are completely wrong. In
    >> particular for anything shared I don't think the string gss-eap
    >> should appear.

    Cantor,> Ok.

    >> GSS-API naming extensions has two value forms.  The first is
    >> intended as a raw form, presumably XML.  The second is a display
    >> value and is implementation dependent.  You get both when you get
    >> a name attribute. (Well, you can request one or both).

    Cantor,> Ok, then I suspect we should probably provide guidance,
    Cantor,> possibly going so far as a MUST as to how to handle
    Cantor,> that. In particular, you presumably want the XML to be
    Cantor,> well-formed, so that creates additional work for the
    Cantor,> mechanism or whatever's creating the name attribute to
    Cantor,> serialize it safely.

I'd kind of assumed that you want the raw value of the element in
question. At least if there are no elements just data such as a string,
I think you want that.  I agree that if there are XML elements in the
attribute value, you probably do need to handle namespaces and make it
well-formed.

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 28 Nov 2011 16:57:17 +0000

>attribute value, you probably do need to handle namespaces and make it

Yes, that's fine. We just need to explicitly say that or it will be
ambiguous.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Mon, 28 Nov 2011 12:05:51 -0500

Cantor,> On 11/28/11 11:43 AM, "Sam Hartman" <[email-masked]> wrote:
    >> question. At least if there are no elements just data such as a
    >> string, I think you want that.  I agree that if there are XML
    >> elements in the attribute value, you probably do need to handle
    >> namespaces and make it well-formed.

    Cantor,> Yes, that's fine. We just need to explicitly say that or it
    Cantor,> will be ambiguous.

Agreed.
So,  resolving your editorial issues is trivial.

I already have an action item to run a proposed set of URNs by kitten
and abfab.

Any chance you could give me text on the values and name IDs? The latest
XML source is in the draft repository, although plain text is also fine.

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 28 Nov 2011 20:58:39 +0000

>XML source is in the draft repository, although plain text is also fine.

Ok, here's some text to try. I included language about character encoding.
I don't know if that's needed, but I suspect something probably is,
whether it's this or something else.

There's also some ugly text about NameID qualifiers because of an
unfortunate decision to allow defaulting there. I captured what my
guidelines would be in the general case of a SAML implementation.

For section 6.2:

Each attribute carried in the assertion SHOULD also be a GSS name
attribute.  The name of this attribute has three parts, all separated by
an ASCII space character.  The first part is TBD.  The second part is the
URI for the <saml:Attribute> element's NameFormat XML attribute.  The
final part is the <saml:Attribute> element's Name XML attribute.

If the content of each <saml:AttributeValue> element is a simple text node
(or nodes), then the raw and "display" values of the GSS name attribute
MUST be the text content of the element(s) encoded as UTF-8.

If the value is not simple, then the raw value(s) of the GSS name
attribute MUST be the well-formed serialization of the
<saml:AttributeValue> element(s) encoded as UTF-8. The "display" values
are implementation-defined.

Then the last paragraph is the same as what you have now.

Then add section 6.3 SAML Name Identifiers:

The <saml:NameID> carried in the subject of the assertion SHOULD also be a
GSS name attribute. The name of this attribute has two parts, separated by
an ASCII space character. The first part is TBD. The second part is the
URI for the <saml:NameID> element's Format XML attribute.

The raw value of the GSS name attribute MUST be the well-formed
serialization of the <saml:NameID> element encoded as UTF-8. The "display"
value is implementation-defined. For formats defined by section 8.3 of
[SAMLCORE], missing values of the NameQualifier or SPNameQualifier XML
attributes MUST be populated in accordance with the definition of the
format prior to serialization. In other words, the defaulting rules
specified for the "persistent" and "transient" formats MUST be applied
prior to serialization.

This attribute SHOULD be marked authenticated if the name identifier is
contained in a SAML assertion that has been successfully validated back to
the trusted source of the peer credential.  In the GSS-EAP mechanism, a
SAML assertion carried in an integrity-protected and authenticated AAA
protocol SHALL be sufficiently validated.  An implementation MAY apply
local policy checks to this assertion and discard it if it is unacceptable
according to these checks.

-- Scott