Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-13.txt

From: Alejandro Pérez Méndez <[email-masked]>
Date: Tue, 6 Oct 2015 14:47:07 +0200

Dear Scott and Simon,

I have reviewed the latest version of the draft-ietf-kitten-sasl-saml-ec 
(v13). In my opinion, the document is well written and very clear, and 
it is relatively easy to follow if you are somewhat familiar with SAML, 
SASL and GSS-API. The outline of the SAML ECP profile given in section 3 
is really helpful to avoid sending the reader to check the [SAMLECP20] 
document right-away , and the example given in section 6 is clarifying 
and helps to understand how the proposal works.

There are however a few minor points that are not clear to me, so I'd 
appreciate if you could clarify them:

#1 In the document, the difference between SAML20EC and SAML20EC-PLUS is 
not clearly described. There is only a brief mention in section 4 
indicating that the latter one means that ChannelBindings are supported, 
but there are not further explanation nor mention. If you are not 
familiar with RFC5801 (I wasn't), you need to figure out that the -PLUS 
suffix comes from that document. I think adding a reference to 5801 at 
this point would be useful.

#2 Section 4 is titled "SAML SASL Mechanism Specification", when I think 
it would be more correct titling it as "SAML Enhanced Client SASL 
Mechanism Specification" (as in the document title).

#3 Should

    "If the client is unable to obtain a response from the IdP, or must
    otherwise signal, failure, it responds to the SASL server with a
    SOAP envelope containing a SOAP fault."

actually be

    "If the client is unable to obtain a response from the IdP, or must
    otherwise signal a failure, it responds to the SASL server with a
    SOAP envelope containing a SOAP fault."

?

#4 Section 4.7. A reference to section 5.6.2 might be useful here to 
figure out what a "service name" looks like.

#5 Section 4.7. Does the URI format allow using "service@host" as a 
value? (just asking)

#6 Section 4.7. I found problems parsing the following sentence (I'm not 
a native speaker, so please ignore my comment if the sentence is correct)

"The value MUST be securely associated with the SAML entityID claimed
    by the SASL server by the identity provider, such as ..."

To be more specific, two "by" too close in the same sentence made me 
confused about who was making the association.

#7 Section 5, paragraph 2. I think referring to RFC 5801 would provide 
further explanation on why this is done in this way.

#8 Section 5, paragraph 4. Should "mutual-auth" be "mut" instead?

#9 Section 5.6.2. There is a repetition of great part of the text about 
the responseConsumerURL and AssertionConsumerServiceURL from section 4.7.

Best regards,
Alejandro

El 25/09/15 a las 20:07, [email-masked] escribió:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF.
>
>          Title           : SAML Enhanced Client SASL and GSS-API Mechanisms
>          Authors         : Scott Cantor
>                            Simon Josefsson
> 	Filename        : draft-ietf-kitten-sasl-saml-ec-13.txt
> 	Pages           : 39
> 	Date            : 2015-09-25
>
> Abstract:
>     Security Assertion Markup Language (SAML) 2.0 is a generalized
>     framework for the exchange of security-related information between
>     asserting and relying parties.  Simple Authentication and Security
>     Layer (SASL) and the Generic Security Service Application Program
>     Interface (GSS-API) are application frameworks to facilitate an
>     extensible authentication model.  This document specifies a SASL and
>     GSS-API mechanism for SAML 2.0 that leverages the capabilities of a
>     SAML-aware "enhanced client" to address significant barriers to
>     federated authentication in a manner that encourages reuse of
>     existing SAML bindings and profiles designed for non-browser
>     scenarios.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml-ec/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-kitten-sasl-saml-ec-13
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-sasl-saml-ec-13
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 9 Oct 2015 02:20:46 +0000

Thank you for the detailed review. Responses inline...

On 10/6/15, 8:47 AM, "Kitten on behalf of Alejandro Pérez Méndez" <[email-masked] on behalf of [email-masked]> wrote:

>
>#1 In the document, the difference between SAML20EC and SAML20EC-PLUS is not clearly described. There is only a brief mention in section 4 indicating that the latter one means that ChannelBindings are supported, but there are not further explanation nor mention.
> If you are not familiar with RFC5801 (I wasn't), you need to figure out that the -PLUS suffix comes from that document. I think adding a reference to 5801 at this point would be useful.

Will do.

>#2 Section 4 is titled "SAML SASL Mechanism Specification", when I think it would be more correct titling it as "SAML Enhanced Client SASL Mechanism Specification" (as in the document title).

+1

>#3 Should 
>
>"If the client is unable to obtain a response from the IdP, or must otherwise signal, failure, it responds to the SASL server with a SOAP envelope containing a SOAP fault."
>actually be
>"If the client is unable to obtain a response from the IdP, or must otherwise signal a failure, it responds to the SASL server with a SOAP envelope containing a SOAP fault."
>?

Yes, stray comma.

>#4 Section 4.7. A reference to section 5.6.2 might be useful here to figure out what a "service name" looks like.

Will take a look.

>#5 Section 4.7. Does the URI format allow using "service@host" as a value? (just asking)

There's been discussion on this internally by InCommon. In SAML terms, the use of anyURI in the schema implies an absolute URL unless something overrides that assumption. Syntactically, service@host is just a relative URI.

In metadata, the format of the Location attribute in an EndpointType is dependent on the Binding value. In this case, the original draft reused the PAOS Binding URI in order to remain 100% compatible with an unmodified IdP supporting the standard ECP profile.

Strictly speaking, PAOS isn't really HTTP specific, but also doesn't say anything that would override the assumption that the locations have to be absolute URIs. It also doesn't really break anything, because software doesn't generally care, and there are no overlaps between a GSS service name and an HTTP endpoint that would be used with PAOS otherwise.

However, to avoid arguments about it, draft-13 added a new Binding value to use for this mechanism that is preferred over the use of the PAOS Binding value, to explicitly work around the issue, and I added support for it to the upcoming Shibboleth release.

InCommon already published a PAOS endpoint with this syntax because there are already some deployments of the older drafts, and will eventually I imagine support the new Binding. I would expect any wider use to standardize on the new value.

All in all, I'd rather fight over the metadata issue than deal with canonicalizing GSS names into URIs at this point.

>#6 Section 4.7. I found problems parsing the following sentence (I'm not a native speaker, so please ignore my comment if the sentence is correct)
>
>To be more specific, two "by" too close in the same sentence made me confused about who was making the association.

Will reword.

>#7 Section 5, paragraph 2. I think referring to RFC 5801 would provide further explanation on why this is done in this way.

Ok.

>#8 Section 5, paragraph 4. Should "mutual-auth" be "mut" instead?

Yes, I believe so.

>#9 Section 5.6.2. There is a repetition of great part of the text about the responseConsumerURL and AssertionConsumerServiceURL from section 4.7.

That evolved out of the mess with the Binding that you identified, but I'll take another look and maybe trim one of them.

I'll produce a "final" draft that should hopefully be suitable for WGLC, probably tomorrow.

Thanks again for the close read,
-- Scott

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 09 Oct 2015 12:36:45 +0200

> Thank you for the detailed review. Responses inline...

Again, thank you Alejandro!  Looking at your questions and Scott's
responses, I agree with everything that I have an opinion about.

/Simon