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

[Alejandro Perez Mendez <[e-mail]>]

El 19/02/15 a las 20:12, Jim Schaad escribió:
>
>> -----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.

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