ibm education assistance for z/os v2r1 · gsk_protocol_tlsv1_2, &tlsprotocol); ... session id...

© 2013 IBM CorporationMaterial is current as of June 2013

Items: TLS V1.2 Suite B

RFC 5280 Certificate Validation Element/Component: Cryptographic Services - System SSL

IBM Education Assistance for z/OS V2R1

of 48 © 2013 IBM Corporation

Filename: IEA V2R1 System SSL

Agenda

■ Trademarks■ Presentation Objectives■ Overview■ Usage & Invocation■ Interactions & Dependencies■ Migration & Coexistence Considerations■ Presentation Summary■ Appendix

IBM Presentation Template Full Version



Trademarks

■ See url http://www.ibm.com/legal/copytrade.shtml for a list of trademarks.


http://www.ibm.com/legal/copytrade.shtml

http://www.ibm.com/legal/copytrade.shtml



Presentation Objectives

■ At the end of this presentation, you should have an understanding of …– The System SSL line item enhancements for

• TLS V1.2 • Suite B • RFC 5280 Certificate Validation support • General System SSL updates

– How to use the enhancements– Understand how these enhancements affect installation and migration




Overview - TLS V1.2 ■ Problem Statement / Need Addressed:

–Enable use of TLS V1.2 protocol for SSL sessions–Implement Transport Layer Security (TLS) Protocol Version 1.2 based

on RFC 5246■ Solution:

–System SSL has been updated to support the TLS V1.2 protocol–Addition of 37 new cipher suites for use in SSL sessions. –Available in z/OS V1.13 APAR OA39422 (PTFs UA66870,UA66871,

and UA66872)■ Benefit:

–Allows customers to use the latest defined SSL security protocol–Augments end to end encryption for data in flight by helping to maintain

data privacy and prevent data leakage of sensitive information–Allows use of AES-GCM symmetric encryption algorithm




Overview - TLS V1.2

■ Benefit (continued)–Allows use of SHA-256 and SHA-384 for message authentication–Removes dependency on MD5 and SHA-1–Pre-requisite for implementing Suite-B security profile




Overview - TLS V1.2

■ TLS V1.2 introduces the following changes to the protocol

– MD5/SHA-1 Pseudo Random Function (PRF) has been replaced with cipher suite specified PRF’s. The default PRF used for TLS V1.2 uses SHA-256 based PRF.

– Allows for SHA-256 and SHA-384 to be used for the message authentication

– Provide a method for client’s and server’s to specify which hash and signature algorithms they will accept.

– DES (56-bit) and RC2/RC4 (export) suites are not supported.

– RFC 5288 AES Galois Counter Mode (GCM) Cipher Suites for TLS

– RFC 5289 TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)




Usage & Invocation - TLS V1.2

■ Customers must enable the TLS V1.2 protocol for use. This can be done either by:

–Setting the environment variable to 1, ON, or ENABLED• export GSK_PROTOCOL_TLSV1_2=ON

–Using gsk_attribute_set_enum() API• Can either be specified at the TLS environment level or at the

connection level• rc = gsk_attribute_set_enum(env, GSK_PROTOCOL_TLSV1_2,

GSK_PROTOCOL_TLSV1_2_ON);■ Notes:

–Using gsk_attribute_set_enum() API will override the environment variable setting

–If not specified or set to OFF, TLS V1.2 will not be negotiated.–Deprecated APIs do not support the TLS V1.2 protocol.





■ Customers can query the state of the TLS V1.2 enum setting by using the gsk_attribute_get_enum() API

–rc = gsk_attribute_get_enum(conHandle, GSK_PROTOCOL_TLSV1_2, &tlsProtocol);

■ Customers can also query whether the TLS V1.2 protocol is being used for the newly established connection:

–rc = gsk_attribute_get_enum(conHandle, GSK_PROTOCOL_USED, &protocolUsed)




Usage & Invocation - TLS V1.2 ■ TLS V1.2 RSA, Diffie Hellman ciphers

