Subject: [kitten] Multiple attribute providers in an authentication

From: Sam Hartman <[email-masked]>
Date: Mon, 10 Jan 2011 14:17:48 -0500

Background: there was a discussion between authors of the abfab
architecture proposal about multiple attribute providers.
The idea is that you have an identity provider that is producing a set
of attributes about a subject. In the case of ABFAB we're mostly
thinking of a SAML IDP for this particular example.

The IDP  has some attributes it may be in a position to assert.
But the IDP may also want to gather attributes from other  sources and
pass those along.

One option it has is to simply pass the attributes along as if it issued
them itself.  That option isn't really interesting from a protocol
standpoint because it is indistinguishable from the IDP actually issuing
the attribute itself.  That is probably a fine thing to do in certain
deployments but we don't need to spend a lot of time on it.

Another option is that the IDP can go actually get a SAML assertion (or
attribute certificate or the like) and include that in what is sent to
the RP.

At first glance, the protocol implications of doing this look
simple. You just stick the assertion in the existing bag of bits and
move on.

however, it's not that simple because of semantics.

Today in ABFAB, we haven't done a great job of describing what the trust
semantics of the attribute in draft-ietf-abfab-aaa-saml are. However
what has been going through at least Josh and my mind is that the RP
SHOULD assume that the AAA framework provides an integrity protected
channel for that SAML message. The message is actually issued by the IDP
corresponding to the NAI used to make the access request. In addition,
for the SAML assertions sent from the IDP to the RP, the RP SHOULD
assume that the IDP is asserting those attributes about the subject.
That is, the RP need not perform any validation of the SAML
assertion. The RP still needs to validate whether the IDP is permitted
to make the claims it does.
There's no requirement that these SAML assertions be signed.
The IDP MAY sign the assertion; the RP MAY consider any signatures that
are present. However in the interoperable case, any signatures that are
present are ignored.

If there are multiple assertions from the same IDP it seems reasonable
to treat them all the same.

Things get a lot more messy  when assertions from multiple IDPs are
included.
What does it mean to include them in the AAA transport?  I can think of
several trust models that are appropriate depending on deployment:

* The IDP corresponding to the subject's NAI has validated these
  additional assertions and wishes to assert that the attributes can be
  trusted. "If you trust me then you should trust these." Here, the
  assertions are being included either for convenience of packaging the
  attributes into some form the RP can process or because it is possible
  that the RP may be able to validate some signature and trust the
  attribute source more than the IDP.

* The subject IDP has performed SAML validation on the
  assertions. However the IDP is making no claims about how trusted the
  attributes included in the additional assertions are. Even if the IDP
  would be permitted to make a claim made in an additional assertion,
  the RP needs to make an independent policy decision about whether the
  actual issuer should be permitted to make that claim.

* Here are some assertions for the RP's convenience. The IDP makes no
  claims about them; not even the implied claim that they have not been
  modified in transit. They better be signed, the RP better have
  metadata for their issuer, and the RP is more or less on its own.

Another source of complexity surrounds how an IDP links an assertion to
a subject. What confidence is the RP asserting that the additional
assertion describes the same principal as the access-accept message.

Another potential source of complexity is how does the IDP know what
information to gather? Does the IDP just know somehow? Does the RP pass
information back?

How does the RP make the policy decisions it needs to make? How does it
get metadata that is needed?

I think this sort of issue will also have impacts for kitten, because
we'll need to describe it in the naming extensions interface. It seems
like ABFAB is not going to be the only group facing these sorts of
discussions; Kerberos is in the middle of a similar discussion right
now.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 10 Jan 2011 20:55:57 +0100

Sam,

Thanks for taking the time to describe the problem. 

> are present. However in the interoperable case, any signatures that are

You mean is that the security model you have in mind does not require
that SAML assertions be signed?  We may have an additional software
layering problem- specifically, if they are present, and you're using a
SAML library to parse the messages, from a practical standpoint, an
error may be returned.

