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.

>
> 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
> abfab@ietf.org
> https://www.ietf.org/mailman/listinfo/abfab