– NULL• 003B – TLS_RSA_WITH_NULL_SHA256

– AES-CBC• 003C – TLS_RSA_WITH_AES_128_CBC_SHA256• 003D – TLS_RSA_WITH_AES_256_CBC_SHA256• 003E – TLS_DH_DSS_WITH_AES_128_CBC_SHA256• 003F – TLS_DH_RSA_WITH_AES_128_CBC_SHA256• 0040 – TLS_DHE_DSS_WITH_AES_128_CBC_SHA256• 0067 – TLS_DHE_RSA_WITH_AES_128_CBC_SHA256• 0068 – TLS_DH_DSS_WITH_AES_256_CBC_SHA256• 0069 – TLS_DH_RSA_WITH_AES_256_CBC_SHA256• 006A – TLS_DHE_DSS_WITH_AES_256_CBC_SHA256• 006B – TLS_DHE_RSA_WITH_AES_256_CBC_SHA256




Usage & Invocation - TLS V1.2 ■ TLS V1.2 RSA, Diffie Hellman ciphers (continued)

– AES-GCM• 009C – TLS_RSA_WITH_AES_128_GCM_SHA256• 009D – TLS_RSA_WITH_AES_256_GCM_SHA384• 009E – TLS_DHE_RSA_WITH_AES_128_GCM_SHA256• 009F – TLS_DHE_RSA_WITH_AES_256_GCM_SHA384• 00A0 – TLS_DH_RSA_WITH_AES_128_GCM_SHA256• 00A1 – TLS_DH_RSA_WITH_AES_256_GCM_SHA384• 00A2 – TLS_DHE_DSS_WITH_AES_128_GCM_SHA256• 00A3 – TLS_DHE_DSS_WITH_AES_256_GCM_SHA384• 00A4 – TLS_DH_DSS_WITH_AES_128_GCM_SHA256• 00A5 – TLS_DH_DSS_WITH_AES_256_GCM_SHA384




Usage & Invocation - TLS V1.2 ■ New ciphers to specify the usage of SHA-256 and SHA-384 hashing with an

elliptic curve key exchange

– AES-CBC symmetric algorithm• C023 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256• C024 - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384• C025 - TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 • C026 - TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384• C027 - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256• C028 - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 • C029 - TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 • C02A - TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384

– AES-GCM symmetric algorithm• C02B - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256• C02C - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384• C02D - TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 • C02E - TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384• C02F - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256• C030 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 • C031 - TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 • C032 - TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384





■ TLS V1.2 defines a new TLS handshake extension - “Signature Algorithms”

■ Client can use this extension to indicate to the server which hash/signature algorithm pairs may be used in digital signatures

■ The extension contains an enumerated list in descending order of preference of hash/signature algorithm combinations that the client supports

■ Enumerated Hash Algorithms – Numeric Value in parenthesis–None (0), MD5 (1), SHA (2), SHA224 (3), SHA256(4), SHA384 (5),

SHA512 (6)• Note: None is not supported by System SSL

■ Enumerated Signature Algorithms – Numeric value in parenthesis–Anonymous (0), RSA (1), DSA (2), ECDSA (3)

• Note: Anonymous is not supported by System SSL




Usage & Invocation - TLS V1.2 ■ The hash algorithm and signature algorithm enumerations are combined

together to make hash/signature algorithm pair.


Algorithm Enumerated Value (hash and signature algorithm pair)

MD-5 with RSASHA-1 with RSASHA-224 with RSASHA-256 with RSASHA-384 with RSASHA-512 with RSASHA-1 with DSASHA-224 with DSASHA-256 with DSASHA-1 with ECDSASHA-224 with ECDSASHA-256 with ECDSASHA-384 with ECDSASHA-512 with ECDSA

0101 0201 0301 0401 0501 0601 0202 0302 (Not supported in V1.13) 0402 (Not supported in V1.13) 0203 0303 0403 0503 0603




