Shibboleth Developers

[Lukas Haemmerle <>]

> > 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.

That's right, however, so far our people had to own a certificate/key 
pair that was issued by a CA that either was controlled by us or that 
forced them to undergo identification based on paper work (according to 
one of CA acceptance policy). This second requirement for getting an SP 
to receive attributes (besides creating the SP definition based on 
username/password authentication) is what is lost when one can just 
generate a self-signed certificate or use just any key laying around.


> 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?

Yes, but on one hand just defining another endpoint is not enough if you 
want the user's attributes because you still need a certificate to 
decrypt them or to pull them

On the other hand an RRA administrator who has to approve the SP 
definition inspects the callback URL/endpoings, he (hopefully) would get 
suspicious and reject the definition.


> 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.

That's true and that's why we dictated *multiple* CAs that meet certain 
requirements :) But true, in the end it would nevertheless be great to 
get rid of them provided we find an equally secure replacement for the 
CA solution.


> > - 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.

It is clear that we won't do without also providing a way to embed other 
certificates as well because we see the necessity for using certificates 
from other CAs or self-signed certificates, especially for SPs operated 
by commercial content providers.


> > 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.

Personally, I tend to agree with you but as you can see, I work in 
SWITCH's security group and not all colleagues think that solely relying 
on username/password authenticated users and letting the SP endpoints 
get validated by an RRA is sufficient without any further measures to 
keep about the same level of security concerning the certificate, 
whether it is an accepted one of our CA list or an embedded one of any 
CA/selfsigned ...

Lukas

--
SWITCH
Serving Swiss Universities
--------------------------
Lukas Haemmerle, Software Engineer, Security
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 64, fax +41 44 268 15 68
,
 http://www.switch.ch