Subject: [abfab] Proposal: mandatory radsec for draft-ietf-abfab-aaa-saml

From: Sam Hartman <[email-masked]>
Date: Thu, 08 Nov 2012 14:42:19 -0500

Folks, I've been thinking about the mandatory to implement signature
validation issue.  The more I think about it, the more I agree with
stephen and Scott that end-to-end security is important for ABFAB.  It
won't always be used; just as with other technologies, people will
sometimes want to introduce middleboxes.  However it's important to have
a way of talking to the ends.

However,  I think SAML signatures are the wrong level to accomplish
thit.
The issue is that there's a lot of important stuff in ABFAB that comes
in AAA not SAML.
All the concerns about SAML can apply to the AAA elements.

I was asking myself why Moonshot doesn't worry about this.
Then I realized that we do.
we're going out of our way to set up end-to-end RADSEC.
We get protection of the SAML, but we also get protection of the  AAA
attributes.

RADSEC can be used in a hop-by-hop manner.  However, RADSEC is specified
with a lot of thought towards enabling end-to-end uses.  Multiple
technologies, including the dynamic SRV-based mechanism and Moonshot's
trust router are evolving to make end-to-end RADSEC easier to deploy.

So, I think that RADSEC is a better MTI security technology for  ABFAB
than signature validation.
I'd prefer to make RADSEC a MUST and SAML signature validation a SHOULD.

I've run this by Alan, Josh, Scott and Jim.  They seemed to like the
idea, so I'm presenting it here.

Note that there is a process issue with RADSEC; it's not
standards-track.  Let's assume for the moment that I can come up with a
solution to that (I believe I have two avenues to approach)
do we believe that if we can make it work that would be the right
technical approach?

--Sam

---

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 08 Nov 2012 19:55:39 +0000

Hi,

I could simple say the usual "+1", but given my chatty personality, let
me say I fully support the idea of E2E RADSEC.

On 8 Nov 2012, at 14:42 , Sam Hartman wrote:

> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Leif Johansson <[email-masked]>
Date: Thu, 08 Nov 2012 21:23:56 +0100

> do we believe that if we can make it work that would be the right

Speaking as an individual I'll note that currently RADSEC depends
on some form of public key management that is at least nominally
no better or worse than the key management you'd need to do this
using SAML.

            Cheers Leif

---

From: "Klaas Wierenga (kwiereng)" <[email-masked]>
Date: Thu, 8 Nov 2012 20:35:27 +0000

> no better or worse than the key management you'd need to do this

Also speaking as an individual. I do support the idea of using RadSec. However, I think that one reason why one would be willing to support SAML sigs is the simple fact that they exist today and presumably organizations might be willing to continu to use their existing practice for end to end protection. I realize that in some scenarios it will be impossible for the RP to verify the signature, but I'd say that in the majority of cases this is not more of a problem than it would be in RadSec (barring trust router implementations).

Klaas

---

From: Sam Hartman <[email-masked]>
Date: Thu, 08 Nov 2012 15:39:14 -0500

>>>>> "Klaas" == Klaas Wierenga (kwiereng) <[email-masked]> writes:

    Klaas> Also speaking as an individual. I do support the idea of
    Klaas> using RadSec. However, I think that one reason why one would
    Klaas> be willing to support SAML sigs is the simple fact that they
    Klaas> exist today and presumably organizations might be willing to
    Klaas> continu to use their existing practice for end to end
    Klaas> protection. I realize that in some scenarios it will be
    Klaas> impossible for the RP to verify the signature, but I'd say
    Klaas> that in the majority of cases this is not more of a problem
    Klaas> than it would be in RadSec (barring trust router
    Klaas> implementations).

Sure, and for that reason, I think SAML sig validation implementation
should be a SHOULD.  But I think for an MTI mechansim we should pick
something that actually protects the whole exchange.

---

From: Leif Johansson <[email-masked]>
Date: Thu, 08 Nov 2012 21:39:27 +0100

> Also speaking as an individual. I do support the idea of using RadSec. However, I think that one reason why one would be willing to support SAML sigs is the simple fact that they exist today and pr…
Right (still with chair-hat off) deployability is another issue,
although we shouldn't limit
abfab to those that run "traditional" identity federations today, no
matter how many
there are of those.

        Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Thu, 08 Nov 2012 21:45:03 +0100

> something that actually protects the whole exchange.
Still with no hat on whatsoever...

You seem to be assuming a situation where attributes are sometimes
sent as AAA-attributes and sometimes as SAML-attributes.

I think what we're seeing is a negative consequence of that design-
choice in that it is now impossible to use existing deployments of SAML-
trust infrastructure to protect all forms of attribute exchange.

Please correct me if I got any of that wrong.

            Cheers Leif

---

From: Sam Hartman <[email-masked]>
Date: Thu, 08 Nov 2012 15:49:06 -0500

>>>>> "Leif" == Leif Johansson <[email-masked]> writes:

    >> 
    >> Sure, and for that reason, I think SAML sig validation
    >> implementation should be a SHOULD.  But I think for an MTI
    >> mechansim we should pick something that actually protects the
    >> whole exchange.
    Leif> Still with no hat on whatsoever...

    Leif> You seem to be assuming a situation where attributes are
    Leif> sometimes sent as AAA-attributes and sometimes as
    Leif> SAML-attributes.

no, I'm assuming that deployments have the flexibility as to whether to
use AAA attributes or SAML attributes.
Some of the use cases I'm looking at involve no SAML at all; some
involve using SAML for everything.

Having multiple ways to convey attributes was a fairly explicit decision
here. It's true that it means attribute-container-specific security
mechanisms lose value.

---

