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

From: Sam Hartman <[email-masked]>
Date: Tue, 17 Feb 2015 17:49:52 -0500

Section 4:

I thought we were going to make RADIUS over TLS a MUST not a SHOULD.
Current text says 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.

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 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.

--Sam

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 19 Feb 2015 09:00:49 +0100

Hi Sam,

thanks for the review. See my comments below.

> 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.

> made such a call would be valuable.  I expect that it's likely I'm in

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.

> *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.

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

---

From: Leif Johansson <[email-masked]>
Date: Thu, 19 Feb 2015 09:56:55 +0100

> of TLS is indicated as RECOMMENDED.

Speaking as an individual I don't think there are any sane reasons not
to use TLS if you relax the requirements on credentials administration
(eg run oportunistic TLS). Having said that I think probably RECOMMENDED
is strong enough anyway.

> the AuthnRequest message, it MUST (SHOULD perhaps?) generate an

I can make such a call if we have a clear enough statement to call
consensus on.

	MVH leifj

---

From: "Klaas Wierenga (kwiereng)" <[email-masked]>
Date: Thu, 19 Feb 2015 09:16:57 +0000

> On 19 Feb 2015, at 09:56, Leif Johansson <[email-masked]> wrote:
> 

speaking as another individual, you could go the route that other drafts have taken and say something like:

TLS is REQUIRED unless alternative methods are used to ensure confidentiality like IPSEC tunnels or a sufficiently secure internal network.

Klaas

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 19 Feb 2015 15:16:24 +0100

> TLS is REQUIRED unless alternative methods are used to ensure confidentiality like IPSEC tunnels or a sufficiently secure internal network.

That text sounds quite reasonable to me. I was also thinking in 
including DTLS as an alternative.

Regards,
Alejandro

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 19 Feb 2015 11:12:09 -0800

> -----Original Message-----
> From: abfab [mailto:[email-masked]] On Behalf Of Alejandro Perez
> Mendez
> Sent: Thursday, February 19, 2015 12:01 AM
> To: [email-masked]
> Subject: Re: [abfab] Review of draft-ietf-abfab-aaa-saml-10
> 
> Hi Sam,
> 
as
> RECOMMENDED (sections 7.4.5, 8.3.2, and 10). I just homogenized them to
> the prevailing one.
> 
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.
> > 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'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.

> 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.
> 
> >
> >
> 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?

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 19 Feb 2015 11:15:44 -0800

> Sent: Thursday, February 19, 2015 6:16 AM
> To: [email-masked]
> >>> 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.
> >> Speaking as an individual I don't think there are any sane reasons
> >> not to use TLS if you relax the requirements on credentials
> >> administration (eg run oportunistic TLS). Having said that I think
> >> probably RECOMMENDED is strong enough anyway.
> > TLS is REQUIRED unless alternative methods are used to ensure
> confidentiality like IPSEC tunnels or a sufficiently secure internal
network.
> 
> That text sounds quite reasonable to me. I was also thinking in including
DTLS
> as an alternative.

In my mind DTLS would be acceptable if one says TLS is required.  They are
the same basic mechanism in my mind.  However the use of DTLS in this
scenario is going to be somewhat problematic as it would lead to even more
fragmenting.  The big reason for using TLS/IP rather than DTLS is the
upcoming support for large packets.  

Not clear that the large packet draft is written to allow it to be used in a
non-TLS situation.  Probably need to verify that it is if we want to include
things like IPsec as options

Jim

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 26 Feb 2015 12:03:50 +0100

> This probably also needs to be stressed.

Right. I will add that to the considerations.

Regards,
Alejandro

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 26 Feb 2015 12:05:02 +0100

> things like IPsec as options

We have our fragmentation draft for UDP, so that should not be a problem.

Regards,
Alejandro