IdP Metadata Question

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

IdP Metadata Question

Paul Hethmon
IdP Metadata Question I recently had one of my SP’s point out to me that my IdP metadata does not have a “validUntil” or “cacheDuration” attribute on the “EntityDescriptor”. While the spec lists both as optional when it defines them, it later goes on to say that if “EntityDescriptor” is the root node, then one or the other is required. The default metadata generated by Shibboleth does not put either there.

After searching the wiki and the mailing list, I can’t seem to find anything which talks about how to maintain the IdP metadata. Obviously Shib reads the idp-metadata.xml file per the configuration in the relying-party.xml file, but I’m making an assumption here that once that file is created at the initial install time, it’s up to me (the IdP operator) to maintain it going forward. So if I want to put a “validUntil” date in there, I need to keep track of that date and change it as necessary.

thanks,

Paul

-----
Paul Hethmon
Chief Software Architect
Clareity Security, LLC
865.824.1350 - office
865.250.3517 - mobile
www.clareitysecurity.com
-----

God does not play dice with the universe; He plays an ineffable game of his own devising, which might be compared, from the perspective of any of the other players, to being involved in an obscure and complex version of poker in a pitch dark room, with blank cards, for infinite stakes, with a dealer who won't tell you the rules, and who smiles all the time.

 -- Terry Pratchett, Good Omens

Reply | Threaded
Open this post in threaded view
|

Re: IdP Metadata Question

Chad La Joie
Yes, that is all correct.  As Scott has said numerous times, what the
IdP and SP are generating is a *starting point* for deployers but it is
up to you to take it further and maintain it.

Note, the IdP generates its metadata at install time, it never
regenerates it.  The SP regenerates it every time you hit the metadata URL.

Paul Hethmon wrote:

> I recently had one of my SP¹s point out to me that my IdP metadata does not
> have a ³validUntil² or ³cacheDuration² attribute on the ³EntityDescriptor².
> While the spec lists both as optional when it defines them, it later goes on
> to say that if ³EntityDescriptor² is the root node, then one or the other is
> required. The default metadata generated by Shibboleth does not put either
> there.
>
> After searching the wiki and the mailing list, I can¹t seem to find anything
> which talks about how to maintain the IdP metadata. Obviously Shib reads the
> idp-metadata.xml file per the configuration in the relying-party.xml file,
> but I¹m making an assumption here that once that file is created at the
> initial install time, it¹s up to me (the IdP operator) to maintain it going
> forward. So if I want to put a ³validUntil² date in there, I need to keep
> track of that date and change it as necessary.
>
> thanks,
>
> Paul
>
> -----
> Paul Hethmon
> Chief Software Architect
> Clareity Security, LLC
> 865.824.1350 - office
> 865.250.3517 - mobile
> www.clareitysecurity.com
> -----
>
> God does not play dice with the universe; He plays an ineffable game of his
> own devising, which might be compared, from the perspective of any of the
> other players, to being involved in an obscure and complex version of poker
> in a pitch dark room, with blank cards, for infinite stakes, with a dealer
> who won't tell you the rules, and who smiles all the time.
>
>  -- Terry Pratchett, Good Omens
>
>
>

--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
[hidden email], http://www.switch.ch

Reply | Threaded
Open this post in threaded view
|

RE: IdP Metadata Question

Cantor, Scott E.
Chad La Joie wrote on 2009-06-19:
> Yes, that is all correct.  As Scott has said numerous times, what the
> IdP and SP are generating is a *starting point* for deployers but it is
> up to you to take it further and maintain it.
>
> Note, the IdP generates its metadata at install time, it never
> regenerates it.  The SP regenerates it every time you hit the metadata URL.

Another point is that metadata expiration only applies if the metadata isn't being physically maintained in the same place as the consumer. The IdP loading its own metadata for obvious reasons doesn't need that metadata to "expire" because it's loading it from the local file system and it's by definition under the IdP admin's control.

The SP doesn't load its metadata, so there's no comparable question there.

When you supply metadata "out to the world", in a form that assumes dynamic consumption, then the use of validUntil (and sometimes cacheDuration) is critical to the secure operation of the system, particularly if you rely on the ExplicitKey trust engine model of the world. Revocation is based on the metadata, so unexpiring metadata can be used in an attack to inject old metadata with a compromised key.

