Subject: Re: [abfab] 4K limit

From: Klaas Wierenga <[email-masked]>
Date: Fri, 9 Dec 2011 14:36:36 +0100

Hi,

Apologies for reopening a discussion that seems to have concluded (my only excuse is that I was hovering most of the last 2 weeks 20 meters below the surface of the Red Sea).
But I still need some more convincing that we MUST carry the SAML data over AAA. It seems to me that using the AAA fabric just to introduce the parties to each other and do additional attribute exchange out-of-AAA-band has a number of advantages, most importantly, no issue with the 4k limit. I find the argument that intermediate nodes may need to rewrite attributes not very convincing, after all there are many hub-and-spoke federations in SAML-space that do just that routinely, no need for AAA intermediaries. 
In this respect our use is very different from the AAA+EAP for network access use-case, there we are suffering from the fact that the supplicant has no layer 3 connectivity yet, but in the abfab case all actors have IP-connectivty?

Or am I just being dense? In that case please enlighten me (beyond "but doing everything over AAA is a much cleaner solution")

Klaas

On Nov 29, 2011, at 6:55 PM, DIEGO LOPEZ GARCIA wrote:

> 
> On 29 Nov 2011, at 09:10 , Alejandro Perez Mendez wrote:
>> I think that the "more SAML data" attribute proposed by Alan would work
>> also if included in requests. In such a case, the AAA/idP could send an
>> Access-Challenge message (including User-Name and State attributes, for
>> example), waiting for more data to come from the RP.
> 
> As Alan noted, we should aim for a more general name for the attribute. Though the exchange of SAML data is the main (and probably unique, at least for the moment) use case, I don't see any hurt in using something like "more additional data" or "more external data" or "more authorization data"...
> 
>> Additionally, the "more SAML data" could contain some kind of "cookie"
>> or "nonce" value, in such a way that if returned unmodified in the
>> following Request/Response message to the creator, it allows to tie all
>> the messages within a conversation, if other means (e.g. State
>> attribute) are finally not enough or not applicable.
> 
> Indeed. I think it would provide not only this tying mechanism, but also the possiblity of using it to point the conversation (and the subject of the data being exchanged) to the elements providing those additional authorization data, and I guess this could satisfy what Josh called the decoupling of the authentication and assertion roundtrips.
> 
> Be goode,
> 
> --
> "Esta vez no fallaremos, Doctor Infierno"
> 
> Dr Diego R. Lopez
> Telefonica I+D
> 
> 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
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Alan DeKok <[email-masked]>
Date: Fri, 09 Dec 2011 15:11:53 +0100

> But I still need some more convincing that we MUST carry the SAML data over AAA. It seems to me that using the AAA fabric just to introduce the parties to each other and do additional attribute exc…

  I agree that intermediate nodes do not need to rewrite the attributes.

  There may still be benefits from using AAA.  The simplest is using one
technology for everything.

  The alternative is to put the SAML attributes in HTTP (everything over
HTTP), and give a URL to the end host.  This brings additional issues of
copying the data from AAA server to HTTP server, authenticating the
client which gets the SAML data, securing the data transfer, etc.

  Alan DeKok.

---

From: Klaas Wierenga <[email-masked]>
Date: Fri, 9 Dec 2011 15:56:30 +0100

> technology for everything.

yes, that argument I buy, and is in fact the only compelling argument I was able to come up with.

> client which gets the SAML data, securing the data transfer, etc.

Well, aren't the SAML IdP and RP already involved? The SAML entities would act as some sort of Authentication Server backend, Active Directory with a callback…. Is it likely that we will have a AAA-only RP or IdP rather than a generic IdP/RP? I think that in particular for the IdP that is an unlikely scenario, it will most likely also support HTTP. And rather than seeing it as a URL I would like to regard it is a endpoint identifier. I don't care for HTTP in particular, presumably this could be a case for SAML-ECP…

Klaas

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 9 Dec 2011 17:45:21 +0000

The basic argument is that you need two trust fabrics, one for AAA and one
for SAML. You lose some fairly significant benefit to ABFAB if you need
the SAML layer anyway. You could just do SAML alone. Some of us want to
pursue that anyway, but in the capacity of an ABFAB comment, that's the
issue.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Fri, 09 Dec 2011 15:43:10 -0500

I think it is fairly likely that the IDP and RP will have the software
to do normal SAML things, but in some of the deployments we're looking
at will not have the provisioning (keys, metadata etc) to do SAML over
HTTP.

Also, I actually think there will be intermediates that will want to
rewrite attributes.

---

From: Nico Williams <[email-masked]>
Date: Fri, 9 Dec 2011 14:50:32 -0600

> at will not have the provisioning (keys, metadata etc) to do SAML over

