The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.

20150225 Security Advisory Examples

Owned by Brent Putman
Last updated: Feb 25, 2015
6 min read

This page serves as additional explanatory text and examples related to the security advisory Identity Provider and OpenSAML-J PKIX Trust Engines Exhibit Critical Flaw In Trusted Names Evaluation.

To make the examples clearer, parts of the XML not relevant to illustrating the problem, such as non-relevant element content and namespace declarations, will be omitted.

 

SAML Metadata Problem Example

This SAML metadata example illustrates the starting problematic case.

 

SAML Metadata with vulnerable EntityDescriptors
<!-- The top-level entities group containing globally-scoped key authorities. -->
<md:EntitiesDescriptor name="allEntities">

  <!-- All entities within this EntitiesDescriptor are within the scope of these key authorities. -->
  <md:Extensions>
    <shibmd:KeyAuthority> ... </shibmd:KeyAuthority>
    <shibmd:KeyAuthority> ... </shibmd:KeyAuthority>
  </md:Extensions>

  <!-- This entity has only a KeyName and uses the PKIX trust model. -->
  <md:EntityDescriptor entityID="https://www.example1.org/sp">
    <md:SPSSODescriptor>
      <md:KeyDescriptor>
		<ds:KeyInfo>
			<ds:KeyName>www.example1.org</ds:KeyName>
		</ds:KeyInfo>
      </md:KeyDescriptor>
    </md:SPSSODescriptor>
  </md:EntityDescriptor>

  <!-- This entity has a key specified by an X509Data element for use with the explicit key model.
       It also has a KeyName.  It is not vulnerable to this issue. -->
  <md:EntityDescriptor entityID="https://www.example2.org/sp">
    <md:SPSSODescriptor>
      <md:KeyDescriptor>
		<ds:KeyInfo>
			<ds:KeyName>www.example2.org</ds:KeyName>
			<ds:X509Data> ... </ds:X509Data>
		</ds:KeyInfo>
      </md:KeyDescriptor>
    </md:SPSSODescriptor>
  </md:EntityDescriptor>

  <!-- This entity has a key specified by an X509Data element for use with the explicit key model.
       It does not have a KeyName and is therefore vulnerable to this issue. -->
  <md:EntityDescriptor entityID="https://www.example3.org/sp">
    <md:SPSSODescriptor>
      <md:KeyDescriptor>
		<ds:KeyInfo>
			<ds:X509Data> ... </ds:X509Data>
		</ds:KeyInfo>
  </md:EntityDescriptor>

 </md:EntitiesDescriptor>

 

In the example above, entity https://www.example3.org does not contain a KeyName and may be impersonated by anyone with a certificate issued by one of the CA's enumerated by the KeyAuthority elements.

 

Mitigation Approaches

The best mitigation is to upgrade the IdP to version 2.4.4 or greater.

If upgrading the software is not possible, then there are several mitigation approaches: one involving disabling all PKIX trust engines and several involving editing and/or restructuring of the metadata.

 

Approach 1: Disable PKIX trust engines

This approach involves changing the IdP's configuration to disable use of PKIX trust engines.  Do this ONLY if it is known that the IdP does not need to interact with any SP's whose trust is established based on the PKIX trust model, or if temporary loss of access to such SP's is acceptable.

The IdP ships with the following default TrustEngine configuration in relying-party.xml:

 

Default IdP trust engine configuration in relying-party.xml
     
<security:TrustEngine id="shibboleth.SignatureTrustEngine" xsi:type="security:SignatureChaining">
  <security:TrustEngine id="shibboleth.SignatureMetadataExplicitKeyTrustEngine" xsi:type="security:MetadataExplicitKeySignature" metadataProviderRef="ShibbolethMetadata"/>                              
  <security:TrustEngine id="shibboleth.SignatureMetadataPKIXTrustEngine" xsi:type="security:MetadataPKIXSignature" metadataProviderRef="ShibbolethMetadata"/>
</security:TrustEngine>
    
<security:TrustEngine id="shibboleth.CredentialTrustEngine" xsi:type="security:Chaining">
  <security:TrustEngine id="shibboleth.CredentialMetadataExplictKeyTrustEngine" xsi:type="security:MetadataExplicitKey" metadataProviderRef="ShibbolethMetadata"/>
  <security:TrustEngine id="shibboleth.CredentialMetadataPKIXTrustEngine" xsi:type="security:MetadataPKIXX509Credential" metadataProviderRef="ShibbolethMetadata"/>
</security:TrustEngine>

 

 

The configuration would be modified to remove or comment out the the 2 -MetadataPKIX- TrustEngine elements as follows:

 

