Subject: [abfab] Comments on draft-ietf-abfab-aaa-saml-11

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 7 Aug 2015 14:58:12 +0000

Just a brief review primarily of section 4 and the metadata material.

4.3.2

I wouldn't denote "entityID" as <entityId> as that suggests an XML element by that name, which doesn't exist in SAML.

Apologies if it's covered elsewhere, but these bullets seems to lack specificity:

   o  RADIUS client identity in trusted digitally signed SAML request.

   o  RADIUS realm in trusted digitally signed SAML response or
      assertion.

How precisely is the RADIUS identity expressed in the SAML messages?

4.3.3

One thing missing is a definition of what to put in the protocolSupportEnumeration attribute for these roles. Presumably that would be some identifier representing whatever family of profiles this binding is intended to be used with. In SAML it's used to delineate SAML 1 and SAML 2 support. It's a required attribute on every RoleDescriptor, so something has to be in it.

4.3.4

One point is that in the XML examples shown, the various string-valued elements are shown with whitespace around the values. It would be unusual to normatively address the trimming question, but I don't know if you want the examples to actually encourage extra whitespace given that no matter what you say or do, some implementations inevitably won't trim. In fact, it's probably worth noting it if you need implementations to *not* trim, but I assume these elements by and large don't expect leading/trailing WS to be significant.

4.5

This text reads a bit oddly given that the previous section explicitly covers the metadata extensions defined. At minimum, it seems like maybe it should indicate that if metadata *is* used, those roles MUST be present?

-- Scott

---

From: Alejandro Pérez Méndez <[email-masked]>
Date: Sat, 8 Aug 2015 09:26:02 +0200

Hi Scott,

thanks for the quick review. See my comments inline.

> I wouldn't denote "entityID" as <entityId> as that suggests an XML element by that name, which doesn't exist in SAML.

Right, I will remove it.

> How precisely is the RADIUS identity expressed in the SAML messages?

Although it would be possible doing so, we agreed that this document 
would only provide a technical solution for representing the AAA name in 
trusted SAML metadata. If someone wanted to express them in SAML 
messages, he would need to define how this would be done.

I will state something like that at the beginning of section 4.3.3 to 
make it clear.

> One thing missing is a definition of what to put in the protocolSupportEnumeration attribute for these roles. Presumably that would be some identifier representing whatever family of profiles this…

That confuses me. This attribute is already defined in the description 
of the RoleDescriptor type, and I thought that I did not need to provide 
further information. For instance, in the saml-metadata-2.0-os document, 
other subtypes of RoleDescriptor such as SSODescriptor or 
AttributeAuthorityDescriptor, or even subsubtypes such as 
IDPSSODescriptor, say nothing about the value of 
protocolSupportEnumeration. I just followed the same kind of description 
they do. In fact, in that document, the only place besides 
RoleDescriptor where protocolSupportEnumeration appears is in section 
"2.6 Examples", so I did include it in my examples.

Where do you suggest to include this kind of description? In the 
introductory text for each role? Why other subtypes of RoleDescriptor do 
not provide it?

> One point is that in the XML examples shown, the various string-valued elements are shown with whitespace around the values. It would be unusual to normatively address the trimming question, but I…

You are right, I don't want the extra whitespaces to be included in the 
value of the element. What do you suggest?:
a) making the example look like this

              <RADIUSRealm>idp.com</RADIUSRealm>

or
b) using another type that has implicit trimming capabilities (if such 
thing exists)
For instance, I've seen that the localizedNameType extends xs:string, 
but it seems to have no problems with trimming.
This text is extracted from saml-metadata-2.0-os section 2.6:

<OrganizationDisplayName xml:lang="en">
     Identity Providers R US, a Division of Lerxst Corp.
</OrganizationDisplayName>

where OrganizationDisplayName is of type localizedNameType, and it is 
shown with whitespace around the values.
Does this subtype define anything special that implies trimming?

> This text reads a bit oddly given that the previous section explicitly covers the metadata extensions defined. At minimum, it seems like maybe it should indicate that if metadata *is* used, those r…

You're completely right. I will update the text.

Thanks!

-- Alejandro

>
> -- Scott
>
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: "Cantor, Scott" <[email-masked]>
Date: Sun, 9 Aug 2015 18:59:45 +0000

On 8/8/15, 3:26 AM, "abfab on behalf of Alejandro Pérez Méndez" <[email-masked] on behalf of [email-masked]> wrote:

>
>That confuses me. This attribute is already defined in the description of the RoleDescriptor type, and I thought that I did not need to provide further information. For instance, in the saml-metadata-2.0-os document, other subtypes of RoleDescriptor such as SSODescriptor or AttributeAuthorityDescriptor, or even subsubtypes such as IDPSSODescriptor, say nothing about the value of protocolSupportEnumeration. I just followed the same kind of description they do. In fact, in that document, the only place besides RoleDescriptor where protocolSupportEnumeration appears is in section "2.6 Examples", so I did include it in my examples.

It may be that the right value here is just "urn:oasis:names:tc:SAML:2.0:protocol", which is the one that's called out by default in the metadata spec for SAML 2.0 entities.

Since these roles were, I thought, more intended to describe RADIUS entities, that didn't seem entirely appropriate, but OTOH if these are RADIUS entities able to communicate SAML 2.0 messages, I don't know that it isn't appropriate either.

It doesn't matter that much in practice here because the purpose of the attribute is to distinguish a particular role type across multiple use cases (e.g. IDPSSODescriptor that might be SAML 2.0, SAML 1.1, WS-Federation, OpenID Connect, or all four).

If these roles are more or less singular in nature, then the value is probably academic, and leaving it defaulting to "urn:oasis:names:tc:SAML:2.0:protocol" is likely fine, but I'm just noting that that is in fact what would have to appear. If that doesn't seem good, something else would need to be defined.

>introductory text for each role? Why other subtypes of RoleDescriptor do 

The default value is defined in the RoleDescriptor definition. If one was to specify a different default for a role type, it would make sense to define it within that role type's definition.

>value of the element. What do you suggest?:

The simplest fix is just to change the examples.

>b) using another type that has implicit trimming capabilities (if such 

No such thing exists, so it's a rathole to try and address it.

>but it seems to have no problems with trimming.

Everything based on string ends up with trimming issues sooner or later. Nothing has ever been done to address it.

>Does this subtype define anything special that implies trimming?

No. That approach to the examples is what I'm suggesting you avoid.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Mon, 10 Aug 2015 10:38:02 -0400

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

    Cantor,> It may be that the right value here is just
    Cantor,> "urn:oasis:names:tc:SAML:2.0:protocol", which is the one
    Cantor,> that's called out by default in the metadata spec for SAML
    Cantor,> 2.0 entities.

    Cantor,> Since these roles were, I thought, more intended to
    Cantor,> describe RADIUS entities, that didn't seem entirely
    Cantor,> appropriate, but OTOH if these are RADIUS entities able to
    Cantor,> communicate SAML 2.0 messages, I don't know that it isn't
    Cantor,> appropriate either.

These are in fact RADIUS entities that can communicate using SAML 2.0
using the binding defined in this document.
Currently, that is the only use for these roles.

--Sam

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 10 Aug 2015 15:31:08 +0000

>Currently, that is the only use for these roles.

Ok. Then I would say staying silent on it is fine after all.

-- Scott