El 19/02/15 a las 20:12, Jim Schaad escribió:
-----Original Message-----
From: abfab [mailto:[email protected]] On Behalf Of Alejandro Perez
Mendez
Sent: Thursday, February 19, 2015 12:01 AM
To: [email protected]
Subject: Re: [abfab] Review of draft-ietf-abfab-aaa-saml-10
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.
If we don't make TLS a MUST, then we probably need to strengthen the privacy
considerations to talk about the fact that eavesdroppers on the wire will be
able to get to the contents of the SAML statements being made. It is not
just an issue of RADIUS Proxies. In any event I don't know how this can be
enforced for anything but the first and last steps in a multi-proxy world.
This probably also needs to be stressed.
Right. I will add that to the considerations.
Regards,
Alejandro
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.
Why do you not think that the NAI name form is sufficient for this purpose?
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
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