relying-party.xml configuration with PKIX trust engines disabled
 <security:TrustEngine id="shibboleth.SignatureTrustEngine" xsi:type="security:SignatureChaining">
  <security:TrustEngine id="shibboleth.SignatureMetadataExplicitKeyTrustEngine" xsi:type="security:MetadataExplicitKeySignature" metadataProviderRef="ShibbolethMetadata"/>                              
  <!-- This trust engine is commented out and disabled
  <security:TrustEngine id="shibboleth.SignatureMetadataPKIXTrustEngine" xsi:type="security:MetadataPKIXSignature" metadataProviderRef="ShibbolethMetadata"/> 
  -->
</security:TrustEngine>
    
<security:TrustEngine id="shibboleth.CredentialTrustEngine" xsi:type="security:Chaining">
  <security:TrustEngine id="shibboleth.CredentialMetadataExplictKeyTrustEngine" xsi:type="security:MetadataExplicitKey" metadataProviderRef="ShibbolethMetadata"/>
  <!-- This trust engine is commented out and disabled
  <security:TrustEngine id="shibboleth.CredentialMetadataPKIXTrustEngine" xsi:type="security:MetadataPKIXX509Credential" metadataProviderRef="ShibbolethMetadata"/>
  -->
</security:TrustEngine>

 

Unless configuration reloading of relying-party.xml is enabled, the IdP will need to be restarted for this change to take effect.

 

Approach 2: Add KeyNames for all entities

This approach involves ensuring that all entities have at least one KeyName for every KeyDescriptor that they contain.

 

Vulnerable entity with KeyName added
 <!-- The top-level entities group containing globally-scoped key authorities. -->
<md:EntitiesDescriptor name="allEntities">

  <!-- All entities within this EntitiesDescriptor are within the scope of these key authorities. -->
  <md:Extensions>
    <shibmd:KeyAuthority> ... </shibmd:KeyAuthority>
    <shibmd:KeyAuthority> ... </shibmd:KeyAuthority>
  </md:Extensions>


  <!-- For clarity, other entities not shown.  -->
  <md:EntityDescriptor entityID="https://www.example1.org/sp"> ... </md:EntityDescriptor>
  <md:EntityDescriptor entityID="https://www.example2.org/sp"> ... </md:EntityDescriptor> 

  <!-- This entity has a key specified by an X509Data element for use with the explicit key model.
       A KeyName has been added and it is no longer vulnerable to this issue. -->
  <md:EntityDescriptor entityID="https://www.example3.org/sp">
    <md:SPSSODescriptor>
      <md:KeyDescriptor>
		<ds:KeyInfo>
			<ds:KeyName>www.example3.org</ds:KeyName>
			<ds:X509Data> ... </ds:X509Data>
		</ds:KeyInfo>
  </md:EntityDescriptor>

 </md:EntitiesDescriptor>

 

Approach 3: Split the metadata

This approach involves splitting the metadata source document into 2 distinct documents: 1) one containing the KeyAuthority elements and any entities which rely on the PKIX model 2) one containing no KeyAuthority elements and only entities which rely on the explicit key model only.  A new metadata provider is then defined which consumes the new PKIX-only metadata source document.

 

Original source: Non-PKIX entities
<!-- KeyAuthority elements removed, and only entities using the explicit key model. -->
<md:EntitiesDescriptor name="nonPKIXEntities">

  <!-- This entity has a key specified by an X509Data element for use with the explicit key model.
       It also has a KeyName.  It is not vulnerable to this issue. -->
  <md:EntityDescriptor entityID="https://www.example2.org/sp">
    <md:SPSSODescriptor>
      <md:KeyDescriptor>
		<ds:KeyInfo>
			<ds:KeyName>www.example2.org</ds:KeyName>
			<ds:X509Data> ... </ds:X509Data>
		</ds:KeyInfo>
      </md:KeyDescriptor>
    </md:SPSSODescriptor>
  </md:EntityDescriptor>

  <!-- This entity has a key specified by an X509Data element for use with the explicit key model.
       It does not have a KeyName but is no longer vulnerable to this issue. -->
  <md:EntityDescriptor entityID="https://www.example3.org/sp">
    <md:SPSSODescriptor>
      <md:KeyDescriptor>
		<ds:KeyInfo>
			<ds:X509Data> ... </ds:X509Data>
		</ds:KeyInfo>
  </md:EntityDescriptor>

 </md:EntitiesDescriptor> 

 

 

New source: PKIX Entities
 <!-- The top-level entities group containing globally-scoped key authorities. -->
<md:EntitiesDescriptor name="pkixEntities">

  <!-- All entities within this EntitiesDescriptor are within the scope of these key authorities. -->
  <md:Extensions>
    <shibmd:KeyAuthority> ... </shibmd:KeyAuthority>
    <shibmd:KeyAuthority> ... </shibmd:KeyAuthority>
  </md:Extensions>

  <!-- This entity has only a KeyName and uses the PKIX trust model. -->
  <md:EntityDescriptor entityID="https://www.example1.org/sp">
    <md:SPSSODescriptor>
      <md:KeyDescriptor>
		<ds:KeyInfo>
			<ds:KeyName>www.example1.org</ds:KeyName>
		</ds:KeyInfo>
      </md:KeyDescriptor>
    </md:SPSSODescriptor>
  </md:EntityDescriptor>

 </md:EntitiesDescriptor>

 