And I wouldn't want to encourage reliance on the HTTPS PKI.

However, what could be done is that an attribute with a URI could also
have a digest of the thing to be fetched via HTTP, and maybe a digest
of the server cert or an intermediate CA for it (or perhaps a key that
the actual attribute payload will be encrypted in, that way we can use
plain HTTP).  But this starts sounding hairy.

> Also, I actually think there will be intermediates that will want to

I imagine so.  I can see several reasons: 1) to rewrite attributes
understood by one side into attributes understood by the other, 2) to
apply privacy policies.  (2) might be common in a deployment with a
common, trusted trust broker, so to speak.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Fri, 09 Dec 2011 16:01:34 -0500

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> However, what could be done is that an attribute with a URI
    Nico> could also have a digest of the thing to be fetched via HTTP,
    Nico> and maybe a digest of the server cert or an intermediate CA
    Nico> for it (or perhaps a key that the actual attribute payload
    Nico> will be encrypted in, that way we can use plain HTTP).  But
    Nico> this starts sounding hairy.

We can certainly do this.
It starts getting quite involved though and illustrates  the value of
AAA.

---

From: Leif Johansson <[email-masked]>
Date: Sun, 11 Dec 2011 12:09:36 +0100

> plain HTTP).  But this starts sounding hairy.

Drop the cert bits and you're essentially describing the way openid connect uses a resource token (oauth) to de-reference attributes.

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Sun, 11 Dec 2011 18:43:07 +0100

> Drop the cert bits and you're essentially describing the way openid connect uses a resource token (oauth) to de-reference attributes.

But in OpenID Connect the token is used to get access to the attributes, not for establishing trust beetwen the RP (the client in OpenID parlance) and the attribute source. As Alan stated, going this way you cannot get rid of the need for two parallel trust infrastructures, and I think that is the essential argument for transfrerring the SAML data inside RADIUS.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

---

From: Klaas Wierenga <[email-masked]>
Date: Sun, 11 Dec 2011 19:55:57 +0100

Sent from my iPad

> But in OpenID Connect the token is used to get access to the attributes, not for establishing trust beetwen the RP (the client in OpenID parlance) and the attribute source. As Alan stated, going th…

Yeah, I guess that makes sense, thanks for indulging....

Klaas

---

From: Leif Johansson <[email-masked]>
Date: Mon, 12 Dec 2011 09:50:27 +0100

On 12/11/2011 06:43 PM, DIEGO LOPEZ GARCIA wrote:
>>> However, what could be done is that an attribute with a URI
>>> could also have a digest of the thing to be fetched via HTTP,
>>> and maybe a digest of the server cert or an intermediate CA for
>>> it (or perhaps a key that the actual attribute payload will be
>>> encrypted in, that way we can use plain HTTP).  But this starts
>>> sounding hairy.
>>> 
>> 
>> Drop the cert bits and you're essentially describing the way
>> openid connect uses a resource token (oauth) to de-reference
>> attributes.
> 
> But in OpenID Connect the token is used to get access to the
> attributes, not for establishing trust beetwen the RP (the client
> in OpenID parlance) and the attribute source. As Alan stated, going
> this way you cannot get rid of the need for two parallel trust
> infrastructures, and I think that is the essential argument for
> transfrerring the SAML data inside RADIUS.

Sorry. I thought dereferencing an attribute handle was exactly what
Nico was talking about here.

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Dec 2011 09:59:43 -0600

> Nico was talking about here.

Well. I was addressing part of the trust issue as well.  Instead of
simply getting a URI to dereference you'd also get some cryptographic
metadata with which to authenticate either the location or the
dereferenced data itself.

Nico
--

---

From: Klaas Wierenga <[email-masked]>
Date: Mon, 12 Dec 2011 17:06:44 +0100

> dereferenced data itself.

yes, that is also what I had in mind when I talked about "trusted introducer"

Klaas

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Mon, 12 Dec 2011 17:19:58 +0100

> yes, that is also what I had in mind when I talked about "trusted introducer"

The point here is how much information you'd have to put in such a handle to establish trust (in both directions) when dereferencing it, and the additional mechanisms at both sides. I guess it was Nico the one that mentioned that this could become "hairy"…

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Dec 2011 10:47:43 -0600

> The point here is how much information you'd have to put in such a handle to establish trust (in both directions) when dereferencing it, and the additional mechanisms at both sides. I guess it was…

If the handle were to include authentication of the referenced data
then we'd have synchronization issues.

If the handle were to include server authentication data that would be
easier, but we'd still have revocation and key rollover issues.  But
if we do this hop-by-hop then those issues are not new -- it's only if
we try to skip hops that we run into new issues.

HTTP is just a protocol.  I offer it because it doesn't have a payload
size limit.

Nico
--