■ The server uses the signature algorithm pairs it receives from the client to perform additional processing during a TLS V1.2 handshake

■ If the server certificate’s key is to be used for generating a digital signature the key algorithm must be present in at least one of the hash/signature algorithm pairs

■ The signatures of each certificate in the server certificate chain that is exchanged during the handshake must be present in the hash/signature algorithm pair list.

■ The servers cipher suite list can only contain ciphers that use a key algorithm present in the clients list of hash/signature algorithm pairs.

■ The first hash/signature algorithm pair in the list that matches the key of the server certificate is used by the server to generate digital signatures during the handshake




Usage & Invocation - TLS V1.2 ■ The client uses the signature algorithm pairs it receives from the server to

perform additional processing during a TLS V1.2 handshake■ If the client certificate’s key is to be used for generating a digital signature

the key algorithm must be present in at least one of the hash/signature algorithm pairs

■ The signatures of each certificate in the client certificate chain sent must be present in the hash/signature algorithm pair list.

■ The first hash/signature algorithm pair in the list that matches the key of the client certificate is used by the client to generate digital signatures during the handshake





■ Customers can specify the supported signature algorithm . This can be done either by:

–Setting the environment variable• export GSK_TLS_SIG_ALG_PAIRS=0201

–Using gsk_attribute_set_buffer() API• Can either be specified at the TLS environment level or at the

connection level• rc = gsk_attribute_set_buffer(env, GSK_TLS_SIG_ALG_PAIRS,

“0201”);■ Notes:

–Default signature algorithm list - 0601 0603 0501 0503 0401 0403 0402 0301 0303 0302 0201 0203 0202 0101

• Note: 0302 and 0402 are not supported in V1R13–Using gsk_attribute_set_buffer() API will override the environment

variable setting




Interactions & Dependencies - TLS V1.2 ■ Hardware Dependencies

– None

■ Software Dependencies– Requires ICSF HCR77A0 or higher be installed – System SSL calls ICSF PKCS # 11 callable services for AES-GCM encrypt / decrypt

functions– ICSF controls access to the cryptographic services through the CSFSERV resource

class. Access is needed to the CSF1SKE, CSF1SKD, CSF1TRC, and CSF1TRD resources.

– ICSF will determine whether to utilize CPACF hardware to perform AES-GCM encrypt / decrypt functions

■ Exploiters– Communication Server's Application Transparent/TLS– Any z/OS System SSL applications wanting to exploit the TLS V1.2 protocol




Migration & Coexistence Considerations - TLS V1.2

■ Toleration APAR available for V1R12 to handle session resumption of SSL sessions from the SYSPLEX session ID cache which use an unsupported TLS protocol version.

■ APAR OA37102 Alters System SSL so that in a SYSPLEX where SYSPLEX session ID caching is enabled, an attempt to resume a SSL session using a unsupported TLS protocol will force a full re-handshake to occur

– V1R12 PTFs – UA66806 and UA66807– Notes:

• APAR OA39422 has this support built into it for z/OS V1R13

■ TLS V1.2 sessions created on a z/OS V1R13 or z/OS V2R1 system cannot be resumed on V1R12 and a full re-handshake will be forced.




Overview – Suite B■ Problem Statement / Need Addressed:

–Suite B cryptography for TLS V1.2 defines a set of profiles that specify what cryptographic algorithms may be used for key establishment, authentication, and encryption.

■ Solution:–System SSL will add functionality to support Suite B compliant profile

sessions.■ Benefit:

–Customers are able to configure System SSL to restrict the cryptographic algorithms in use to those that comply with Suite B profiles.

–Support for RFC 5430 in Full Compliant Mode




Overview – Suite B■ Suite B support in System SSL was implemented at the SSL environment level.

All connections within the environment must conform to Suite B requirements.

■ Suite B has defined two profiles. One supporting 128-bit and another 192-bit.

■ When Suite B for TLS is specified, the following restrictions are enforced:– TLS V1.2 protocol – Symmetric algorithm used by the handshake and application payload is AES-

