Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 involving editing and/or restructuring of the metadata.

 

...

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:

 

Code Block
languagexml
titleDefault 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:

 

Code Block
languagexml
titlerelying-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>

 

 

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.

...

Code Block
languagexml
titleVulnerable 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.

...

Code Block
languagexml
titleNew 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.

...

Code Block
languagexml
titleMixed 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. 

...