...
Metadata Category | Impact of Being Incorrect |
|---|---|
Certificates in IdP metadata (i.e., a public key in metadata corresponding to the IdP's signing key) | A spoofed IdP may push false identity assertions to SPs that trust the correct IdP. |
Endpoints (especially | IdP users may be phished. Also, the IdP's user community may suffer a service outage. |
Certificates and endpoints in SP metadata | Loss of PII when identity assertions are sent to a spoofed SP. Also, the SP's user community may suffer a service outage. |
Entity attributes that indicate the trustworthiness of an entity (e.g., Identity Assurance qualifiers and other qualifiers for which the Federation operator is authoritative) | SPs may place too much trust in an IdP's assertion, or an IdP may send information to an SP that it would not normally trust to receive that information. |
User interface elements in metadata (i.e., MDUI elements) | The entity's user community may be presented with confusing information, with the possibility that users will be misled and/or coerced to do the wrong thing. |
Potential Threats
Wiki Markup
Threat | Potential Impacts | Who Is Impacted | Impact Level | Potential Controls | Questions and Comments |
|---|---|---|---|---|---|
A bad guy controls a certificate entry in IdP metadata, the bad guy could issue arbitrary signed assertions from a Trojan IdP. | The Trojan IdP could actively push bogus assertions to arbitrary SPs. An SP that would otherwise trust that IdP would immediately be compromised. | The SP's community members. | Equal to the impact level of the IdP's highest assurance profile (Unassured - Low, LoA1 - Low, LoA2 - Medium, LoA3 - Medium, LoA4 - High). |
| Today, injecting a certificate into metadata is a two-step operation. First, the certificate is uploaded to the secure server. Second, the certificate is bound to metadata. The first step can and should include compensating controls. |
A bad guy controls a SingleSignOnService endpoint in IdP metadata. | Users redirected to that endpoint could be phished. | The IdP's community members. | Low increase in impact, given existing mitigation for authentication in each assurance profile. |
| Today, all domains in metadata are validated by the RA and remain valid for at least one year. To introduce a bogus domain into metadata, a bad guy would have to control a host in a valid domain or poison the whois database that the RA uses to validate a domain. |
A bad guy controls SP metadata, using it to create a Trojan service. | IdPs could be coerced to send identity information (perhaps PII) to the Trojan service. | The IdP's community members. | Equal to the impact of an SP improperly using the identity information it's given. |
| The impact level depends on the specific attributes that are asserted to the SP. |
A bad guy controls a DiscoveryResponse endpoint in SP metadata. | Users redirected to that endpoint could be phished. | The IdP's community members. | Low increase in impact of phishing, due to the fact that any SP can create a DS that ignores metadata. |
| |
An authorized guy could (intentionally or unintentionally) insert bad metadata for an entity. | Errors in metadata can affect the assurance, confidentiality, integrity availability, or reputation of the entity. | The entity's community members. | Equal to the impact of "insider" threats for an IdP's highest assurance profile, or to the CIA or reputation of any entity. |
| Given the system and human controls currently in place, it would be very difficult for an authorized user to hurt anyone outside the immediate community of interest. |
The authentication service required by the FM for a particular administrator may not be available, and a repair may require that administrator to modify metadata. | Users of that authentication service (e.g., IdP) will experience an outage until InCommon personnel can intervene. | The IdP's community members. | Equal to the impact of outages for the IdP's highest assurance profile. |
|
|
...