CBC 256-bit or AES-GCM based– Secure connection negotiated with ECDH key exchange– Certificates used during the handshake are signed with ECDSA – Elliptical curves allowed are P-256 and P-384 curves– Restrict the client’s and server’s ability to specify which hash and signature

algorithms they will accept. ■ System SSL only supports the compliant profiles. No support for transitional

mode.




Usage & Invocation – Suite B

■ Suite B 128-bit Profile–The 128 bit profile corresponds to:

• Elliptical Curve Size of 256 bits (secp256r1)• Encryption using AES 128• SHA 256 as the hash algorithm

–Cipher Suites:• C02B - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 • C023 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

–Signature Algorithm• SHA-256 with ECDSA - ’0403’





■ Suite B 192-bit Profile–The 192 bit profile corresponds to:

• Elliptical Curve Size of 384 bits (secp384r1)• Encryption using AES 256• SHA 384 as the hash algorithm

–Cipher Suites:• C02C - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 • C024 -TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

–Signature Algorithm• SHA-384 with ECDSA - ’0503’





■ Customer applications must enable Suite B Profile. This can be done either by:

–Setting the environment variable GSK_SUITE_B_PROFILE to one of the following values:

• OFF (default)• 128• 192• ALL

• Example:–export GSK_SUITE_B_PROFILE=128

–OR ...




Usage & Invocation – Suite B■ Using gsk_attribute_set_enum() API

– Can be specified at the TLS environment level only– GSK_ENUM ID is GSK_SUITE_B_PROFILE– Valid GSK_ENUM_VALUE values are:

• GSK_SUITE_B_PROFILE_OFF• GSK_SUITE_B_PROFILE_128• GSK_SUITE_B_PROFILE_192• GSK_SUITE_B_PROFILE_ALL

– Example:• rc = gsk_attribute_set_enum(env, GSK_SUITE_B_PROFILE,

GSK_SUITE_B_PROFILE_128);

■ Notes: – Using gsk_attribute_set_enum() API will override the environment variable

setting– If not specified or set to OFF, Suite B will not be enforced– Deprecated APIs do not support Suite B




Interactions & Dependencies – Suite B

■ Hardware Dependencies– None

■ Software Dependencies– Requires ICSF HCR77A0 or higher be installed– System SSL calls ICSF PKCS # 11 callable services to perform AES-GCM encrypt /

decrypt and Elliptic Curve functions– ICSF controls access to the cryptographic services through the CSFSERV resource

class. Access is needed to the CSF1SKE, CSF1SKD, CSF1GKP, CSF1GAV, CSF1TRD, CSF1TRC, CSF1PKS, CSF1PKV and CSF1DVK resources

– ICSF will determine whether to utilize CPACF hardware to perform AES-GCM encrypt / decrypt functions

■ Exploiters– Communication Server's Application Transparent/TLS– Any z/OS System SSL applications wanting to exploit the TLS V1.2 protocol and Suite B




Overview - RFC 5280 Certificate Validation

■ Problem Statement / Need Addressed:– Enhanced SSL certificate validation is needed to support RFC 5280– Need ability to perform certificate validation to the root CA certificate when

certificates reside in a SAF key ring– Need support for more secure DSA keys

■ Solution:– Enhanced certificate validation to

• Support certificates and certificate validation as defined by RFC 5280• Allow end-user to configure how certificate validation to the root CA

certificate occurs– Added support for DSA 2048-bit keys

■ Benefit:– Customers will be able to use industry standard specifications for certificate

validation– Exploit features provided through the new certificates– Continue to support certificates defined by RFCs 2459 and 3280




Overview - RFC 5280 Certificate Validation

■ Benefit (continued)– Certificates in SAF key rings can be validated just like certificates that reside in

a PKCS#11 token or key database file– DSA 2048-bit keys provide more secure connections




Overview - RFC 5280 Certificate Validation■ Using the RFC 5280 Certificate validation, the customer can:

