In order to carry out operations of the Federation, UNC System Office will furnish an apache web server as the required communication infrastructure. This web server will supply the XML metadata needed for authoritative attribute authorizations as well as the discovery service required to connect individual users with the appropriate identity provider. In addition, this web server will be responsible for performing the necessary certificate authority operations as outlined below.
UNC System Office will provide disaster recovery for this hardware at an alternate site. Specifically, the federation infrastructure will have dedicated resources at this alternate location to enable recovery from a catastrophic loss within one business day plus time to fully propagate DNS changes. Every 24 hours, all federation data will be securely mirrored from the production server to the disaster recovery server.
The following list represents the sequential technical steps required to bring a new member into the Federation and add its identity provider.
-
Provision Administrative Account - Each member institution will have one administrative account that will be required to perform the necessary administrative actions. The authentication for this account will be based on the local identity provider credentials. The authorization will be manually added by the staff at UNC System Office. The technical contact for the member entity will be the only individual given this authorization.
-
Respond to Required Questions - The technical contact will supply institution approved information to each of the questions from ???. Some of this data is for informational purposes only, while other data elements will be used directly in the XML metadata.
-
Technical Contact Submits CSR (Creates a Ticket)
-
The technical contact creates a certificate signing request (CSR).
-
The technical contact will upload this CSR using the administrative interface. This upload will occur over a standard web browser (SSL) encryption to ensure privacy and security.
-
Additional metadata-specific information will be provided during this step and stored in a database. This information will be required to be added the newly signed request to the federation metadata.
-
-
Verify CSR Submission - UNC System Office will send an email or place a telephone call to the technical contact to verify the authenticity of the uploaded CSR.
-
UNC System Office Signs the CSR - Please see Section 3.2, “Certificate Signing”, for details about the signing process. The successful completion of this process will generate a certificate (CRT) for usage by the federation.
-
Push Certificate (CRT) to Metadata
-
UNC System Office will add the new CRT to the "ticket" in question using a web interface.
-
Adding the CRT in this manner will automatically:
-
Notify the original technical contact of its availability. At which point, the technical contact can login to the system and download the CRT for usage.
-
Update the federation metadata to incorporate this new identity provider or service provider.
-
-
-
Verify - UNC System Office will validate the addition to ensure the federation metadata continues to function properly.
The following section describes the operations around the certificate authority that UNC System Office will manage for the Federation.
The following profile describes the public key of the certificate authority. All CSRs will be signed by the corresponding private key; the public nature of this key is critical as users must have the ability to verify the authenticity of this public key through an alternate published source. This certificate profile will also be published on the Federation's web site for public consumption.
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 0 (0x0)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=US, ST=North Carolina, L=Chapel Hill, O=UNC General Administration,
CN=federation.northcarolina.edu/emailAddress=root@northcarolina.edu
Validity
Not Before: Mar 12 15:06:12 2008 GMT
Not After : Mar 10 15:06:12 2018 GMT
Subject: C=US, ST=North Carolina, L=Chapel Hill, O=UNC General Administration,
CN=federation.northcarolina.edu/emailAddress=root@northcarolina.edu
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:b1:60:92:1c:29:81:9e:8e:bc:4a:64:25:24:7a:
73:ce:75:b9:f2:62:43:31:30:f4:d1:21:ed:52:42:
bf:1a:39:9d:88:cb:b2:09:92:f5:13:b8:e1:bd:bb:
35:49:df:21:de:6f:eb:40:f1:7b:d1:d7:39:14:fc:
4e:78:23:38:c4:14:d0:1a:ae:fb:68:4d:44:75:2e:
aa:bb:39:65:90:82:aa:14:81:5c:1d:be:2a:fb:f7:
d8:27:09:16:ee:e3:ef:4b:76:2f:49:f8:87:62:ae:
72:1f:e6:95:94:87:cb:62:06:23:a5:fc:38:42:1a:
92:fd:e9:ca:d9:c2:6e:c4:27:fa:74:db:df:d6:20:
24:f9:c5:7f:52:5c:e9:6e:dd:b6:41:c4:70:75:b3:
ad:62:9b:27:4d:d7:d4:f4:a6:dd:74:0b:9e:d6:54:
e6:9c:f5:35:51:27:fd:0e:d0:15:44:36:8e:89:4c:
6a:b1:fb:12:74:50:92:8b:54:0c:23:58:a1:b2:b3:
78:d2:31:73:05:34:b1:db:7e:97:20:72:66:d4:d3:
b0:2f:23:d5:db:2d:27:39:27:ca:7f:02:3a:de:ed:
09:2e:b6:19:18:50:30:65:a7:bb:06:f4:41:d7:83:
80:3f:71:65:47:7b:d7:47:9a:74:af:26:0c:0f:39:
0d:79
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
70:B1:64:94:CE:F2:6E:C4:09:FF:06:46:21:73:4E:8C:2A:0F:22:2C
X509v3 Authority Key Identifier:
keyid:70:B1:64:94:CE:F2:6E:C4:09:FF:06:46:21:73:4E:8C:2A:0F:22:2C
DirName:/C=US/ST=North Carolina/L=Chapel Hill/O=UNC General Administration
/CN=federation.northcarolina.edu/emailAddress=root@northcarolina.edu
serial:00
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: md5WithRSAEncryption
34:8c:85:9f:26:0c:5c:a4:87:88:af:84:7a:6e:ba:02:4a:5b:
94:4d:c3:9b:e5:67:09:78:50:65:cb:f6:cd:42:60:8f:1b:f5:
4a:c8:a3:4a:ff:b2:c9:46:48:6b:ba:33:3f:87:12:b6:f5:46:
ff:87:58:38:7f:b2:cf:d7:ab:67:f1:5c:1b:d6:7c:a6:33:d2:
0d:f3:5f:a3:97:10:f8:a8:91:54:02:6b:24:e8:33:dc:4d:2f:
a1:d6:6f:86:62:67:b4:f8:17:d1:46:2a:07:e1:aa:55:d8:3f:
7e:ce:87:04:41:c0:b3:4b:e8:b4:2b:4d:80:b4:86:4f:f2:8a:
78:d1:ad:10:ff:7d:33:c0:3f:31:5c:73:de:5a:92:98:70:3f:
7e:89:97:9c:20:38:09:22:87:fa:7e:e2:09:54:dd:2c:f7:2d:
0a:65:25:e5:bd:f9:84:10:b4:a1:75:5c:d0:6e:cc:5e:1c:ad:
12:63:19:c1:bf:ac:8e:00:dc:c9:25:ba:39:77:d2:59:0a:d0:
d5:d7:9d:49:63:79:f5:9b:a3:ce:1d:cc:48:d9:5d:82:01:c9:
41:a9:d2:ee:82:d4:93:3d:ec:20:3a:56:96:22:a4:15:32:97:
fd:f7:61:22:f6:06:39:2d:dd:fd:ec:c7:5a:23:db:0f:cc:d1:
0e:59:7d:8e
All certificate signing requests (CSR) will be valid for a period of 1,095 days from the date of signature. Therefore, all participating federation members will be required to re-issue CSRs for signing every 3 years. This security measure is taken to ensure only valid identity providers and service providers are periodically claimed by their owner.
The certificate authority has the responsibility to keep the private key truly private. The integrity of the entire Federation depends on this fact. As such, UNC System Office will enact the following steps to maximize the integrity of the private key and minimize the risk of exposure:
-
The private key will be removed from ALL machines accessible via the network.
-
The private key will be burned on a CD.
-
Two backup copy of this CD will be burned as well as a thumb drive (for a total of 3 backup copies)
-
Three copies of the private key (2 CDs and one thumb drive) will be placed in a locked safe.
-
The locked safe will be bolted to the floor within the machine room of the CA.
-
Only 2 individuals (Director of Online Service and Director of Network & Media Services) will have a key to the safe.
-
The machine room will have a cipher lock combination known only to a small group of systems and network administrators.
-
The machine room will be monitored by a camera and notification system.
-
The final copy of the private key will be placed in a safe at an alternate physical location (for disaster recovery).
UNC System Office will perform the following auditing steps to minimize the risk of CA breach:
-
Unix's Logwatch will be enabled to alert systems administrators to any unexpected machine behavior.
-
A paper based log will be placed within the safe and the the safe opener will be required to fill out the following information each time the safe is opened.
-
Name of person opening the safe.
-
Title of person.
-
Reason for opening the safe.
-
Materials removed from the safe.
-
Time safe was opened.
-
Materials returned to the safe.
-
Time safe was closed.
-
-
The database responsible for capturing signed certificate (CRT) files will capture the userid of the individual signing the certificate as well as the time stamp of upload.
The following list represents the sequence of steps required by the CA to sign a CSR and return the newly created CRT file to the original owner.
-
The Certificate Authority Administrator (CAA) will copy the CSR from the uploaded ticket to the dedicated location on the signing machine. This CSR will reside in this location indefinitely so as to expedite recovery from a CA breach.
-
The CAA will contact one of the dedicated individuals with a key to the safe (Safe Opener - SO)
-
The SO will unlock the safe and fill out the required auditing form.
-
The SO will give the CD containing the private key to the CAA.
-
The CAA will take the CD and insert it into the CA machine.
-
The CAA will mount the CD within the operating system. During this time, only the root user may access the CD due to Unix file system permissions.
-
The CAA will proceed to sign the CSR with the CA's private key from the CD.
-
The CAA will un-mount and eject the CD from the machine.
-
The CAA will return the CD to the SO.
-
The SO will return the CD to the safe and complete the corresponding audit log.
-
The SO will lock the safe.
-
Both the SO and the CAA will leave the room.
-
The CAA will take the appropriate actions of incorporating the CRT into the federation metadata and sending it to the requesting institution.
In the event that the private key of an identity or service provider is exposed, then that certificate must be revoked by the CA to minimize the risk for malicious actions resulting from the use of the breached key. However, the Federation uses explicit certificates embedded directly within the metadata. Therefore, the traditional need to maintain separate certificate revocation lists (CRL) is not required since only explicitly enumerated certificates are valid within the federation. Consequently, the procedure for revoking is greatly simplified and the security around this revocation is greatly enhanced.
-
The technical contact (TC) for the member institution creates a new private key for the identity provider or service provider in question.
-
The TC creates a certificate signing request (CSR) from this private key.
-
The TC utilizes the web-based administrative interface to upload the CSR.
-
UNC System Office (UNC SO) follows the standard process (see Section 3.2, “Certificate Signing”) for generating the new CRT.
-
GA will replace the original CRT with the newly created CRT. This replacement will be automatically published the new CRT to the federation metadata, thereby, instantly revoking the original CRT.
-
GA will notify the TC and make the new CRT available for download from the administrative interface.
While great lengths have been taken to avoid exposure of the CA signing key, the following section describes the operations that will occur in order to recover from this security violation. The key is considered compromised if it leaves the control of UNC System Office; in other words, they key is compromised if the physical media is separated from the secure possession of UNC System Office.
-
UNC System Office (UNC SO) will notify both the administrative and technical contacts of each participating member via email.
-
UNC SO will create a new certificate authority public and private key pair.
-
UNC SO will replace the original public key in the Federation metadata with the new one. This will have the effect of revoking the certificate from the Federation since it uses explicit key enumeration.
-
The newly created key pair will be used for the following sequence of steps FOR EACH certificate signing request (CSR) that was previously signed by the federation:
-
Resign the CSR, from the original request (See Section 3.2, “Certificate Signing”). This has the effect of revoking the original CRT as described in Section 3.3, “Certificate Revocation”.
-
Update the metadata with the new CRT file.
-
Send the CRT to the technical contact of the member.
-
-
UNC SO will securely destroy the original media that contained the private key.
-
UNC SO will securely create new media that contains the private key.
-
UNC SO will completely remove the private key from all networked machines.
-
UNC SO will notify both the administrative and technical contact of each participating member via email at the conclusion of the recovery process.