Date: Fri, 29 Mar 2024 08:28:06 +0000 (UTC) Message-ID: <226956761.7705.1711700886298@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7704_1214513924.1711700886296" ------=_Part_7704_1214513924.1711700886296 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
In September 2013, the Metadata Distribution Working Group submitted its= Phase 1 R= ecommendations to the InCommon Technical Advisory Committee. This FAQ a= nticipates questions and concerns regarding a Phase 1 Implementation Plan to = be initiated December 2013.
Yes, for the first time since the formation of the InCommon Federation, = the location of InCommon metadata is changing. This is a big deal, we know,= but the time is ripe for change.
InCommon Operations will deploy three new metadata aggregates at the fol= lowing permanent HTTP locations:
The new locations will replace the current HTTP location of production m= etadata:
Moving forward, all new metadata services will be deployed on vhost wayf.incommonfederation.org will be phased out.
Multiple, heterogeneous services currently run on legacy vhost way=
f.incommonfederation.org
, namely, InCommon Metadata Services and the Discovery Service. To provide bette=
r quality of service, these services need to be segregated onto separate vh=
osts (md.incommon.org
and ds.incommon.org
, resp.)=
. Note: The InCommon Federated Error Handling Service is already running on ds.inc=
ommon.org
.
If this were the only reason to move to a new vhost, we probabl= y wouldn't be doing it (which is why we haven't done it until now). There a= re other, more significant reasons for making this change. See the Phase 1 Implementation Plan for a complete list of = drivers, some of which are discussed below.
All metadata services on legacy vhost wayf.incommonfederation.org<=
/code> will be decommissioned on March 29, 2014. At that time, we will=
install a redirect from the legacy metadata aggregate to the new fallb=
ack metadata aggregate. That redirect will remain in place indefinitel=
y.
All deployments should migrate ASAP
All SAML deployments shall migrate to one of the new metadata aggregates= ASAP but no later than March 29, 2014.
Yes, traditionally the InCommon metadata signing certificate has been se= t to expire every three years. It will next expire on May 2, 2014. Mor= e importantly, the InCommon metadata signing certificate is signed by a leg= acy CA whose certificate expires on March 29, 2014. This is why we cho= se the above migration deadline.
Moving forward, all new metadata aggregates will be signed using a new s= elf-signed signing certificate set to expire on December 18, 2037:
In the future, we don't intend to re-sign the new self-signed metadata s= igning certificate unless it's absolutely necessary.
The trusted InCommon metadata signing = key will not change
Although the metadata signing certificate is new, the metadata signing k= ey is not.
Like the vhost issue, if this were the only reason for making t= hese changes, we probably wouldn't be doing it. Even together with= the new vhost, it's debatable whether or not these changes are warranted, = but in any case, an emerging SHA-2 requirement is the straw that breaks the= camel's back.
XML Signature uses a so-called digest algorithm to compute a hash of the= signed XML node. The current metadata signing process relies on the SHA-1 = digest algorithm. We are updating the process to use SHA-2 instead of SHA-1= .
Out of the chute, two of the new metadata aggregates will use different = digest algorithms (the third aggregate is for future use):
Currently the XML signature on InCommon metadata uses the deprecated (an= d soon-to-be disallowed) SHA-1 digest algorithm:
This is motivating the migration to a SHA-2 digest algorithm.
All deployments should be compatible w= ith SHA-2
All SAML deployments shall consume metadata signed with a SHA-2 digest a= lgorithm by June 30, 2014.
Multiple metadata= aggregates allow us to deploy changes to InCommon metadata more quickl= y, easily, and safely. Metadata consumers choose exactly one of the aggrega= tes depending on the immediate requirements of their deployment.
Each deployment chooses one aggregate<= /p>
Each deployment in the InCommon Federation shall migrate to one (and onl= y one) of the new metadata aggregates no later than March 29, = 2014.
The fallback metadata aggregate comes into play when a breaking= change is inadvertently introduced into InCommon metadata (such as SHA-2).= When a change is made to the production metadata aggregate, and that chang= e breaks a downstream metadata process, an affected deployment can temporar= ily migrate to the fallback metadata aggregate. This gives the deployment t= ime to adjust to the breaking change.
The fallback metadata aggregate is transient in the sense that = backward compatibility is provided for a limited, predetermined period of t= ime. In the case of SHA-2, deployments have approximately three months (bey= ond the March 29 milestone) to become compatible with SHA-2. At that t= ime, the fallback metadata aggregate will be synced with the p= roduction metadata aggregate, which forces all deployments to conform.=
Eventually all published metadata will= be signed with SHA-2
All SAML deployments shall migrate to the new production metadata ag= gregate (or the preview metadata aggregate) ASAP but = no later than June 30, 2014. From that day forward, all metad= ata aggregates published by InCommon will be signed using a SHA-2 digest al= gorithm.
Like the fallback metadata aggregate, the preview metadata aggregate= helps manage the introduction of potentially breaking changes into In= Common metadata. Before such a change is deployed in production, it is firs= t introduced in preview mode. Any issues that surface are addressed before = the change is moved to production.
The preview metadata aggregate is designed for deployments on the leadin= g edge, such as test and dev deployments. Such deployments are strongly enc= ouraged to consume the preview metadata aggregate instead of the production= metadata aggregate.
An important decision point for each deployment is whether to migrate to= the new production metadata aggregate or the preview metadata= aggregate. Regardless of whether your deployment is compatible with S= HA-2, determine the ultimate goal (production or preview) and plan accordin= gly. Depending on timing, you may have to temporarily migrate to the fa= llback metadata aggregate to reach your ultimate goal.
In the FAQs that follow, where it says "migrate to the production me= tadata aggregate," it should say "migrate to the production metada= ta aggregate or the preview metadata aggregate, whatever make= s the most sense for your deployment."
Shibboleth IdP deployments in the InCommon Federation are least affe= cted by this implementation plan.
Being a pure Java implementation, the Shibboleth IdP software will verif= y an XML signature based on a SHA-2 digest algorithm if the underlying vers= ion of Java supports SHA-2. Therefore all Shibboleth IdP deployments based = on Java version 1.4.2 (or later) should migrate to the new product= ion metadata aggregate ASAP (but no later than March 29, 2014).= p>
If you are running Shibboleth IdP version 2.0 (or later), you are a= lmost certainly running Java 1.4.2 (or later). In that case, your soft= ware is compatible with SHA-2 and you can migrate to the new production= metadata aggregate at your convenience (but no later than March = 29, 2014).
There are two modifications you need to make to your IdP=E2=80=99s metadata configura= tion:
metadataURL
XML attribute on the <MetadataPro=
vider>
element should point to the HTTP location of the new p=
roduction metadata aggregate.The second step above is optional (since the new signing certificate con= tains the same key as the old signing certificate) but it is a recommended = practice nonetheless. See the Metadata Consumption wiki page for instructions how to secur= ely obtain a copy of the new metadata signing certificate.
Shibboleth SP version 2.0 (or later) supports SHA-2 but whether or = not it can deliver that support depends on the version of OpenSSL in use by= the SP. As a special case, since OpenSSL is bundled with the Shibboleth SP= software on the Windows platform, SHA-2 support on Windows is assured.
On the Windows platform, the Shibboleth SP software will verify an XML s= ignature based on a SHA-2 digest algorithm. Therefore Windows-based Shibbol= eth SP deployments should migrate to the new production metadata aggreg= ate (or the preview metadata aggregate) ASAP but no later tha= n March 29, 2014.
Since OpenSSL is not bundled with the Shibboleth SP sof= tware on a non-Windows platform, SHA-2 compatibility depends on the version= of OpenSSL in use by the SP.
Old versions of OpenSSL are not compat= ible with SHA-2
If your deployment depends on an old version of the OpenSSL crypto libra= ry, it may be unable to verify the signature on the new metadata aggregate.= In particular, versions of OpenSSL prior to 0.9.8 are known to be incompat= ible with SHA-2 and therefore any platform that depends on OpenSSL 0.9= .7 (or earlier) will not be able to verify an XML signature that uses a SHA= -2 digest algorithm.
If the Shibboleth SP software is installed on an unsupported OS platform= , it is likely you are running an old version of OpenSSL that doesn=E2=80= =99t support SHA-2. For example, RHEL 4 was built with OpenSSL version= 0.9.7, which is known to be incompatible with SHA-2.
On Linux, the Shibboleth SP software depends on whatever version of Open= SSL is built into the underlying operating system, and so it is relatively = easy to determine the version of OpenSSL in use:
$ /usr/= bin/openssl version OpenSSL 0.9.8y 5 Feb 2013
If you're running the Shibboleth SP software on any other operating syst= em (Solaris, Mac OS X), you need to determine the OpenSSL dependency b= y some other means.
Bottom line: If your Shibboleth SP deployment depends o= n OpenSSL version 0.9.8 or later, you should migrate to the new pr= oduction metadata aggregate (or the preview metadata aggregate); otherwise, you should migrate to the fallback metadata aggregate. In either case, there are two modifications you need to make to your SP= =E2=80=99s me= tadata configuration:
url
XML attribute on the <MetadataProvider>=
;
element should point to the HTTP location of the new metadata aggr=
egate.The second step above is optional (since the new signing certificate con= tains the same key as the old signing certificate) but it is a recommended = practice nonetheless. See the Metadata Consumption wiki page for instructions how to secur= ely obtain a copy of the new metadata signing certificate.
Deployments not compatible with SHA-2 = should upgrade ASAP
If your Shibboleth SP deployment is not compatible with= SHA-2, and you have to migrate to the fallback metadata aggregate= , start planning now to upgrade your system so that you ca= n migrate to the new production metadata aggregate by June= 30, 2014.
On Linux, since the Shibboleth SP software depends on whatever version o= f OpenSSL is built into the underlying operating system, you have no choice= but to upgrade to a supported platform.
The simpleSAMLphp metarefresh module = will refresh and verify metadata automatically. Signature verification depe= nds on the fingerprint of the metadata signing certificate, so the fingerpr= int configured in the metarefresh module must be updated before migrating s= impleSAMLphp to one of the new metadata aggregates.
Old versions of simpleSAMLphp are inco= mpatible with SHA-2
It is known that versions of simpleSAMLphp prior to version 1.11 ar= e not compatible with SHA-2. You will need to upgrade to s= impleSAMLphp 1.11 (or later) before migrating to the new productio= n metadata aggregate (or the preview metadata aggregate).
If you're running simpleSAMLphp 1.11 (or later), your software is c= ompatible with SHA-2 and you should migrate to the new production metad= ata aggregate (or the preview metadata aggregate); otherwise = you should migrate to the fallback metadata aggregate. In either c= ase, there are two configuration changes you need to make to simpleSAMLphp'= s metarefresh module:
src
array element should point to the HTTP location of=
the new metadata aggregate.validateFingerprint
array element must reflect the fin=
gerprint of the new signing certificate.The second step is critical for simpleSAMLphp deployments (despite the f= act that the new metadata signing certificate contains the same key as the = old signing certificate). See the Metadata Consumption wiki page for instructions how to s= ecurely obtain the fingerprint of the new metadata signing certificate.
Deployments not compatible with SHA-2 = should plan to upgrade
If your simpleSAMLphp deployment is not compatible with=
SHA-2, and you migrate to the fallback metadata aggregate,
Note: simpleSAMLphp 1.12 is due to be released in = December 2013. You may want to wait for this release since it includes sign= ificant improvements to the metarefresh = module.
Microsoft AD FS 2.0 is not able to consume the InCommon metadata ag= gregate, so the answer depends on the external process you use to refresh a= nd verify metadata on behalf of AD FS. Some deployments use a tool called F= EMMA, which does not verify the signature on the metadata. In this case the= XML signature on the new metadata aggregate will have no adverse effect. A= n AD FS deployment that uses FEMMA is advised to migrate to the new pro= duction metadata aggregate (or the preview metadata aggregate= ) ASAP but no later than March 29, 2014.
FEMMA alone does not provide a secure = metadata refresh process
If your AD FS deployment uses FEMMA alone to consume InCommon metadata, =
it is doing so insecurely. A secure metadata process will verify the signat=
ure on the metadata and check the validUntil
=
attribute on the root element of the XML file. FEMMA does neither. See the =
Metadata Consumptio=
n wiki page for more information about the validUntil
attr=
ibute.
An alternative to FEMMA called pysFEMMA will verify the signatu= re on the metadata, however. Like the Shibboleth SP, an AD FS deployment th= at uses pysFEMMA will have difficulty migrating to the new metadata aggrega= te if the underlying crypto library is incompatible with SHA-2. See the AD FS Metadata Config= wiki page for more detailed information about FEMMA and pysFEMMA.
AFAIK, no commercial product is able to consume the InCommon metadata ag= gregate, so the answer is more-or-less the same as it is for Microsoft AD F= S 2.0: it depends on the tool chain used to refresh and verify metadat= a.
No, ce= rtificates in metadata are not affected by this new policy. Remember, t= he certificate wrapper on keys in metadata is totally irrelevant. Only the = public key bound to the certificate matters.