– Utilize certificates following the standard defined in RFC 5280– Control level of certificate validation

■ Value: – Customers are able to specify a more current and secure validation mode

• 2459 Only -- Existing• 2459, 3280, and 5280• 3280 Only -- Existing• 5280 Only -- New

– Enhanced support for certificate and CRL extensions to provide a more secure X.509 environment. Added internationalization support when validating certificate chains

■ Enhance certificate validation for certificates that reside in a SAF key ring. The customer can:

– Validate to the trust anchor certificate – Existing (Default)– Validate to the root CA certificate – New




Usage & Invocation - RFC 5280 Certificate Validation

■ There are now 4 possible certificate validation modes:

–GSK_CERT_VALIDATION_MODE_ANY – validate according to RFC 2459, if that fails validate according RFC 3280, and if that fails validate according to RFC 5280

–GSK_CERT_VALIDATION_MODE_2459 – validate according to RFC 2459

–GSK_CERT_VALIDATION_MODE_3280 – validate according to RFC 3280

–GSK_CERT_VALIDATION_MODE_5280 – validate according to RFC 5280 (NEW)





■ The validation mode can be set through:

–gsk_attribute_set_enum() API–environment variable GSK_CERT_VALIDATION_MODE–or on the validatation_mode parameter on the

gsk_validate_certificate_mode() API call

■ Notes:

–Certificate and CRL validation mode defaults to the validation mode ANY

–Deprecated APIs can exploit through environment variables.





■ For SSL/TLS exploiters, certificate validation mode can be defined by:

–Setting environment variable• export GSK_CERT_VALIDATION_MODE=5280, 3280, 2459 or

ANY –Using gsk_attribute_set_enum() (SSL environment level only)

• rc = gsk_attribute_set_enum (env, GSK_CERT_VALIDATION_MODE,GSK_CERT_VALIDATION_MODE_5280);or GSK_CERT_VALIDATION_MODE_3280);orGSK_CERT_VALIDATION_MODE_2459);or GSK_CERT_VALIDATION_MODE_ANY);

–Using validation_mode parameter on gsk_validate_certificate_mode()





■ SAF Key ring certificate chain validation behavior can be set through:

–gsk_attribute_set_enum() API–New environment variable

GSK_CERT_VALIDATE_KEYRING_ROOT–or on the new validate_root parameter on the

gsk_validate_certificate_mode() API call

■ Notes:

–Has no effect on certificate validation with certificates in key database files or PKCS #11 Tokens (validation always done to root).

–Only applies at the SSL environment level – not just at the SSL connection level


notes:///Has



Usage & Invocation - RFC 5280 Certificate Validation■ SAF Key ring certificate chain validation behavior can be set through:

–Setting environment variable• export GSK_CERT_VALIDATE_KEYRING_ROOT=ON or OFF• ON (1) – Validate SAF key ring certificates to the root CA• OFF (0) – Validate SAF key ring certificates to the intermediate

trust anchor (Default – same as today)

–Using gsk_attribute_set_enum() (SSL environment level only)• rc = gsk_attribute_set_enum (env,

GSK_CERT_VALIDATE_KEYRING_ROOT,GSK_CERT_VALIDATE_KEYRING_ROOT_ON);or GSK_CERT_VALIDATE_KEYRING_ROOT_OFF);





■ For CMS exploiters, use gsk_validate_certificate_mode()gsk_status gsk_validate_certificate_mode ( gskdb_data_sources * data_sources, x509_certificate * subject_certificate, gsk_boolean accept_root, gsk_int32 * issuer_record_id, GSKCMS_CERT_VALIDATION_MODE validation_mode, gsk_uint32 arg_count, [GSKCMS_CERT_VALIDATE_KEYRING_ROOT validate_root,] ...)

■ The existing validation_mode parameter can be set to:

–GSKCMS_CERT_VALIDATION_MODE_5280 -- NEW–GSKCMS_CERT_VALIDATION_MODE_3280–GSKCMS_CERT_VALIDATION_MODE_2459–GSKCMS_CERT_VALIDATION_MODE_ANY