Explicit metadata exchange by hand to "get stuff working" by copying files to the servers is in a gray area in which it's not usually clear that validUntil makes sense to require, but it could be used to regulate batch update or somehow prevent it from getting too stale.

In general, there are few "fully baked" models for exchange of metadata that take all the issues into account. Which is why when people ask how to do it we don't have good answers.

We could be facile about it as a marketing tool and say "it's easy, just copy the metadata files to the opposite machines and load them and never touch them again", and ignore how to keep it maintained.
 
-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: IdP Metadata Question

Cantor, Scott E.
In reply to this post by Chad La Joie
Scott Cantor wrote on 2009-06-19:
> We could be facile about it as a marketing tool and say "it's easy, just
> copy the metadata files to the opposite machines and load them and never
> touch them again", and ignore how to keep it maintained.

It's worth adding that this is really what the PKI view of the system is. In the days when PKIX was the assumed trust model, you would generally just exchange the metadata and not worry about it unless URLs changed, because the metadata just carried the identifiers of the certificates used.

We need to create the documentation needed to explain the basic concept of metadata so that people understand what in the heck they're doing here. That is still on my TODO list.
 
-- Scott


Reply | Threaded
Open this post in threaded view
|

Re: IdP Metadata Question

Paul Hethmon
In reply to this post by Cantor, Scott E.
On 6/19/09 11:26 AM, "Scott Cantor" <[hidden email]> wrote:

> When you supply metadata "out to the world", in a form that assumes dynamic
> consumption, then the use of validUntil (and sometimes cacheDuration) is
> critical to the secure operation of the system, particularly if you rely on
> the ExplicitKey trust engine model of the world. Revocation is based on the
> metadata, so unexpiring metadata can be used in an attack to inject old
> metadata with a compromised key.

In my case, I've let my SP's consume the metadata by giving them the proper
Shib URL to fetch it from. Until this point, I haven't had any of my relying
parties ask me about expiring the metadata.
 
> Explicit metadata exchange by hand to "get stuff working" by copying files to
> the servers is in a gray area in which it's not usually clear that validUntil
> makes sense to require, but it could be used to regulate batch update or
> somehow prevent it from getting too stale.
>
> In general, there are few "fully baked" models for exchange of metadata that
> take all the issues into account. Which is why when people ask how to do it we
> don't have good answers.

My concern was that by me modifying/maintaining the metadata by hand, I
wasn't breaking something inside of Shib. I think the initial thought that
someone would have is that the IdP metadata would be maintained by Shib, not
that Shib would consume it like any other interested party. It's really
understanding that difference between configuration and metadata. Like I
configure Shib to handle SAML2 SSO POST, but if I want to let someone use
it, I have to publish it in my metadata.


-----
Paul Hethmon
Chief Software Architect
Clareity Security, LLC
865.824.1350 - office
865.250.3517 - mobile
www.clareitysecurity.com
-----

God does not play dice with the universe; He plays an ineffable game of his
own devising, which might be compared, from the perspective of any of the
other players, to being involved in an obscure and complex version of poker
in a pitch dark room, with blank cards, for infinite stakes, with a dealer
who won't tell you the rules, and who smiles all the time.

 -- Terry Pratchett, Good Omens


Reply | Threaded
Open this post in threaded view
|

RE: IdP Metadata Question

Cantor, Scott E.
Paul Hethmon wrote on 2009-06-19:
> In my case, I've let my SP's consume the metadata by giving them the
proper
> Shib URL to fetch it from. Until this point, I haven't had any of my
relying
> parties ask me about expiring the metadata.

That's probably (I'll argue) because they don't understand the security
implications. And again, it depends on the trust model. You don't have to
put keys in there just because we happen to favor that approach,
particularly if you're using SPs from vendors.
 
> My concern was that by me modifying/maintaining the metadata by hand, I
> wasn't breaking something inside of Shib. I think the initial thought that
> someone would have is that the IdP metadata would be maintained by Shib,
not
> that Shib would consume it like any other interested party.

I would agree.

> It's really
> understanding that difference between configuration and metadata. Like I
> configure Shib to handle SAML2 SSO POST, but if I want to let someone use
> it, I have to publish it in my metadata.

That's why I favored the position that the components should, where
possible, never consume their own metadata. I still think the IdP can be
modified to avoid that, but it will take some of the same awkward
configuration bits that the SP uses to get around it.

-- Scott