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

[Alejandro Pérez Méndez <[e-mail]>]

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, [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/kitten