■ arg_count parameter on the gsk_validate_certificate_mode() API must be set to 1 when validate_root is specified (previously only could be set to 0)

■ validate_root can be:–GSKCMS_CERT_VALIDATE_KEYRING_ROOT_ON–GSKCMS_CERT_VALIDATE_KEYRING_ROOT_OFF




Usage & Invocation - RFC 5280 Certificate Validation■ Certificate Management Services (CMS) APIs updated to support the

creation of DSA 2048 bit keys certificate authority and user/server certificates, and the usage of DSA 2048 bit keys.

■ Updated CMS APIs:


● gsk_construct_certificate● gsk_construct_renewal_request● gsk_construct_self_signed_certificate● gsk_construct_signed_certificate● gsk_create_certification_request● gsk_create_database_renewal_request● gsk_create_database_signed_certificate● gsk_create_self_signed_certificate● gsk_create_signed_certificate● gsk_create_signed_certificate_record● gsk_create_signed_certificate_set● gsk_create_signed_crl_record

● gsk_generate_key_pair● gsk_generate_key_parameters

● gsk_make_signed_data_content● gsk_make_signed_data_content_extended● gsk_make_signed_data_msg● gsk_make_signed_data_msg_extended● gsk_read_signed_data_content● gsk_read_signed_data_content_extended● gsk_read_signed_data_msg● gsk_read_signed_data_msg_extended

● gsk_sign_certificate● gsk_sign_crl● gsk_sign_data● gsk_verify_certificate_signature● gsk_verify_crl_signature● gsk_verify_data_signature




■ gskkyman has been updated to support creation and management of CA and end entity DSA 2048-bit certificates


Old menus New menusCertificate Type

1 - CA certificate with 1024-bit RSA key 2 - CA certificate with 2048-bit RSA key 3 - CA certificate with 4096-bit RSA key 4 - CA certificate with 1024-bit DSA key 5 - User or server certificate with 1024-bit RSA key 6 - User or server certificate with 2048-bit RSA key 7 - User or server certificate with 4096-bit RSA key 8 - User or server certificate with 1024-bit DSA key 9 - CA certificate with an ECC key 10 - User or server certificate with an ECC key

Select certificate type (press ENTER to return to menu): 4

Certificate Usage

1 - CA certificate 2 - User or server certificate

Select certificate usage (press ENTER to return to menu): 1

Certificate Key Algorithm

1 - Certificate with an RSA key 2 - Certificate with a DSA key 3 - Certificate with an ECC key

Select certificate key algorithm (press ENTER to return to menu): 2

DSA Key Size

1 - 1024-bit key 2 - 2048-bit key

Select DSA key size (press ENTER to return to menu): 2

Signature Digest Type

1 - SHA-224 2 - SHA-256

Select Digest Type (press ENTER to return to menu): 2




■ gskkyman utility:

–Remains a clear key certificate management utility.

–A PKCS #11 token certificate with a clear private key is allowed full gskkyman functionality.

–The gskkyman utility provides only limited functionality for PKCS #11 token certificates that have secure private keys. If a PKCS #11 certificate has a secure private key the following functions are allowed:

• Showing certificate and key information • Setting the key as default• Exporting a certificate to a file• Deleting a certificate and key• Changing the label





–If a PKCS #11 token certificate has a secure private key then the following functions are NOT permitted:

• Copying certificate and key to another token• Exporting certificate and key to a file• Creating a signed certificate and key• Creating a certificate renewal request

–When displaying Token Key Information for a PKCS #11 certificate's private key, the Private key type will indicate if the private key is either Clear or Secure.




Interactions & Dependencies - RFC 5280 Certificate Validation

■ Hardware Dependencies–None

■ Software Dependencies–None

■ Exploiters–Any z/OS System SSL application using RFC 5280 certificates or

certificates that reside in a SAF key ring