However, I think what you're alluding to is that the lack of a signature
itself is *part* of the problem of returning attributes from 3rd
parties, since the associated connectivity of the AAA transport is
providing authenticity and *not *the signature.

> [snip]

> assertion describes the same principal as the access-accept message.

On this point - the IdP either is or is not authoritative for knowing at
the very least where the information is going to come from.  The only
question here is whether or not it is willing to vouch for the
information itself.
> information to gather? Does the IDP just know somehow? Does the RP pass
And this is a generic problem with attribute providers.  The general
answer is either that the principal provides a pointer, or it finds the
information through external means.  Again, the only issues in this case
are whether the IdP is providing some sort of surety, and whether it can
be assumed that there is a trust relationship between the RP and the
attribute provider.  That latter one is a much bigger deal, IMHO!

Regards,

Eliot

---

From: "Cantor, Scott E." <[email-masked]>
Date: Mon, 10 Jan 2011 20:18:46 +0000

> You mean is that the security model you have in mind does not require that
> SAML assertions be signed?  We may have an additional software layering
> problem- specifically, if they are present, and you're using a SAML library to
> parse the messages, from a practical standpoint, an error may be returned.

That shouldn't be a concern, or if it is you've got much bigger problems because the assumptions about trust and key management that such broken code would make will be a problem in their own right.

> However, I think what you're alluding to is that the lack of a signature itself is
> part of the problem of returning attributes from 3rd parties, since the
> associated connectivity of the AAA transport is providing authenticity and not
> the signature.

I think it's more that if you stick with the simple case, you don't need them, and if you do need them,  a host of more complex concerns become important.

> On this point - the IdP either is or is not authoritative for knowing at the very
> least where the information is going to come from.  The only question here is
> whether or not it is willing to vouch for the information itself.