Approach 4: Move PKIX entities to a dedicated group

This approach involves moving the entities which rely on the PKIX trust model to a dedicated EntitiesDescriptor, along with the relevant KeyAuthority elements.  This "scopes" the KeyAuthority elements so that they only apply to those entities which are descendents of their owning EntitiesDescriptor.

 

Mixed entities with group
<!-- The top-level entities group containing mixed entities.  There are no global key authorities. -->
<md:EntitiesDescriptor name="allEntities">

  <!-- This entity has a key specified by an X509Data element for use with the explicit key model.
       It also has a KeyName.  It is not vulnerable to this issue. -->
  <md:EntityDescriptor entityID="https://www.example2.org/sp">
    <md:SPSSODescriptor>
      <md:KeyDescriptor>
		<ds:KeyInfo>
			<ds:KeyName>www.example2.org</ds:KeyName>
			<ds:X509Data> ... </ds:X509Data>
		</ds:KeyInfo>
      </md:KeyDescriptor>
    </md:SPSSODescriptor>
  </md:EntityDescriptor>

  <!-- This entity has a key specified by an X509Data element for use with the explicit key model.
       It does not have a KeyName but is no longer vulnerable to this issue. -->
  <md:EntityDescriptor entityID="https://www.example3.org/sp">
    <md:SPSSODescriptor>
      <md:KeyDescriptor>
		<ds:KeyInfo>
			<ds:X509Data> ... </ds:X509Data>
		</ds:KeyInfo>
  </md:EntityDescriptor>



  <!-- New entities group containing only entities which use the PKIX model, along with the relevant key authorities. -->
  <md:EntitiesDescriptor name="pkixEntities">
 
 	<!-- All entities within this EntitiesDescriptor are within the scope of these key authorities. -->
  	<md:Extensions>
    	<shibmd:KeyAuthority> ... </shibmd:KeyAuthority>
    	<shibmd:KeyAuthority> ... </shibmd:KeyAuthority>
  	</md:Extensions>

  	<!-- This entity has only a KeyName and uses the PKIX trust model. -->
  	<md:EntityDescriptor entityID="https://www.example1.org/sp">
    	<md:SPSSODescriptor>
      		<md:KeyDescriptor>
				<ds:KeyInfo>
					<ds:KeyName>www.example1.org</ds:KeyName>
				</ds:KeyInfo>
      		</md:KeyDescriptor>
    	</md:SPSSODescriptor>
  	</md:EntityDescriptor>

  </md:EntitiesDescriptor>


 </md:EntitiesDescriptor>

 

Approach 5: Move KeyAuthority elements down to individual entities

This approach involves moving/copying the KeyAuthority extensions down to appear under each EntityDescriptor which uses the PKIX model. 

 

Mixed entities with individual KeyAuthority extensions
<!-- The top-level entities group containing mixed entities.  There are no global key authorities. -->
<md:EntitiesDescriptor name="allEntities">


  <!-- This entity has only a KeyName and uses the PKIX trust model. -->
  <md:EntityDescriptor entityID="https://www.example1.org/sp">

	 <!-- Only the parent EntityDescriptor is within the scope of these key authorities. -->
  	<md:Extensions>
    	<shibmd:KeyAuthority> ... </shibmd:KeyAuthority>
    	<shibmd:KeyAuthority> ... </shibmd:KeyAuthority>
  	</md:Extensions>
 
	 <md:SPSSODescriptor>
      <md:KeyDescriptor>
		<ds:KeyInfo>
			<ds:KeyName>www.example1.org</ds:KeyName>
		</ds:KeyInfo>
      </md:KeyDescriptor>
    </md:SPSSODescriptor>
  </md:EntityDescriptor>


  <!-- This entity has a key specified by an X509Data element for use with the explicit key model.
       It also has a KeyName.  It is not vulnerable to this issue. -->
  <md:EntityDescriptor entityID="https://www.example2.org/sp">
    <md:SPSSODescriptor>
      <md:KeyDescriptor>
		<ds:KeyInfo>
			<ds:KeyName>www.example2.org</ds:KeyName>
			<ds:X509Data> ... </ds:X509Data>
		</ds:KeyInfo>
      </md:KeyDescriptor>
    </md:SPSSODescriptor>
  </md:EntityDescriptor>

  <!-- This entity has a key specified by an X509Data element for use with the explicit key model.
       It does not have a KeyName but is no longer vulnerable to this issue. -->
  <md:EntityDescriptor entityID="https://www.example3.org/sp">
    <md:SPSSODescriptor>
      <md:KeyDescriptor>
		<ds:KeyInfo>
			<ds:X509Data> ... </ds:X509Data>
		</ds:KeyInfo>
  </md:EntityDescriptor>

 </md:EntitiesDescriptor>