Shibboleth Developers

["Scott Cantor" <>]

> How about an option that would limit the access to the signed metadata
> to some IP ranges only or only a certain number/minute.

It supports an ACL list now, but not ranges. Time criteria would require
persistence via the storage service. Is somebody volunteering to provide
patches for this?
 
> Mhh, why is the time so important?

Because there is no transport authentication here. Time is only one of the
issues, but not even really the main one.

> I would say that the URL you download
> is important (compared to the URLs contained in the validated metadata)
> but not necessarily the time.

That requires transport authentication, DNSSEC, or other technology, and in
turn a pre-existing key/relationship. It's not possible to bootstrap trust
solely off of a key you don't know to begin with. Even if you have a fresh
signature, you can't know that you're communicating with the actual entity
you want. Only knowledge of a key in advance (or via a PKI) can give you
that.

> Well, in our case SP descriptions are created while being authenticated
> with SWITCHaai. After creation by an SP admin, the SP description has to
> be approved by an Resource Registration Authority admin (RRA) of the
> organization that this SP description is registered for. The RRA then
> has to check the assertion consumer URLs, required attributes etc. and
> the embedded certificate(s).

That authentication process is what dictates your security, not PoP. I think
that's what Ian's trying to point out. If you have one, you don't need the
other (or you're saying your process there is in need of strengthening).

> Now some colleagues argue like this: If you want to embed certificates
> in the metadata, how do you make sure that the (potentially self-signed)
> certificate that is approved by the RRA was really added to the
> description by the legitimate SP admin and not somebody who stole the
> person's account information?

The same threat exists whether you embed the certificate or not. If I can
get into your account, I can create a bogus SP definition, key or no key.
The key is not sufficient for defining an SP, only the metadata as a whole
is. The key is just one of the fields. If I were going to attack you,
wouldn't I create the SP definition such that the callback for the metadata
later would succeed?

For another thing, if I don't embed the certificate I still have to give you
the key *name*. Short of dictating a single CA, that leaves you just as
vulnerable. And I hope by now people understand that simply does not scale.

> We thought b. could be verified by the Resource Registry downloading a
> signed metadata file from the registered SP and validating its
> signature. This would be proof of possession if you could make sure that
> the downloaded metadata was coming from an URL associated with the
> registered SPs endpoints (which can be very easily verified by an RRA).

The only way to make sure of that is TLS (or similar). If you're positing
that a simple DNS callback is sufficient, I'd make two points:

- That's one of the major criticisms of OpenID. It's certainly one of mine
anyway.

- That would probably be weaker than using a strong password to administer
the SP metadata in your registry and uploading the key (or key name) there
alone.

> - Only allow embedding certificates issued by one of our
> controlled/accepted CAs. Because getting one of these certs involves
> some identity checking procedure this would solve a.

That's a huge lose. Please don't do this. Every large SP will thank you.

> But all of these options have their disadvantages of course and
> therefore we still haven't decided yet.

My feeling is you're overthinking the problem if you're still planning to
use a password-based process to supply the other SP metadata. If you do
that, you already have enough to accept the key, and if not, you probably
need to make other changes.

-- Scott