Re: [abfab] Review of draft-ietf-abfab-aaa-saml-10

["Jim Schaad" <[e-mail]>]

> -----Original Message-----
> From: abfab [mailto:[e-mail]] On Behalf Of Alejandro Perez
> Mendez
> Sent: Thursday, February 19, 2015 12:01 AM
> To: [e-mail]
> 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.

> 
> 
> >
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/abfab
> 
> _______________________________________________
> abfab mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/abfab