You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT

This page lists entity metadata values that are well known as source of operational issues affecting SAML2 implementations in eduGAIN. According to the severity of the issues, the eduGAIN OT may reject the feed containing the metadata. Whatever the action the eduGAIN OT will undertake, it will promptly contact the Identity Federation responsible for the feed and it will try to solve the issue without any service interruption if possible.


CodeConditionKnow Operational IssuesPossible actions
CR
  • an upstream metadata feed from an identity federation contains a CR (Carriage Return) as a literal character reference ("
"  or "&#xD")
  • the feed is aggregated as is in the eduGAIN metadata
  • another identity federation pick up the eduGAIN metadata and republish it to their own parties leaving untouched the CR

(2016) Relying parties not able to validate the metadata

(2019-08-21) .NET based signature validation fails  (ADFSToolkit and other Powershell aggregate handlers impacted) - signaled by InCommon member to ADFSToolkit team via ADFSToolkit issue tracker , escalated and resolved by InCommon support. 

(2020) .NET based signature validation fails (ADFSToolkit and  other Powershell aggregate handlers not able to validate the metadata)

  • Warn and remedy by the Identity Federation responsible for the feed
  • Reject the upstream feed containing the CR

Notes

2020-10-15 side note on Code CR from Chris Phillips:

This .Net parsing issue was seen Sept 2019 and was submitted to the Microsoft Security Center (msrc.microsoft.com) on Sept 12, 2019. Including a full test harness with fabricated data illustrating the failure with the following description upon submission:

User entered data could trigger improper XML validation and thus improper failure in validating trust in properly signed XML documents wherever .net/powershell library is used

MSRC assigned a tracking #VULN-009799 to the submission at the time. A reply by MSRC came October 28,2019 to Chris Phillips after MSRC completed their assessment and said:

"The engineering team has finished their investigation and determined it does not meet the bar for servicing. They were not able to determine a situation where this would be exploitable, and at worst the system returns a 'not valid' response when it should return 'valid' meaning it's failing in a more secure direction."


DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT

  • No labels