Ben Campbell <ben@xxxxxxxxxxx> writes:
> -- section 4, 3rd and 4th paragraph (paragraph a and b)
>
> These seem like protocol affecting differences. If so, they need
> elaboration, such as normative statements and formal definitions, or
> references to such.
>
> -- section 5, general:
>
> The section seems to need further elaboration or references
Hello Ben. Thank you for your review. Klaas pointed me at this part
and I will try to work this out with you.
Re section 4 I believe your comment is based on a misunderstanding. Let
me try to explain what the intention is, and we can work out how to fix
the text if needed. What is described in paragraph a) and b) are the
protocol requirements that (implicitely) follow from GS2. There is
nothing particular to this protocol in there. Let's take a step back:
The purpose of GS2 is to map any GSS-API mechanism into a SASL
mechanism. However, SASL-SAML is defined as a SASL mechanism (because
SASL implementers wants it that way). The point of section 4 is to turn
this SASL mechanism into a GSS-API mechanism that, after the SAML
GSS-API mechanism is used via GS2, becomes identical to the SAML
mechanism defined in the rest of the SASL-SAML document. This is a bit
convuleted to describe, but this is the gist of it.
(It would have been simpler to specify a SAML GSS-API mechanism and then
let GS2 convert it to SASL automatically, but some SASL people doesn't
want anything to do with GSS-API so this is a compromise to allow them
to implement SAML-SASL without touching GSS-API.)
I'm thinking that perhaps the above explanation would be useful to have
in the document, to give some background. If you agree, I propose to
resolve your section 4 comment by making this change:
OLD:
The SAML SASL mechanism is actually also a GSS-API mechanism. The
SAML user takes the role of the GSS-API Initiator and the SAML
NEW:
This section specify a GSS-API mechanism that when used via the GS2
bridge to SASL behave like the SASL mechanism defined in this
document. Thus, it can loosely be said that the SAML SASL mechanism
is also a GSS-API mechanism.
The SAML user takes the role of the GSS-API Initiator and the SAML
Does this resolve your concern re section 4?
Re your section 5 comment, I tend to agree. The section is quite brief
because it was ripped out of section 3.1. I propose that we simply
collapse this section back into 3.1 where it makes more sense. Thus:
OLD:
- See Section 5 for the channel binding "gs2-cb-flag" field.
NEW:
- The "gs2-cb-flag" MUST be set to "n" because channel binding
data cannot be integrity protected by the SAML negotiation.
(Note: In theory channel binding data could be inserted in the
SAML flow by the client and verified by the server, but that is
currently not supported in SAML.)
And then remove section 5 completely. Section 3 and in particular
section 3.1 already contains the relevant references and provides the
context where the statements make sense.
What do you think?
Thanks,
/Simon
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf