> -----Original Message-----
> From: Sam Hartman [mailto:[email protected]]
> Sent: Wednesday, August 15, 2012 1:17 AM
> To: Jim Schaad
> Cc: [email protected]
> Subject: Re: [abfab] draft-ietf-abfab-gss-eap-naming believed ready for
last
> call
>
> >>>>> "Jim" == Jim Schaad <[email protected]> writes:
>
> Jim> 1. Just because I keep having to go and read the SAML document
> Jim> every time, it might be useful to provide an example in
> Jim> paragraph 1 of section 3 about what makes a first part and a
> Jim> second part. I would pass the document without this, it is
> Jim> just a suggestion.
>
> I'd love to include an example here.
> I'll try to update code prior to IETF LC ending.
Hope to see it.
>
>
> Jim> 3. In section 5, I thought we had agreed that there should be
> Jim> a statement that "The values, prior to receiving the
> Jim> access-accept message, are undefined."
>
> I thought the first paragraph was adequate, but expanded it somewhat.
> Let me know how we're doing now.
Yes this looks better.
>
> Jim> 4. Section 6.1 - I think this is correct. s/is always
> Jim> authentic when present/is always authenticated when present/ If
> Jim> I am wrong (which is possible) then I am not sure what the word
> Jim> authentic is supposed to be. I don't think it currently makes
> Jim> sense. The argument against the above is the following on
> Jim> sentence which states that a new GSS-API mechanism may allow it
> Jim> to be unauthenticated.
>
> Added hopeful clarity to this paragraph.
Better
>
> Jim> 5. Section 6.1 - unclear if this is useful information or not.
> Jim> Might want to say that for GSS-API-EAP, it is the same as
> Jim> "urn:ietf:gss:radius-attribute TBD".
>
> I don't want to trod on draft-ietf-abfab-aaa-saml's toes.
I understand that you don't want to trod on the SAML document. I might
suggest that the following text be added instead.
For the GSS-API mechanism this attribute is an alias for a RADIUS attribute,
however it is recommended that this attribute name be used as other
mechanism could transport the SAML statement by a different method that
RADIUS.
>
> Jim> 6. Section 5 - the above note just nudged a new one. Does
> Jim> there need to be a DIME attribute as the number space can be
> Jim> larger. Perhaps just a comment to the effect that some DIME
> Jim> space may not be reachable?
>
> If we want diameter support there does need to be an attribute.
> We can define that in the diameter document if that ever happens.
Sounds fine
>
>
> Jim> 7. Section 6.2 -- Possible comment to be added. "If the
> Jim> implementation does discard it, then processing the entire SAML
> Jim> statement will result in a different answer than processing the
> Jim> individual attributes." This might just be a security
> Jim> considerations comment.
>
> OK.
Nits:
Abstract
s\Authentication/Authorization/Accounting\Authentication/Authorization/Accou
nting (AAA)\
s/Generic Security Services Application Programming interface/Generic
Security Services Application Programming interface (GSS-API)/
Section 1.
s\Authentication/Authorization/Accounting\Authentication/Authorization/Accou
nting (AAA)\
Expand the EC in SAML EC
Section 3.
s/Attributes using the federated context/Attributes access by the federated
context/
s/based on who is the subject of the name/based on authenticator part/
I this that it is backwards - you need to know who the authenticator
is in order to know the semantics of the subject is.
Section 5
s/specifations/specifications/
Section 6.1
s/some other mechanisms/other mechanism/ or /some other mechanism/
Section 7
s/mechanisms are/Mechanisms are/
Section 9
s/Sam hartman's/Sam Hartman's/
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
