Versions Compared

Old Version 7

changes.mady.by.user Stefan Winter

Saved on

compared with

New Version Current

changes.mady.by.user Marina Adomeit

Saved on

Key

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

...

This page and its child pages contains description of individual processes dealing with service operations should be noted as well, such as:

  • Service Order
  • Problem resolution
  • Configuration change
  • System update
  • Backup
  • Disaster recovery

RESPONSIBLE: Information provided here is initially populated by the development team (during the transition phase), and revised based on the need or in a yearly service check by service_name Service Managerperiodically.

Client Root CA Signing Ceremony Playbook

...

The ceremony is held on the Xth 2nd day of month Y November in the year Z 2018 A.D. The physical location is: GEANT Association Offices, Amsterdam.

...

M. Milinovic, SRCE (passphrase person #2)

Procedure

  1. S. Winter arrives at GEANT Offices with a Raspberry Pi 3. The Pi has the most recent version of Raspian OS preinstalled, with OpenSSL and the hwrng kernel driver, but no custom software.
  2. The VC begins.
  3. All participants to the ceremony agree on a value "n" for the length of the passphrases. Values smaller than 10 are unacceptable.
  4. S. Winter executes the server CA generation script on the host auth-1.hosted.eduroam.org. This process takes a long time and runs in parallel with the Client Root CA procedures.
  5. The CA generation scripts which are available online at GitHub get downloaded to a USB stick on a computer in GEANT offices.
  6. The

...

  1. Pi gets powered up and connected to a monitor and keyboard available at GEANT offices.
  2. The USB stick gets attached to the Pi, and mounted.
  3. The scripts get copied to local

...

  1. SD card storage.
  2. S. Winter executes the script "CA.bootstrapNewRootCA", answering the interactive questions by the script.
  3. When the script asks for the certificate private key's passphrase, S. Winter makes up a n character password and writes it down

...

  1. in an application on his laptop, for screen sharing.
  2. When the

...

  1. CAs are generated, S. Winter executes the second script, "CA.generateNewIntermediateCA".
  2. When the script asks for the certificate private key's passphrase, S. Winter makes up a different n character password and writes it down

...

  1. on an existing VeraCrypt volume on his laptop.
  2. S. Winter executes the scripts which generate the CRL and OCSP statements, for both the RSA and ECDSA variants.
  3. S. Winter holds up the passphrase to the root CAs into the camera.
  4. M. Milinovic makes a copy of the root CA passphrase and stores it safely for everafter.
  5. S. Winter makes a copy of the root CA passphrase and stores it onto an existing VeraCrypt volume on his own laptop.
  6. S. Winter

...

  1. destroys the piece of paper holding the passphrase. 
  2. S. Winter copies all the public information regarding the CAs onto the USB stick:
    -root CA ECDSA+RSA certificate;
    -intermediate CA ECDSA+RSA certificate;
    -root CA CRL ECDSA+RSA;

...

  1. - root CA OCSP statement for the intermediate CA certificates ECDSA+RSA.
  2. S. Winter copies the following SECRET information to the same USB stick:
    -intermediate CA private keys, RSA and ECDSA variants.
    -root CA private

...

  1. keys, RSA

...

  1. and ECDSA variants
  2. The USB stick gets unmounted.
  3. The Pi is shut down

...

  1. .
  2. D. Visser extracts the root CA private keys into a word processor document and prints them.
  3. D. Visser  places the Pi and the printouts in their physical lockup (safe). The access to that safe is managed internally in GEANT according to local procedures.
  4. S. Winter deletes the root CA private keys from the USB stick.
  5. S. Winter copies the remainder of the information on the USB stick to the relevant locations on the VMs.
  6. The group verifies that meanwhile the server CA generation script has finished.
  7. The VC ends.
  8. The ceremony ends.

Client and Server Root CA Procedures

TBD: where exactly is it stored, access controls to physical location

There will be a key generation ceremony. Q to the SM: is it acceptable to take the preparatory steps before traveling to the signing ceremony? Or do everything live?

The Client Root CA is stored in GEANT Offices inside a safe, according to local organisation procedures. None of the persons with physical access have knowledge of the passphrase to the private keys.

The passphrase to the Root CA private keys is known to the Service Owner (M. Milinovic) and S. Winter (DevOps team). Both of these have no access to the physical storage of the key file.

VM snapshot restore procedure 


1. eduroam-OT sends a request to the GEANT IT Support <support@it.geant.org>, to restore a specific machine, from a given date,

      1-a If the restore is urgent (which IMHO will always be the case), CC qaiser and Allen to the email, and note "URGENT" in subject of the message

      1-b In this message eduroam-OT states if they want that the:

          1-b-1 restored snapshot replace the existing VM, or

          1-b-2 restored snapshot to be separately accessible so that they can manually retrieve the needed information

2. GEANT IT restores the VM as per request, detailed in 1-b.

          2-a The restore time is not guaranteed, as GEANT IT is not 24/7. For urgent ones follow 1-a !!

3. GEANT IT confirms to the eduroam-OT that the restore was complete

4. eduroam-OT confirms that the restore was successful and optionally informs in case of 1-b-2, if the restored VM is no longer needed

5. restore request is closedTBD: who has the password for the encrypted private key, how is it stored, how is long-term accessibility ensured.