Migration & Coexistence Considerations - RFC 5280 Certificate Validation■ gskkyman

– When running the gskkyman program in interactive mode, a series of menus guide you through various tasks, prompting you for each piece of information required to complete the task. In z/OS V2R1, some of the existing gskkyman menus have been refined to make the tasks simpler and more intuitive for the user to perform.

– Installations/products that have created automated scripts to interact with the gskkyman menus will need to modify these scripts to work with the new menus.

– Documentation that describes the gskkyman menus is updated to describe the new menus.




Overview - General updates

■ General System SSL release updates:– ICSF is now required to be up and running before executing System SSL

applications in FIPS mode• Will use random number generation and Diffie-Hellman functions from ICSF

in this environment

– If a System SSL application is executing in non-FIPS mode and ICSF is available, ICSF will be used for random number generation. If ICSF is not available, random number generation will continue to be performed in System SSL's software.




Interactions & Dependencies - General updates

■ Hardware Dependencies– None

■ Software Dependencies– Requires ICSF HCR77A0 or higher be installed

– System SSL calls ICSF PKCS # 11 callable services for random number generation and Diffie-Hellman

– ICSF controls access to the cryptographic services through the CSFSERV resource class. Access is needed to the CSFRNG, CSF1GKP, CSF1GAV, CSFPGSK, CSF1TRD, CSF1TRC and CSF1DVK resources




Migration & Coexistence Considerations - General updates

1) CSFSERV resource when running in non-FIPS mode

– When it is running a System SSL application in non-FIPS mode (default mode), System SSL will still attempt to exploit ICSF's random number generation. ICSF's random number generation will allow the application to take advantage of the ICSF software or the Crypto Express3 cards for generating random data.

– If CSFSERV class is defined and if the user ID that starts the SSL application cannot access the CSFRNG resource of the CSFSERV class, System SSL will not be able to use ICSF and the informational message ICH408I (which indicates insufficient authorization) may be issued to the console.

– System SSL processing will continue, your application will be using System SSL's random number generation support.

– Action: Permit application user's to the CSFRNG resource




Migration & Coexistence Considerations - General updates

2) System SSL when running in FIPS mode will require and exploit ICSF's random number generation and Diffie-Hellman support.

– Before running the System SSL application in FIPS mode you must ensure that ICSF is running

– If CSFSERV class is defined, all user IDs that start SSL applications in FIPS mode, invoke the gskkyman utility to manage FIPS key database files, or invoke the GSKSRVR started task in FIPS mode must have access to certain CSFSERV classes.

– When exploiting Diffie-Hellman Support• CSF1TRC, CSF1DVK, CSF1GKP, CSF1GSK, CSF1GAV, CSF1TRD

– APAR OA40816 on z/OS V1R12 and z/OS V1R13 assists with helping to find SSL applications running in FIPS mode without ICSF available




Presentation Summary■ You should now be able to:

–Understand the recent changes in System SSL (TLS V1.2, Suite B, crypto algorithms, certificate validation, and general updates)

–Understand the migration changes (new dependencies on ICSF and gskkyman menu changes)

–Be able to find any of the above information in the relevant publication(s)




Appendix

■ Publications–z/OS Cryptographic Services System Secure Sockets Layer (SC14-

7495)■ Specifications:

–RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2 - http://datatracker.ietf.org/doc/rfc5246/

–RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile – http://datatracker.ietf.org/doc/rfc5280/

–RFC 5288, AES Galois Counter Mode (GCM) Cipher Suites for TLS - http://datatracker.ietf.org/doc/rfc5288

–RFC 5289, TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM) - http://datatracker.ietf.org/doc/rfc5289/

–RFC 5430, Suite B Profile for Transport Layer Security (TLS) - http://datatracker.ietf.org/doc/rfc5430/


http://datatracker.ietf.org/doc/rfc5246/





ibm education assistance for z/os v2r1 · gsk_protocol_tlsv1_2, &tlsprotocol); ... session id...

Documents