Hi Sam, thanks for the review. See my comments below.
El 17/02/15 a las 23:49, Sam Hartman escribió:
Section 4: I thought we were going to make RADIUS over TLS a MUST not a SHOULD. Current text says recommended.
Whereas version -09 stated once (in section 5.2) that the use of TLS was REQUIRED, along the rest of text it indicated several times this support as RECOMMENDED (sections 7.4.5, 8.3.2, and 10). I just homogenized them to the prevailing one.
Nevertheless, I think that making TLS a MUST might be limiting. There might be some use case scenarios for this profile where using TLS is not actually required (e.g. other security mechanisms apply). I would see that kind of requirement more for the ABFAB architecture level than for this I-D level. Moreover, in the saml-profiles-2.0-os document, the use of TLS is indicated as RECOMMENDED.
Section 6.3.3: I would like to state for the record that I believe interlinking the SAML and EAP authentications to permit the SAML request to affect things like TLS resumption and authentication freshness is problematic and will lead to implementation failures (or simply be ignored). I would prefer we not take that approach. However the sense of the room was against me when this was last discussed. I do think an explicit consensus call by chairs if we have not already made such a call would be valuable. I expect that it's likely I'm in the rough.
I'm ok with such a call, but I'd like to know more about the problems you would expect. As I see it, if the IdP cannot/won't address the constraints called in the AuthnRequest message, it MUST (SHOULD perhaps?) generate an authentication error.
Section 6.4.3: o Assume that the Client's identifier implied by a SAML <Subject> element, if present, takes precedence over an identifier implied by the RADIUS User-Name attribute.*what*?! This flies in the face of 4.3.1.
This section is dealing with the Client's identifier (Subject), whereas 4.3.1 deals with names of the AAA entities (i.e. RP and IdP, related with Issuer and Recipient at the SAML level). Hence, I don't think section 6.4.3 has a direct impact on what 4.3.1 says.
This draft still does not provide a mechanism to meet the conditions specified in section 4.3.2. In particular, we don't describe how to embed AAA names in requests, responses or metadata.
You're right. I think we should focus on representing this information in the metadata, which is controlled by the recipient, rather than on the information on the wire, which might have been forged by the sender.
Regards, Alejandro
--Sam _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
_______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