Some people (I should be clear I'm not one of them) believe that without a uniform subject identifier across all such assertions, you lose any hope of auditing the linkability of the identies later. And achieving that uniformity does some tortuous things to the SAML flows needed to get the assertions built.

I agree with Eliot that the issues associated with knowing what attributes to get, what sources to use, etc., are general problems, not confined to this use of SAML, or to SAML itself.

But usually when aggregation is involved, there is less need for a fully dynamic system without administrative intervention, in my experience.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Mon, 10 Jan 2011 15:23:10 -0500

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

    Eliot> Sam, Thanks for taking the time to describe the problem.

You are welcome.
I realized that I did not explicitly say it, but I think all these
complexities are tractable.
We will have to do work in order to support this use case.
I think that work is not in scope for what we're signed up to do now,
although if someone stepped forward and wanted to  do the work, it could
happen sooner.

I think that some of this may require some work in kitten.
>     Today in ABFAB, we haven't done a great job of describing
> what the trust semantics of the attribute in
> draft-ietf-abfab-aaa-saml are. However what has been going
> through at least Josh and my mind is that the RP SHOULD
> assume that the AAA framework provides an integrity protected
> channel for that SAML message. The message is actually issued
> by the IDP corresponding to the NAI used to make the access
> request. In addition, for the SAML assertions sent from the
> IDP to the RP, the RP SHOULD assume that the IDP is asserting
> those attributes about the subject.  That is, the RP need not
> perform any validation of the SAML assertion. The RP still
> needs to validate whether the IDP is permitted to make the
> claims it does.  There's no requirement that these SAML
> assertions be signed.  The IDP MAY sign the assertion; the RP
> MAY consider any signatures that are present. However in the
> interoperable case, any signatures that are present are
> ignored.

    Eliot> You mean is that the security model you have in mind does not
    Eliot> require that SAML assertions be signed?  We may have an
    Eliot> additional software layering problem- specifically, if they
    Eliot> are present, and you're using a SAML library to parse the
    Eliot> messages, from a practical standpoint, an error may be
    Eliot> returned.

Perhaps.
With Shibboleth we certainly are no longer having issues with this.
I'd be interested in hearing from other SAML implementeors.

Note that you are equally likely to have trouble if the message is
signed and you don't have metadata.  So, you're going to have a better
user experience if your SAML library does not require signatures.

    Eliot> However, I think what you're alluding to is that the lack of
    Eliot> a signature itself is part of the problem of returning
    Eliot> attributes from 3rd parties, since the associated
    Eliot> connectivity of the AAA transport is providing authenticity
    Eliot> and not the signature.

No; you can always (as the issuer at least) add signatures.
Supporting a case where the third party attributes are just carried and
the RP is responsible for validation is fairly easy at the protocol
level. It probably requires a different AAA attribute that doesn't imply
the contents should be trusted. That is, the RP is free to ignore
signatures on assertions in the current attribute, but would need to
validate assertions from third parties. However that's one new AAA
attribute, which is fairly simple.
My personal opinion is that it's also fairly useless.
We're assuming that the RP and IDP don't have any requirement for a
trust relationship other than through the AAA fabric. Why is it more
reasonable to assume a trust relationship with a third party.
There are some situations where this model is exactly what you need.

Complexity comes in if you want to offload more trust to the IDP.

    Eliot>     [snip]

>     Another source of complexity surrounds how an IDP links
> an assertion to a subject. What confidence is the RP
> asserting that the additional assertion describes the same
> principal as the access-accept message.

    Eliot> On this point - the IdP either is or is not authoritative for
    Eliot> knowing at the very least where the information is going to
    Eliot> come from.  

I agree with this sentence. I don't understand how it fits into the
 quoted paragraph above.

    Eliot> The only question here is whether or not it is
    Eliot> willing to vouch for the information itself.

I agree that's a question.
I'm again not sure that it fits into the question of subject linkage,
except that one hopes the subject linkage is fairly good if the IDP does
vouch for the information.

>     Another potential source of complexity is how does the
> IDP know what information to gather? Does the IDP just know
> somehow? Does the RP pass information back?

    Eliot> And this is a generic problem with attribute providers.  The
    Eliot> general answer is either that the principal provides a
    Eliot> pointer, or it finds the information through external means.

Sure.  But we need to provide protocols and APIs to actually convey that
throughout the system.  It's real engineering that needs doing for
things to work, but again is certainly something we can do.

    Eliot>     Eliot> Again, the only issues in this case are whether the IdP is
    Eliot> providing some sort of surety, and whether it can be assumed
    Eliot> that there is a trust relationship between the RP and the
    Eliot> attribute provider.  That latter one is a much bigger deal,
    Eliot> IMHO!

I'm definitely missing how these relate to what information the RP
wants.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 10 Jan 2011 22:27:58 +0100

Hi Sam,

Thanks for your response.  Let me add that this is really not a big
issue with me for now.  I see some very interesting use cases that
relate to liability concerns around certain attributes, and I consider
this conversation useful just to the point of knowing whether we are
able to accomplish the task of having attribute providers later, if and
when demand warrants.

> I agree with this sentence. I don't understand how it fits into the

I may have misunderstood what you originally wrote.

Perhaps what you are saying is that if there is absolutely no
requirement that the IdP trust the attribute provider at all, that it
simply passes bits, then there is a risk that the information returned
might not be related to the principal.  I would suggest that it is
incumbent on the attribute provider to at least make an assurance that
it won't happen, because you're right- the RP cannot be assured
otherwise because it may not have sufficient information or even
authorization to reference the principal to the RP.

One other challenge here would be to consider whether it is permissible
that the unique index or name of the principal in the context of the
attribute provider could leak to the RP.  If that name is covered by a
signature, it cannot easily be removed.

Eliot

---

From: Sam Hartman <[email-masked]>
Date: Mon, 10 Jan 2011 18:54:03 -0500

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

    Eliot> Perhaps what you are saying is that if there is absolutely no
    Eliot> requirement that the IdP trust the attribute provider at all,
    Eliot> that it simply passes bits, then there is a risk that the
    Eliot> information returned might not be related to the principal.
    Eliot> I would suggest that it is incumbent on the attribute
    Eliot> provider to at least make an assurance that it won't happen,
    Eliot> because you're right- the RP cannot be assured otherwise
    Eliot> because it may not have sufficient information or even
    Eliot> authorization to reference the principal to the RP.

That's one case.
Another case is where say you are linking principals based on names and
you have two principals with the same name. E.G. I want to provide an
assertion about credit availability. My credit score attribute provider
can linke based on SSN (in the US) or name.
The IDP doesn't have the SSN, so it has to ask about the name.
What happens if the linking is off.

    Eliot> One other challenge here would be to consider whether it is
    Eliot> permissible that the unique index or name of the principal in
    Eliot> the context of the attribute provider could leak to the RP.
    Eliot> If that name is covered by a signature, it cannot easily be
    Eliot> removed.

O, thanks for enumerating this one!

---

From: Gabriel López <[email-masked]>
Date: Tue, 11 Jan 2011 09:01:27 +0100

>    attribute source more than the IDP.
It should require a trust relationship between attribute providers and 
idp, in order to validate attribute assertions before to sent them all 
together to the RP. I just want to remark the requirement of this trust 
relationship.
>    actual issuer should be permitted to make that claim.
you could include here XACML
>    metadata for their issuer, and the RP is more or less on its own.
I'm not sure to understand this point. Do you need the trust 
relationship between RP and idP?
> information to gather? Does the IDP just know somehow? Does the RP pass
The RP could request specific attributes in a SAML Attribute Query. 
Beside, idP/attribute provider could decide what attributes be disclosed 
to the RP, by means of attribute release policies (XACML?)

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

-- 
----------------------------------------------------------------
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Wed, 19 Jan 2011 20:18:07 -0500

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

    Jim> Would you consider it to be permissible for an intermediate to
    Jim> re-write the assertions to change the framework they are being
    Jim> made in from the IdP's home network to the federation network's
    Jim> framework?  This would say that they may not have quite the
    Jim> same degree of integrity protection as might be initially
    Jim> assumed.

AAA integrity is hop-by-hop.
I don't think we'll have technical mechanisms in some deployments to
prevent this.
In some cases (draft-howlett-radsec-kmp springs to mind) it might be
fairly tricky to do that.
I don't think we've discussed the role of intermediates much.
I can think of several models including:

* Intermediates are good and need to be permitted to muck about.
* When intermediates can muck about it's OK for them to do so.
* Intermediates must not muck about; future deployment and other
 mechanisms may restrict their ability to do so more than is restricted
 today.

We have not discussed  a lot what the answer is.

In some of the work Josh and I did we ran into a number of cases where
having the intermediates be able to examine the information passing
through has been quite valuable.
(We typically found that out when we designed a mechanism to
short-circuit some intermediate and then ended up adding a lot of
complexity to get the intermediate some information.)

Similarly in discussions at the Kerberos Consortium conference this
fall, several people believed that having an organizational policy
intermediate near the RP would be valuable. (In that community they
believed a KDC would be a great place to put such an intermediate.)

    >> assertion. The RP still needs to validate whether the IDP is
    >> permitted to make the claims
    Jim> it
    >> does.  There's no requirement that these SAML assertions be
    >> signed.  The IDP MAY sign the assertion; the RP MAY consider any
    >> signatures that
    Jim> are
    >> present. However in the interoperable case, any signatures that
    >> are
    Jim> present
    >> are ignored.
    >> 
    >> If there are multiple assertions from the same IDP it seems
    >> reasonable to treat them all the same.
    >> 
    >> Things get a lot more messy when assertions from multiple IDPs
    >> are included.

    Jim> Are you saying that the principal has multiple names or that
    Jim> they are multiple assertions being made about a single name?

Both.
I'm assuming all the assertions are about the same subject/principal,
but that entity may be known by multiple names.
Someone needs to actually make sure that all the assertions are about
the same subject.
That is quite tricky.

    >> Another source of complexity surrounds how an IDP links an
    >> assertion to a subject. What confidence is the RP asserting that
    >> the additional assertion describes the same principal as the
    >> access-accept message.
    >> 
    >> Another potential source of complexity is how does the IDP know
    >> what information to gather? Does the IDP just know somehow? Does
    >> the RP pass information back?

    Jim> What happens if the naming space of the claims is different
    Jim> between the IDP and the RP?

To the extent that problem exists, I think it is independent of whether
multiple attribute provders or one attribute provider is involved.  I
think we're defining the use of NAIs as a way to have a common name
space between the RP and the first IDP.
That is, the AAA federation substrate for abfab needs to provide some
naming services to guarantee that we have a common namespace between the
RP and IDP.

    Jim> What happens if the additional attributes need to come from a
    Jim> completely different fourth realm?  I.e. my name comes from the
    Jim> country of issue, the RP is a bank and the attributes need to
    Jim> come from a university?

*this* is the first point I was getting at in the paragraph from my
 original message.
I consider this situation complicated.
    Jim> I completely agree this is a hard problem that we need to start
    Jim> writing down, if not answers then at least boundaries of the
    Jim> problem.

Yes.  I and as I understand it Moonshot don't need to solve this problem
to make forward progress.  I think building some walls around the
problem and starting to understand where it is is valuable.  However
until someone steps forward and wants to spend (or fund) significant
cycles on this, I don't think we will solve it.

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 19 Jan 2011 16:06:01 -0800

Sam 

Comments in line.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Sam Hartman
> Sent: Monday, January 10, 2011 11:18 AM
> To: [email-masked]; [email-masked]
> Subject: [abfab] Multiple attribute providers in an authentication
> 
> 
> The idea is that you have an identity provider that is producing a set of
> attributes about a subject. In the case of ABFAB we're mostly thinking of
a
> SAML IDP for this particular example.
> 
pass
> those along.
them
> itself.  That option isn't really interesting from a protocol standpoint
because
> it is indistinguishable from the IDP actually issuing the attribute
itself.  That is
> probably a fine thing to do in certain deployments but we don't need to
> spend a lot of time on it.
> 
> attribute certificate or the like) and include that in what is sent to the
RP.
> 
> At first glance, the protocol implications of doing this look simple. You
just
> stick the assertion in the existing bag of bits and move on.
> 
> semantics of the attribute in draft-ietf-abfab-aaa-saml are. However what
> has been going through at least Josh and my mind is that the RP SHOULD
> assume that the AAA framework provides an integrity protected channel for
> that SAML message. The message is actually issued by the IDP corresponding
> to the NAI used to make the access request. In addition, for the SAML
> assertions sent from the IDP to the RP, the RP SHOULD assume that the IDP
> is asserting those attributes about the subject.