From: Leif Johansson <[email-masked]>
Date: Thu, 08 Nov 2012 21:52:00 +0100

> here. It's true that it means attribute-container-specific security
OK, then we're on the same page. Thx.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 9 Nov 2012 13:51:37 +0100

Hi Sam, all:

I was wondering what would happen if a current deployment is not using radsec. Is it not too much restrictive to set MUST for radsec?. (In fact, as you mention, it is an experimental RFC)

I would say that if Radsec is available MUST be used and SAML signature MAY be used. But if Radsec is not deployed SAML signature MUST be used.

Or in general if end-to-end security is deployed SAML signature is not required.

Best regards.

P.D: Perhaps, this is what you are trying to say and I misunderstood your statement.

> do we believe that if we can make it work that would be the right

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Alan DeKok <[email-masked]>
Date: Fri, 09 Nov 2012 07:55:34 -0500

> I was wondering what would happen if a current deployment is not using radsec. Is it not too much restrictive to set MUST for radsec?. (In fact, as you mention, it is an experimental RFC)

  My $0.02 is that most RADIUS deployments should be moving to RadSec,
or RADIUS over DTLS.  The security of the RADIUS protocol requires it.

  If a new implementation understands SAML, it can do RadSec, too.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 09 Nov 2012 10:23:55 -0500

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan> Rafa Marin Lopez wrote:
    >> I was wondering what would happen if a current deployment is not
    >> using radsec. Is it not too much restrictive to set MUST for
    >> radsec?. (In fact, as you mention, it is an experimental RFC)

    Alan>   My $0.02 is that most RADIUS deployments should be moving to
    Alan> RadSec, or RADIUS over DTLS.  The security of the RADIUS
    Alan> protocol requires it.

The Moonshot implementation of ABFAB has always supported RADSEC.

I know that the UM team had an early deployment of AABFAB; I don't know
if that supported RADSEC or not.

---

From: Gabriel Lopez <[email-masked]>
Date: Mon, 12 Nov 2012 17:04:17 +0100

> if that supported RADSEC or not.
Actually not, it runs over Radius. Although it is just a matter of
implementation.

regards, Gabi.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 12 Nov 2012 14:32:51 -0500

>>>>> "Gabriel" == Gabriel Lopez <[email-masked]> writes:

    Alan> Rafa Marin Lopez wrote:
    >> >> I was wondering what would happen if a current deployment is
    >> not >> using radsec. Is it not too much restrictive to set MUST
    >> for >> radsec?. (In fact, as you mention, it is an experimental
    >> RFC)
    >> 
    >> I know that the UM team had an early deployment of AABFAB; I
    >> don't know if that supported RADSEC or not.
    Gabriel> Actually not, it runs over Radius. Although it is just a
    Gabriel> matter of implementation.

OK, so you would not be concerned about a radsec requirement on behalf
of the MU implementation?

---

From: Gabriel Lopez <[email-masked]>
Date: Tue, 13 Nov 2012 15:16:03 +0100

On 12/11/12 20:32, Sam Hartman wrote:
> >> >> I know that the UM team had an early deployment of AABFAB; I >>
> don't know if that supported RADSEC or not. Gabriel> Actually not, it
> runs over Radius. Although it is just a Gabriel> matter of
> implementation. OK, so you would not be concerned about a radsec
> requirement on behalf of the MU implementation? 

The original UM implementation of GSS-EAP is deprecated, we are
currently working with the GSS-EAP moonshot implementation.

My concern is about to define RadSec mandatory for those institutions
willing to deploy abfab.
Let's suppose eduroam, institution A is requesting authentication to
institution B, where A is abfab-aware, and B is a tipical eduroam
member. Let's suppose:

a) Authorization (SAML) is not required --> A and B are able to
authenticate the user directly, without any modification in B side.
End-to-end authentication is not possible

b) Authorization (SAML) is required and B is running a SAML-idP (i.e.
Shibboleth) --> minimum modification at B side (radius server requesting
SAML attributes to idP). End-to-end authentication is possible by means
of SAML signature.

c) Authorization (SAML) is required and B is not SAML-aware --> B has to
deploy current abfab solution. Easy to deploy. End-to-end authentication
is possible by means of SAML signature.
   
        Why does abfab have to force institution B to deploy RadSec too?.

As sent before, we strongly agree to make use of radsec, when possible.
In any case, if WG members agree on that maybe I am
missing/misunderstanding something

regards, Gabi.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 13 Nov 2012 09:20:09 -0500

>>>>> "Gabriel" == Gabriel Lopez <[email-masked]> writes:

    Gabriel> My concern is about to define RadSec mandatory for those
    Gabriel> institutions willing to deploy abfab.  Let's suppose
    Gabriel> eduroam, institution A is requesting authentication to
    Gabriel> institution B, where A is abfab-aware, and B is a tipical
    Gabriel> eduroam member. Let's suppose:

Ah!  The IETF rarely if ever specifies what security technology you must
use or deploy and I'm not proposing doing that in this case.  I'm
proposing that implementations of draft-ietf-abfab-aaa-saml--that is
software implementing that spec--MUST be capable of using RADSEC.
Whether you turn on RADSEC is up to whomever deploys the code.

I absolutely agree with you that requiring people to use RADSEC in all
ABFAB deployments would be inappropriate for the IETF to do.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 13 Nov 2012 16:14:07 +0100

Hi Sam:

In such a case, it sounds reasonable. No concern, at least, from my side.

Best regards.

---

From: Gabriel Lopez <[email-masked]>
Date: Tue, 13 Nov 2012 17:40:25 +0100

> In such a case, it sounds reasonable. No concern, at least, from my side.
I agree.