>>>>> "Jim" == Jim Schaad <[email protected]> writes:
Jim> Some comments inline
>> -----Original Message----- From: [email protected]
>> - Examples are very very badly needed. Maybe some GSS calls and
>> showing the values that'll be produced.
>>
I've tried to add some.
>> >> - 6.2, can't there be more spaces after the first two in this
>> case?
Jim> Calling that
>> out would seem better.
Jim> I am not sure what you mean here. It seems to me that we have
Jim> <string> <space> <string> <space> <string>
Jim> Where are you planning to put the additional spaces? After the
Jim> last string? It might be interesting to say if you could put
Jim> multiple space characters in the location where the <space> is,
Jim> but that is not something that I would necessarily expect.
I agree with Stephen that the last string can for some name formats
contain spaces.
Text clarified.
Tried to clarify this too.
>>
>> General, comment-like:
>>
>> - As presented, this looks very complex. I think the presentation
>> could do with work to make this an easier read.
Jim> In order to access this, I would need to know where you felt it
Jim> was complex. At this point it is, for better or worse, rather
Jim> easy to read.
>>
>> - Ought this be made specific to the currently known GSS
>> mechtypes that
Jim> use
>> RADIUS or SAML? I mean for example a statment like "This
>> specification
Jim> only
>> applies for GSS-EAP or SAML-EC." That might well simplify a lot
>> of things
Jim> since
>> I reckon some of the complexity mentioned above comes from what
>> might be premature generalisation.
I think there's a huge cost for future applications if we do that and
come up with related SAML mechanisms or stack these SAML mechanisms in
for example a GSS mechanism providing data compression or the like.
Also, consider the interaction with NegoEx or SPNEGO.
Applications can and will find these attributes with mechanism names
with a much broader set of underlying mechanism.
>>
>> questions:
>>
I've added text that hopefully clarifies.
>>
>> - How do I implement the "MUST NOT" in the last para of section
>> 4? I'm
Jim> told
>> that's meant for mechanism spec. writers so making that clear
>> would be good. "Closely associated" seems too vague. "Can assume"
>> in the example also seems pretty vague.
Jim> I don't have good text here at this point.
I've proposed something in the soon-to-be-uploaded 05.
>>
>> - Section 5, 1st para: what does "undefined" mean? If I call the
>> relevant
Jim> GSS
>> function too early (before access-accept) what do I get? Maybe
>> say here which GSS calls are meant?
Jim> If you make the call too early, you might get an answer that
Jim> would change after the access-accept message. You might get an
Jim> error. We are not saying what the correct behavior is. While
Jim> the current deployments are setup to just get information back,
Jim> for Plasma we are looking at situations where we are going to
Jim> want to ask more questions and the way to do this is not
Jim> currently defined.
I've tried to clarify that we're specifying behavior for what happens if
you look for these attributes on the src_name returned from
GSS_Accept_Sec_context after GSS_S_COMPLETE.
>>
>> - 6.1, How can a GSS API extension spec assert that
>> authentication only succeeds if the SAML or AAA exchange is
>> successfully authenticated? Sam suggested: "This attribute MUST
>> always be authenticated when present in mechanism names complying
>> with this specification." which I think would be better.
>>
Jim>
Jim>I had asked a similar question in the past, and I think that Sam's response
Jim> is incorrect in that it does not match with what he told me in
Jim> the past. There is a possibility that some mechanism will have
Jim> a SAML statement it receives that it cannot authenticate either
Jim> via the AAA exchange or by validating the signature on the SAML
Jim> statement. In this case the attribute would not be returned as
Jim> authenticated. However I would be willing for this behavior to
Jim> be dropped. But given that we are talking about how to query
Jim> for the attribute, I don't think that the suggested sentence
Jim> from Sam would be correct.
Hmm.
I thought what I said in the past is that the SAML assertion attribute
would be dropped if the mechanism didn't like the assertion, but that
you'd typically expect the RADIUS attribute carrying the assertion to
remain at least for GSS-EAP.
Although I guess that was more about local policy checks than validation
faliures.
Jim> Perhaps 1. Make this a new paragraph 2. Updated text
Jim> This attribute is authenticated only when the mechanism can
Jim> successfully authenticated the SAML statement. For the GSS-EAP
Jim> mechanism this is true if the AAA exchange has successfully
Jim> authenticated. However, uses of the GSS-API MUST confirm that
Jim> the attribute is marked authenticated as other mechanisms MAY
Jim> permit an initiator to provide an unauthenticated SAML
Jim> statement.
>> - 6.2: Maybe I need to check SAML again, but the
>> "<saml:Attribute> element's Name XML attribute" is used at the
>> end of para 1, but later
Jim> paras
>> talks about the <saml:AttributeValue> - are they the same or not?
Jim> They are not the same.
>>
>> - 6.2: What does "sufficiently validated" mean? Adding more
>> clarity here would be good. Sam suggested: "what we're saying or
>> trying to say here is that a mechanism of GSS-EAP should mark
>> attributes carried according to draft-ietf-abfab-aaa-saml as
>> authenticated in the return from GSS_Get_Name_attribute without
>> needing to do normal SAML validation."
>>
That probably is what Sam said, not what he suggested as text.
Jim> Text: In the GSS-EAP mechanism, a SAML assert carried in an
Jim> integrity-protected and authenticated AAA protocol SHALL be
Jim> considered successfully validated.
>> - 6.2: last sentence talks about "this assertion" buts its not
>> clear to me
Jim> if you
>> mean the entire assertion or just the attribute?
Jim> I think that when Sam wrote the text he was thinking of the
Jim> SAML assertion. I think however it would be more correct in
Jim> the current content to substitute attribute for assertion as it
Jim> needs to be clear than local policy may kill an attribute. I
Jim> would suggest the following changes:
Jim> 1. Add the following to the end of section 6.1 "An
Jim> implementation MAY apply local policy checks to a SAML
Jim> assertion and discard it if it fails the local policy checks."
Jim> 2. Change the text at the end of section 6.2 to "An
Jim> implementation MAY apply local policy checks to each attribute
Jim> contained in a SAML assertion and discard the attribute if it
Jim> fails the local policy checks.
>>
>> - 6.3: Why the SHOULD in the first para?
Jim> A mechanism can choose not to expose some name forms to the
Jim> acceptor. In this case the GSS name attribute would not be
Jim> present.
>>
>> - section 8, what is "paramname"?
Jim> If a parameter "paramname" is registered in this registry then
Jim> its URN will be "urn:ietf:gss:paramname".
>>
>> nits and whinges:
>> - section 8, all but 1st sentence of 1st para should go
>>
Will do, but Stephen is taking full responsibility for resolving any
confusion by people trying to put it somewhere else.:-)
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