Would you consider it to be permissible for an intermediate to re-write the
assertions to change the framework they are being made in from the IdP's
home network to the federation network's framework?   This would say that
they may not have quite the same degree of integrity protection as might be
initially assumed.  

> That is, the RP need not perform any validation of the SAML assertion. The
> RP still needs to validate whether the IDP is permitted to make the claims
it
> does.
are
> present. However in the interoperable case, any signatures that are
present
> are ignored.
> 
> If there are multiple assertions from the same IDP it seems reasonable to
> treat them all the same.
> 

Are you saying that the principal has multiple names or that they are
multiple assertions being made about a single name?  

> Another source of complexity surrounds how an IDP links an assertion to a
> subject. What confidence is the RP asserting that the additional assertion
> describes the same principal as the access-accept message.
> 

What happens if the naming space of the claims is different between the IDP
and the RP?

What happens if the additional attributes need to come from a completely
different fourth realm?  
I.e. my name comes from the country of issue, the RP is a bank and the
attributes need to come from a university?

> I think this sort of issue will also have impacts for kitten, because
we'll need
> to describe it in the naming extensions interface. It seems like ABFAB is
not
> going to be the only group facing these sorts of discussions; Kerberos is
in the
> middle of a similar discussion right now.

I completely agree this is  a hard problem that we need to start writing
down, if not answers then at least boundaries of the problem.

Jim