IBM Security Z Security

Greetings all,
I have recently set up CKNSERVE across two systems, following the standard instructions.

I have seen that CKNSERVE is issuing these messages,

ICH408I USER(CKNSRV  ) GROUP(CKN     ) NAME(CKNSERVE        
  CSF-PKDS-DEFAULT CL(CSFKEYS )                             
  INSUFFICIENT ACCESS AUTHORITY                             
  ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )           
I think these often appear in groups of three messages.

The XFACILIT profile CSF.PKDS.TOKEN.CHECK.DEFAULT.LABEL has been defined, so the check against CSF-PKDS-DEFAULT should be made whenever a PKDS token is used which is not from the PKDS. I have not granted the necessary access and yet I think all is working well.

Have I missed something in the set up? Should I grant the access?

Lennie Dymoke-Bradshaw

------------------------------
Lennie Dymoke-Bradshaw
------------------------------

I have had no reply from anyone on this subject in nearly 2 months. 
Does no one else run with ICSF key store policy definitions for asymmetric keys outside of the PKDS? 

Lennie

Greetings all,
I have recently set up CKNSERVE across two systems, following the standard instructions.

I have seen that CKNSERVE is issuing these messages,

ICH408I USER(CKNSRV  ) GROUP(CKN     ) NAME(CKNSERVE        
  CSF-PKDS-DEFAULT CL(CSFKEYS )                             
  INSUFFICIENT ACCESS AUTHORITY                             
  ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )           
I think these often appear in groups of three messages.

The XFACILIT profile CSF.PKDS.TOKEN.CHECK.DEFAULT.LABEL has been defined, so the check against CSF-PKDS-DEFAULT should be made whenever a PKDS token is used which is not from the PKDS. I have not granted the necessary access and yet I think all is working well.

Have I missed something in the set up? Should I grant the access?

Lennie Dymoke-Bradshaw

------------------------------
Lennie Dymoke-Bradshaw
------------------------------

Hi Lennie,

Does a discrete XFACILIT profile CSF.PKDS.TOKEN.CHECK.LABEL.WARN perhaps exist in your security databases?
That could explain why all appears to be working well despite CKNSRV lacking access to CSF-PKDS-DEFAULT.

I am not quite sure whether CKNSRV should be given READ access to CSFKEYS CSF-PKDS-DEFAULT,
having no experience with implementing ICSF key store policies.
Also, the Installation and Deployment Guide makes no direct mention of the resource.

The Cryptographic Services Integrated Cryptographic Service Facility Administrator's Guide on the other hand
suggests that if CSF.PKDS.TOKEN.CHECK.LABEL.WARN exists,
"you can, by examining the SMF type 82 subtype 25 records logged in the SMF data set, identify the users who need permission to access keys."

After giving these users the permissions they require and you are
"ready to move to a stricter implementation of this [key store] policy",
"you enable the controls for fail mode and disable the ones for warning mode."

Regards,

I have had no reply from anyone on this subject in nearly 2 months. 
Does no one else run with ICSF key store policy definitions for asymmetric keys outside of the PKDS? 

Lennie

Greetings all,
I have recently set up CKNSERVE across two systems, following the standard instructions.

I have seen that CKNSERVE is issuing these messages,

ICH408I USER(CKNSRV  ) GROUP(CKN     ) NAME(CKNSERVE        
  CSF-PKDS-DEFAULT CL(CSFKEYS )                             
  INSUFFICIENT ACCESS AUTHORITY                             
  ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )           
I think these often appear in groups of three messages.

The XFACILIT profile CSF.PKDS.TOKEN.CHECK.DEFAULT.LABEL has been defined, so the check against CSF-PKDS-DEFAULT should be made whenever a PKDS token is used which is not from the PKDS. I have not granted the necessary access and yet I think all is working well.

Have I missed something in the set up? Should I grant the access?

Lennie Dymoke-Bradshaw

------------------------------
Lennie Dymoke-Bradshaw
------------------------------

Luc,

Many thanks for replying. I thought this query had vanished down a bit-bucket somewhere :-)
Your speculation that a profile of CSF.PKDS.TOKEN.CHECK.LABEL.WARN might exist is one of the things I first looked at. However, this is a list of the XFACILIT profiles matching CSF.** 

As you can see the .WARN profile does not exists and the profile CSF.PKDS.TOKEN.CHECK.DEFAULT.FAIL does exist.
One update on my original post is that I have realised the message is being issued from the TCP/IP address space rather than the CKNSERVE address space. I suspect it is related to AT/TLS, but I have not seen this from AT/TLS elsewhere. 

As you say there does not appear to be anything about this is in the Installation and Deployment Guide. But I wonder if CKNSERVE has been tested with the key store policies in place.

Regards,
Lennie Dymoke-Bradshaw

Hi Lennie,

Does a discrete XFACILIT profile CSF.PKDS.TOKEN.CHECK.LABEL.WARN perhaps exist in your security databases?
That could explain why all appears to be working well despite CKNSRV lacking access to CSF-PKDS-DEFAULT.

I am not quite sure whether CKNSRV should be given READ access to CSFKEYS CSF-PKDS-DEFAULT,
having no experience with implementing ICSF key store policies.
Also, the Installation and Deployment Guide makes no direct mention of the resource.

The Cryptographic Services Integrated Cryptographic Service Facility Administrator's Guide on the other hand
suggests that if CSF.PKDS.TOKEN.CHECK.LABEL.WARN exists,
"you can, by examining the SMF type 82 subtype 25 records logged in the SMF data set, identify the users who need permission to access keys."

After giving these users the permissions they require and you are
"ready to move to a stricter implementation of this [key store] policy",
"you enable the controls for fail mode and disable the ones for warning mode."

Regards,

I have had no reply from anyone on this subject in nearly 2 months. 
Does no one else run with ICSF key store policy definitions for asymmetric keys outside of the PKDS? 

Lennie

Greetings all,
I have recently set up CKNSERVE across two systems, following the standard instructions.

I have seen that CKNSERVE is issuing these messages,

ICH408I USER(CKNSRV  ) GROUP(CKN     ) NAME(CKNSERVE        
  CSF-PKDS-DEFAULT CL(CSFKEYS )                             
  INSUFFICIENT ACCESS AUTHORITY                             
  ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )           
I think these often appear in groups of three messages.

The XFACILIT profile CSF.PKDS.TOKEN.CHECK.DEFAULT.LABEL has been defined, so the check against CSF-PKDS-DEFAULT should be made whenever a PKDS token is used which is not from the PKDS. I have not granted the necessary access and yet I think all is working well.

Have I missed something in the set up? Should I grant the access?

Lennie Dymoke-Bradshaw

------------------------------
Lennie Dymoke-Bradshaw
------------------------------

Hi Lennie,

In the zSecure Server design and development documents, I have found no descriptions of tests with specific AT-TLS policies or key store policy controls.

Regards,

Luc,

Many thanks for replying. I thought this query had vanished down a bit-bucket somewhere :-)
Your speculation that a profile of CSF.PKDS.TOKEN.CHECK.LABEL.WARN might exist is one of the things I first looked at. However, this is a list of the XFACILIT profiles matching CSF.** 

As you can see the .WARN profile does not exists and the profile CSF.PKDS.TOKEN.CHECK.DEFAULT.FAIL does exist.
One update on my original post is that I have realised the message is being issued from the TCP/IP address space rather than the CKNSERVE address space. I suspect it is related to AT/TLS, but I have not seen this from AT/TLS elsewhere. 

As you say there does not appear to be anything about this is in the Installation and Deployment Guide. But I wonder if CKNSERVE has been tested with the key store policies in place.

Regards,
Lennie Dymoke-Bradshaw

Hi Lennie,

Does a discrete XFACILIT profile CSF.PKDS.TOKEN.CHECK.LABEL.WARN perhaps exist in your security databases?
That could explain why all appears to be working well despite CKNSRV lacking access to CSF-PKDS-DEFAULT.

I am not quite sure whether CKNSRV should be given READ access to CSFKEYS CSF-PKDS-DEFAULT,
having no experience with implementing ICSF key store policies.
Also, the Installation and Deployment Guide makes no direct mention of the resource.

The Cryptographic Services Integrated Cryptographic Service Facility Administrator's Guide on the other hand
suggests that if CSF.PKDS.TOKEN.CHECK.LABEL.WARN exists,
"you can, by examining the SMF type 82 subtype 25 records logged in the SMF data set, identify the users who need permission to access keys."

After giving these users the permissions they require and you are
"ready to move to a stricter implementation of this [key store] policy",
"you enable the controls for fail mode and disable the ones for warning mode."

Regards,

I have had no reply from anyone on this subject in nearly 2 months. 
Does no one else run with ICSF key store policy definitions for asymmetric keys outside of the PKDS? 

Lennie

Greetings all,
I have recently set up CKNSERVE across two systems, following the standard instructions.

I have seen that CKNSERVE is issuing these messages,

ICH408I USER(CKNSRV  ) GROUP(CKN     ) NAME(CKNSERVE        
  CSF-PKDS-DEFAULT CL(CSFKEYS )                             
  INSUFFICIENT ACCESS AUTHORITY                             
  ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )           
I think these often appear in groups of three messages.

The XFACILIT profile CSF.PKDS.TOKEN.CHECK.DEFAULT.LABEL has been defined, so the check against CSF-PKDS-DEFAULT should be made whenever a PKDS token is used which is not from the PKDS. I have not granted the necessary access and yet I think all is working well.

Have I missed something in the set up? Should I grant the access?

Lennie Dymoke-Bradshaw

------------------------------
Lennie Dymoke-Bradshaw
------------------------------

Luc,

The key store policy controls are not new. They have been around for a long time. I was part of the team that wrote the Redbook that covers this in 2011.
See SC24-7848 Chapter 5. (https://www.redbooks.ibm.com/abstracts/sg247848.html?Open )

It seems strange that there was no testing with such policies  in place. The AT-TLS policy for CKNSERVE is helpfully supplied in the installation materials.

Regards

Lennie

Hi Lennie,

In the zSecure Server design and development documents, I have found no descriptions of tests with specific AT-TLS policies or key store policy controls.

Regards,

Luc,

Many thanks for replying. I thought this query had vanished down a bit-bucket somewhere :-)
Your speculation that a profile of CSF.PKDS.TOKEN.CHECK.LABEL.WARN might exist is one of the things I first looked at. However, this is a list of the XFACILIT profiles matching CSF.** 

As you can see the .WARN profile does not exists and the profile CSF.PKDS.TOKEN.CHECK.DEFAULT.FAIL does exist.
One update on my original post is that I have realised the message is being issued from the TCP/IP address space rather than the CKNSERVE address space. I suspect it is related to AT/TLS, but I have not seen this from AT/TLS elsewhere. 

As you say there does not appear to be anything about this is in the Installation and Deployment Guide. But I wonder if CKNSERVE has been tested with the key store policies in place.

Regards,
Lennie Dymoke-Bradshaw

Hi Lennie,

Does a discrete XFACILIT profile CSF.PKDS.TOKEN.CHECK.LABEL.WARN perhaps exist in your security databases?
That could explain why all appears to be working well despite CKNSRV lacking access to CSF-PKDS-DEFAULT.

I am not quite sure whether CKNSRV should be given READ access to CSFKEYS CSF-PKDS-DEFAULT,
having no experience with implementing ICSF key store policies.
Also, the Installation and Deployment Guide makes no direct mention of the resource.

The Cryptographic Services Integrated Cryptographic Service Facility Administrator's Guide on the other hand
suggests that if CSF.PKDS.TOKEN.CHECK.LABEL.WARN exists,
"you can, by examining the SMF type 82 subtype 25 records logged in the SMF data set, identify the users who need permission to access keys."

After giving these users the permissions they require and you are
"ready to move to a stricter implementation of this [key store] policy",
"you enable the controls for fail mode and disable the ones for warning mode."

Regards,

I have had no reply from anyone on this subject in nearly 2 months. 
Does no one else run with ICSF key store policy definitions for asymmetric keys outside of the PKDS? 

Lennie

Greetings all,
I have recently set up CKNSERVE across two systems, following the standard instructions.

I have seen that CKNSERVE is issuing these messages,

ICH408I USER(CKNSRV  ) GROUP(CKN     ) NAME(CKNSERVE        
  CSF-PKDS-DEFAULT CL(CSFKEYS )                             
  INSUFFICIENT ACCESS AUTHORITY                             
  ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )           
I think these often appear in groups of three messages.

The XFACILIT profile CSF.PKDS.TOKEN.CHECK.DEFAULT.LABEL has been defined, so the check against CSF-PKDS-DEFAULT should be made whenever a PKDS token is used which is not from the PKDS. I have not granted the necessary access and yet I think all is working well.

Have I missed something in the set up? Should I grant the access?

Lennie Dymoke-Bradshaw

------------------------------
Lennie Dymoke-Bradshaw
------------------------------

Ok, let me throw in my 2 cents...

We tested with the keystore policies in place, but we didn't define CSF-PKDS-DEFAULT and we gave our started tasks access on the backstop profile :-)

Now that I added that extra CSFKEYS profile with access none, I also get the ICH408Is and CKNSERVE continues using the secured connection. I do agree that it's weird that after the violation, and using the FAIL policy, the process seems to happily continue. 

So, I tried without APF authorization: same result. I think that a chat with the AT-TLS people is needed.

Luc,

The key store policy controls are not new. They have been around for a long time. I was part of the team that wrote the Redbook that covers this in 2011.
See SC24-7848 Chapter 5. (https://www.redbooks.ibm.com/abstracts/sg247848.html?Open )

It seems strange that there was no testing with such policies  in place. The AT-TLS policy for CKNSERVE is helpfully supplied in the installation materials.

Regards

Lennie

Hi Lennie,

In the zSecure Server design and development documents, I have found no descriptions of tests with specific AT-TLS policies or key store policy controls.

Regards,

Luc,

Many thanks for replying. I thought this query had vanished down a bit-bucket somewhere :-)
Your speculation that a profile of CSF.PKDS.TOKEN.CHECK.LABEL.WARN might exist is one of the things I first looked at. However, this is a list of the XFACILIT profiles matching CSF.** 

As you can see the .WARN profile does not exists and the profile CSF.PKDS.TOKEN.CHECK.DEFAULT.FAIL does exist.
One update on my original post is that I have realised the message is being issued from the TCP/IP address space rather than the CKNSERVE address space. I suspect it is related to AT/TLS, but I have not seen this from AT/TLS elsewhere. 

As you say there does not appear to be anything about this is in the Installation and Deployment Guide. But I wonder if CKNSERVE has been tested with the key store policies in place.

Regards,
Lennie Dymoke-Bradshaw

Hi Lennie,

Does a discrete XFACILIT profile CSF.PKDS.TOKEN.CHECK.LABEL.WARN perhaps exist in your security databases?
That could explain why all appears to be working well despite CKNSRV lacking access to CSF-PKDS-DEFAULT.

I am not quite sure whether CKNSRV should be given READ access to CSFKEYS CSF-PKDS-DEFAULT,
having no experience with implementing ICSF key store policies.
Also, the Installation and Deployment Guide makes no direct mention of the resource.

The Cryptographic Services Integrated Cryptographic Service Facility Administrator's Guide on the other hand
suggests that if CSF.PKDS.TOKEN.CHECK.LABEL.WARN exists,
"you can, by examining the SMF type 82 subtype 25 records logged in the SMF data set, identify the users who need permission to access keys."

After giving these users the permissions they require and you are
"ready to move to a stricter implementation of this [key store] policy",
"you enable the controls for fail mode and disable the ones for warning mode."

Regards,

I have had no reply from anyone on this subject in nearly 2 months. 
Does no one else run with ICSF key store policy definitions for asymmetric keys outside of the PKDS? 

Lennie

Greetings all,
I have recently set up CKNSERVE across two systems, following the standard instructions.

I have seen that CKNSERVE is issuing these messages,

ICH408I USER(CKNSRV  ) GROUP(CKN     ) NAME(CKNSERVE        
  CSF-PKDS-DEFAULT CL(CSFKEYS )                             
  INSUFFICIENT ACCESS AUTHORITY                             
  ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )           
I think these often appear in groups of three messages.

The XFACILIT profile CSF.PKDS.TOKEN.CHECK.DEFAULT.LABEL has been defined, so the check against CSF-PKDS-DEFAULT should be made whenever a PKDS token is used which is not from the PKDS. I have not granted the necessary access and yet I think all is working well.

Have I missed something in the set up? Should I grant the access?

Lennie Dymoke-Bradshaw

------------------------------
Lennie Dymoke-Bradshaw
------------------------------

Ok, let me throw in my 2 cents...

We tested with the keystore policies in place, but we didn't define CSF-PKDS-DEFAULT and we gave our started tasks access on the backstop profile :-)

Now that I added that extra CSFKEYS profile with access none, I also get the ICH408Is and CKNSERVE continues using the secured connection. I do agree that it's weird that after the violation, and using the FAIL policy, the process seems to happily continue. 

So, I tried without APF authorization: same result. I think that a chat with the AT-TLS people is needed.

Luc,

The key store policy controls are not new. They have been around for a long time. I was part of the team that wrote the Redbook that covers this in 2011.
See SC24-7848 Chapter 5. (https://www.redbooks.ibm.com/abstracts/sg247848.html?Open )

It seems strange that there was no testing with such policies  in place. The AT-TLS policy for CKNSERVE is helpfully supplied in the installation materials.

Regards

Lennie

Hi Lennie,

In the zSecure Server design and development documents, I have found no descriptions of tests with specific AT-TLS policies or key store policy controls.

Regards,

Luc,

Many thanks for replying. I thought this query had vanished down a bit-bucket somewhere :-)
Your speculation that a profile of CSF.PKDS.TOKEN.CHECK.LABEL.WARN might exist is one of the things I first looked at. However, this is a list of the XFACILIT profiles matching CSF.** 

As you can see the .WARN profile does not exists and the profile CSF.PKDS.TOKEN.CHECK.DEFAULT.FAIL does exist.
One update on my original post is that I have realised the message is being issued from the TCP/IP address space rather than the CKNSERVE address space. I suspect it is related to AT/TLS, but I have not seen this from AT/TLS elsewhere. 

As you say there does not appear to be anything about this is in the Installation and Deployment Guide. But I wonder if CKNSERVE has been tested with the key store policies in place.

Regards,
Lennie Dymoke-Bradshaw

Hi Lennie,

Does a discrete XFACILIT profile CSF.PKDS.TOKEN.CHECK.LABEL.WARN perhaps exist in your security databases?
That could explain why all appears to be working well despite CKNSRV lacking access to CSF-PKDS-DEFAULT.

I am not quite sure whether CKNSRV should be given READ access to CSFKEYS CSF-PKDS-DEFAULT,
having no experience with implementing ICSF key store policies.
Also, the Installation and Deployment Guide makes no direct mention of the resource.

The Cryptographic Services Integrated Cryptographic Service Facility Administrator's Guide on the other hand
suggests that if CSF.PKDS.TOKEN.CHECK.LABEL.WARN exists,
"you can, by examining the SMF type 82 subtype 25 records logged in the SMF data set, identify the users who need permission to access keys."

After giving these users the permissions they require and you are
"ready to move to a stricter implementation of this [key store] policy",
"you enable the controls for fail mode and disable the ones for warning mode."

Regards,

I have had no reply from anyone on this subject in nearly 2 months. 
Does no one else run with ICSF key store policy definitions for asymmetric keys outside of the PKDS? 

Lennie

Greetings all,
I have recently set up CKNSERVE across two systems, following the standard instructions.

I have seen that CKNSERVE is issuing these messages,

ICH408I USER(CKNSRV  ) GROUP(CKN     ) NAME(CKNSERVE        
  CSF-PKDS-DEFAULT CL(CSFKEYS )                             
  INSUFFICIENT ACCESS AUTHORITY                             
  ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )           
I think these often appear in groups of three messages.

The XFACILIT profile CSF.PKDS.TOKEN.CHECK.DEFAULT.LABEL has been defined, so the check against CSF-PKDS-DEFAULT should be made whenever a PKDS token is used which is not from the PKDS. I have not granted the necessary access and yet I think all is working well.

Have I missed something in the set up? Should I grant the access?

Lennie Dymoke-Bradshaw

------------------------------
Lennie Dymoke-Bradshaw
------------------------------

Hey, the reply button works again!

I checked with the AT-TLS people, and they think it's an issue in System-SSL. AT-TLS doesn't do anything, except translate the policies into an action for System-SSL to handle. So, now looking at what System-SSL does with ICSF..... 

It seems that hardly anybody uses this particular combination.

Ok, let me throw in my 2 cents...

We tested with the keystore policies in place, but we didn't define CSF-PKDS-DEFAULT and we gave our started tasks access on the backstop profile :-)

Now that I added that extra CSFKEYS profile with access none, I also get the ICH408Is and CKNSERVE continues using the secured connection. I do agree that it's weird that after the violation, and using the FAIL policy, the process seems to happily continue. 

So, I tried without APF authorization: same result. I think that a chat with the AT-TLS people is needed.

Luc,

The key store policy controls are not new. They have been around for a long time. I was part of the team that wrote the Redbook that covers this in 2011.
See SC24-7848 Chapter 5. (https://www.redbooks.ibm.com/abstracts/sg247848.html?Open )

It seems strange that there was no testing with such policies  in place. The AT-TLS policy for CKNSERVE is helpfully supplied in the installation materials.

Regards

Lennie

Hi Lennie,

In the zSecure Server design and development documents, I have found no descriptions of tests with specific AT-TLS policies or key store policy controls.

Regards,

Luc,

Many thanks for replying. I thought this query had vanished down a bit-bucket somewhere :-)
Your speculation that a profile of CSF.PKDS.TOKEN.CHECK.LABEL.WARN might exist is one of the things I first looked at. However, this is a list of the XFACILIT profiles matching CSF.** 

As you can see the .WARN profile does not exists and the profile CSF.PKDS.TOKEN.CHECK.DEFAULT.FAIL does exist.
One update on my original post is that I have realised the message is being issued from the TCP/IP address space rather than the CKNSERVE address space. I suspect it is related to AT/TLS, but I have not seen this from AT/TLS elsewhere. 

As you say there does not appear to be anything about this is in the Installation and Deployment Guide. But I wonder if CKNSERVE has been tested with the key store policies in place.

Regards,
Lennie Dymoke-Bradshaw

Hi Lennie,

Does a discrete XFACILIT profile CSF.PKDS.TOKEN.CHECK.LABEL.WARN perhaps exist in your security databases?
That could explain why all appears to be working well despite CKNSRV lacking access to CSF-PKDS-DEFAULT.

I am not quite sure whether CKNSRV should be given READ access to CSFKEYS CSF-PKDS-DEFAULT,
having no experience with implementing ICSF key store policies.
Also, the Installation and Deployment Guide makes no direct mention of the resource.

The Cryptographic Services Integrated Cryptographic Service Facility Administrator's Guide on the other hand
suggests that if CSF.PKDS.TOKEN.CHECK.LABEL.WARN exists,
"you can, by examining the SMF type 82 subtype 25 records logged in the SMF data set, identify the users who need permission to access keys."

After giving these users the permissions they require and you are
"ready to move to a stricter implementation of this [key store] policy",
"you enable the controls for fail mode and disable the ones for warning mode."

Regards,

I have had no reply from anyone on this subject in nearly 2 months. 
Does no one else run with ICSF key store policy definitions for asymmetric keys outside of the PKDS? 

Lennie

Greetings all,
I have recently set up CKNSERVE across two systems, following the standard instructions.

I have seen that CKNSERVE is issuing these messages,

ICH408I USER(CKNSRV  ) GROUP(CKN     ) NAME(CKNSERVE        
  CSF-PKDS-DEFAULT CL(CSFKEYS )                             
  INSUFFICIENT ACCESS AUTHORITY                             
  ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )           
I think these often appear in groups of three messages.

The XFACILIT profile CSF.PKDS.TOKEN.CHECK.DEFAULT.LABEL has been defined, so the check against CSF-PKDS-DEFAULT should be made whenever a PKDS token is used which is not from the PKDS. I have not granted the necessary access and yet I think all is working well.

Have I missed something in the set up? Should I grant the access?

Lennie Dymoke-Bradshaw

------------------------------
Lennie Dymoke-Bradshaw
------------------------------

Yes, I couldn't get the Reply button to work yesterday, so I replied to the email.

Thanks for chasing up Guus.

Lennie (aka "Hardly anybody")

Hey, the reply button works again!

I checked with the AT-TLS people, and they think it's an issue in System-SSL. AT-TLS doesn't do anything, except translate the policies into an action for System-SSL to handle. So, now looking at what System-SSL does with ICSF..... 

It seems that hardly anybody uses this particular combination.

Ok, let me throw in my 2 cents...

We tested with the keystore policies in place, but we didn't define CSF-PKDS-DEFAULT and we gave our started tasks access on the backstop profile :-)

Now that I added that extra CSFKEYS profile with access none, I also get the ICH408Is and CKNSERVE continues using the secured connection. I do agree that it's weird that after the violation, and using the FAIL policy, the process seems to happily continue. 

So, I tried without APF authorization: same result. I think that a chat with the AT-TLS people is needed.

Luc,

The key store policy controls are not new. They have been around for a long time. I was part of the team that wrote the Redbook that covers this in 2011.
See SC24-7848 Chapter 5. (https://www.redbooks.ibm.com/abstracts/sg247848.html?Open )

It seems strange that there was no testing with such policies  in place. The AT-TLS policy for CKNSERVE is helpfully supplied in the installation materials.

Regards

Lennie

Hi Lennie,

In the zSecure Server design and development documents, I have found no descriptions of tests with specific AT-TLS policies or key store policy controls.

Regards,

Luc,

Many thanks for replying. I thought this query had vanished down a bit-bucket somewhere :-)
Your speculation that a profile of CSF.PKDS.TOKEN.CHECK.LABEL.WARN might exist is one of the things I first looked at. However, this is a list of the XFACILIT profiles matching CSF.** 

As you can see the .WARN profile does not exists and the profile CSF.PKDS.TOKEN.CHECK.DEFAULT.FAIL does exist.
One update on my original post is that I have realised the message is being issued from the TCP/IP address space rather than the CKNSERVE address space. I suspect it is related to AT/TLS, but I have not seen this from AT/TLS elsewhere. 

As you say there does not appear to be anything about this is in the Installation and Deployment Guide. But I wonder if CKNSERVE has been tested with the key store policies in place.

Regards,
Lennie Dymoke-Bradshaw

Hi Lennie,

Does a discrete XFACILIT profile CSF.PKDS.TOKEN.CHECK.LABEL.WARN perhaps exist in your security databases?
That could explain why all appears to be working well despite CKNSRV lacking access to CSF-PKDS-DEFAULT.

I am not quite sure whether CKNSRV should be given READ access to CSFKEYS CSF-PKDS-DEFAULT,
having no experience with implementing ICSF key store policies.
Also, the Installation and Deployment Guide makes no direct mention of the resource.

The Cryptographic Services Integrated Cryptographic Service Facility Administrator's Guide on the other hand
suggests that if CSF.PKDS.TOKEN.CHECK.LABEL.WARN exists,
"you can, by examining the SMF type 82 subtype 25 records logged in the SMF data set, identify the users who need permission to access keys."

After giving these users the permissions they require and you are
"ready to move to a stricter implementation of this [key store] policy",
"you enable the controls for fail mode and disable the ones for warning mode."

Regards,

I have had no reply from anyone on this subject in nearly 2 months. 
Does no one else run with ICSF key store policy definitions for asymmetric keys outside of the PKDS? 

Lennie

Greetings all,
I have recently set up CKNSERVE across two systems, following the standard instructions.

I have seen that CKNSERVE is issuing these messages,

ICH408I USER(CKNSRV  ) GROUP(CKN     ) NAME(CKNSERVE        
  CSF-PKDS-DEFAULT CL(CSFKEYS )                             
  INSUFFICIENT ACCESS AUTHORITY                             
  ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )           
I think these often appear in groups of three messages.

The XFACILIT profile CSF.PKDS.TOKEN.CHECK.DEFAULT.LABEL has been defined, so the check against CSF-PKDS-DEFAULT should be made whenever a PKDS token is used which is not from the PKDS. I have not granted the necessary access and yet I think all is working well.

Have I missed something in the set up? Should I grant the access?

Lennie Dymoke-Bradshaw

------------------------------
Lennie Dymoke-Bradshaw
------------------------------

Next station: System-SSL....
This is where we get off.

System-SSL does quite a few things, one of them is e.g. verify_certificate_signature 
Inside that check, they call CSNDDSV which gets the RC 8, Reason 3064  
Instead of failing the whole connection, System-SSL goes in the rebound, and calls an internal routine: rsa_verify_data_signature.
And that routine doesn't care about what's in the PKDS or not. It just does the job, and reports that the signature is ok.

So, if the "hardware" doesn't cooperate, System-SSL does it itself. Because the CSN* functions are called first, there will be a performance benefit by simply allowing the STC access to CSF-PKDS-DEFAULT.

Yes, I couldn't get the Reply button to work yesterday, so I replied to the email.

Thanks for chasing up Guus.

Lennie (aka "Hardly anybody")

Hey, the reply button works again!

I checked with the AT-TLS people, and they think it's an issue in System-SSL. AT-TLS doesn't do anything, except translate the policies into an action for System-SSL to handle. So, now looking at what System-SSL does with ICSF..... 

It seems that hardly anybody uses this particular combination.

Ok, let me throw in my 2 cents...

We tested with the keystore policies in place, but we didn't define CSF-PKDS-DEFAULT and we gave our started tasks access on the backstop profile :-)

Now that I added that extra CSFKEYS profile with access none, I also get the ICH408Is and CKNSERVE continues using the secured connection. I do agree that it's weird that after the violation, and using the FAIL policy, the process seems to happily continue. 

So, I tried without APF authorization: same result. I think that a chat with the AT-TLS people is needed.

Luc,

The key store policy controls are not new. They have been around for a long time. I was part of the team that wrote the Redbook that covers this in 2011.
See SC24-7848 Chapter 5. (https://www.redbooks.ibm.com/abstracts/sg247848.html?Open )

It seems strange that there was no testing with such policies  in place. The AT-TLS policy for CKNSERVE is helpfully supplied in the installation materials.

Regards

Lennie

Hi Lennie,

In the zSecure Server design and development documents, I have found no descriptions of tests with specific AT-TLS policies or key store policy controls.

Regards,

Luc,

Many thanks for replying. I thought this query had vanished down a bit-bucket somewhere :-)
Your speculation that a profile of CSF.PKDS.TOKEN.CHECK.LABEL.WARN might exist is one of the things I first looked at. However, this is a list of the XFACILIT profiles matching CSF.** 

As you can see the .WARN profile does not exists and the profile CSF.PKDS.TOKEN.CHECK.DEFAULT.FAIL does exist.
One update on my original post is that I have realised the message is being issued from the TCP/IP address space rather than the CKNSERVE address space. I suspect it is related to AT/TLS, but I have not seen this from AT/TLS elsewhere. 

As you say there does not appear to be anything about this is in the Installation and Deployment Guide. But I wonder if CKNSERVE has been tested with the key store policies in place.

Regards,
Lennie Dymoke-Bradshaw

Hi Lennie,

Does a discrete XFACILIT profile CSF.PKDS.TOKEN.CHECK.LABEL.WARN perhaps exist in your security databases?
That could explain why all appears to be working well despite CKNSRV lacking access to CSF-PKDS-DEFAULT.

I am not quite sure whether CKNSRV should be given READ access to CSFKEYS CSF-PKDS-DEFAULT,
having no experience with implementing ICSF key store policies.
Also, the Installation and Deployment Guide makes no direct mention of the resource.

The Cryptographic Services Integrated Cryptographic Service Facility Administrator's Guide on the other hand
suggests that if CSF.PKDS.TOKEN.CHECK.LABEL.WARN exists,
"you can, by examining the SMF type 82 subtype 25 records logged in the SMF data set, identify the users who need permission to access keys."

After giving these users the permissions they require and you are
"ready to move to a stricter implementation of this [key store] policy",
"you enable the controls for fail mode and disable the ones for warning mode."

Regards,

I have had no reply from anyone on this subject in nearly 2 months. 
Does no one else run with ICSF key store policy definitions for asymmetric keys outside of the PKDS? 

Lennie

Greetings all,
I have recently set up CKNSERVE across two systems, following the standard instructions.

I have seen that CKNSERVE is issuing these messages,

ICH408I USER(CKNSRV  ) GROUP(CKN     ) NAME(CKNSERVE        
  CSF-PKDS-DEFAULT CL(CSFKEYS )                             
  INSUFFICIENT ACCESS AUTHORITY                             
  ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )           
I think these often appear in groups of three messages.

The XFACILIT profile CSF.PKDS.TOKEN.CHECK.DEFAULT.LABEL has been defined, so the check against CSF-PKDS-DEFAULT should be made whenever a PKDS token is used which is not from the PKDS. I have not granted the necessary access and yet I think all is working well.

Have I missed something in the set up? Should I grant the access?

Lennie Dymoke-Bradshaw

------------------------------
Lennie Dymoke-Bradshaw
------------------------------

Guus,

Thanks for chasing this. I understand your comments.

My reaction? Wow! So mainline IBM code in System SSL invokes a function which a security department has decided they should not have access to, and when they are denied access, they simply do it anyway.

With my technical hat on, I can see what is going on, but with any sort of security hat on I think this verges on madness. The only justification I can see for such coding is that System SSL needs to function with or without ICSF services. But maybe they should only use their own routine if (a) the ICSF service is not available, OR (b) the ICSF service fails for some reason other than security.

Lennie

Next station: System-SSL....
This is where we get off.

System-SSL does quite a few things, one of them is e.g. verify_certificate_signature 
Inside that check, they call CSNDDSV which gets the RC 8, Reason 3064  
Instead of failing the whole connection, System-SSL goes in the rebound, and calls an internal routine: rsa_verify_data_signature.
And that routine doesn't care about what's in the PKDS or not. It just does the job, and reports that the signature is ok.

So, if the "hardware" doesn't cooperate, System-SSL does it itself. Because the CSN* functions are called first, there will be a performance benefit by simply allowing the STC access to CSF-PKDS-DEFAULT.

Yes, I couldn't get the Reply button to work yesterday, so I replied to the email.

Thanks for chasing up Guus.

Lennie (aka "Hardly anybody")

Hey, the reply button works again!

I checked with the AT-TLS people, and they think it's an issue in System-SSL. AT-TLS doesn't do anything, except translate the policies into an action for System-SSL to handle. So, now looking at what System-SSL does with ICSF..... 

It seems that hardly anybody uses this particular combination.

Ok, let me throw in my 2 cents...

We tested with the keystore policies in place, but we didn't define CSF-PKDS-DEFAULT and we gave our started tasks access on the backstop profile :-)

Now that I added that extra CSFKEYS profile with access none, I also get the ICH408Is and CKNSERVE continues using the secured connection. I do agree that it's weird that after the violation, and using the FAIL policy, the process seems to happily continue. 

So, I tried without APF authorization: same result. I think that a chat with the AT-TLS people is needed.

Luc,

The key store policy controls are not new. They have been around for a long time. I was part of the team that wrote the Redbook that covers this in 2011.
See SC24-7848 Chapter 5. (https://www.redbooks.ibm.com/abstracts/sg247848.html?Open )

It seems strange that there was no testing with such policies  in place. The AT-TLS policy for CKNSERVE is helpfully supplied in the installation materials.

Regards

Lennie

Hi Lennie,

In the zSecure Server design and development documents, I have found no descriptions of tests with specific AT-TLS policies or key store policy controls.

Regards,

Luc,

Many thanks for replying. I thought this query had vanished down a bit-bucket somewhere :-)
Your speculation that a profile of CSF.PKDS.TOKEN.CHECK.LABEL.WARN might exist is one of the things I first looked at. However, this is a list of the XFACILIT profiles matching CSF.** 

As you can see the .WARN profile does not exists and the profile CSF.PKDS.TOKEN.CHECK.DEFAULT.FAIL does exist.
One update on my original post is that I have realised the message is being issued from the TCP/IP address space rather than the CKNSERVE address space. I suspect it is related to AT/TLS, but I have not seen this from AT/TLS elsewhere. 

As you say there does not appear to be anything about this is in the Installation and Deployment Guide. But I wonder if CKNSERVE has been tested with the key store policies in place.

Regards,
Lennie Dymoke-Bradshaw

Hi Lennie,

Does a discrete XFACILIT profile CSF.PKDS.TOKEN.CHECK.LABEL.WARN perhaps exist in your security databases?
That could explain why all appears to be working well despite CKNSRV lacking access to CSF-PKDS-DEFAULT.

I am not quite sure whether CKNSRV should be given READ access to CSFKEYS CSF-PKDS-DEFAULT,
having no experience with implementing ICSF key store policies.
Also, the Installation and Deployment Guide makes no direct mention of the resource.

The Cryptographic Services Integrated Cryptographic Service Facility Administrator's Guide on the other hand
suggests that if CSF.PKDS.TOKEN.CHECK.LABEL.WARN exists,
"you can, by examining the SMF type 82 subtype 25 records logged in the SMF data set, identify the users who need permission to access keys."

After giving these users the permissions they require and you are
"ready to move to a stricter implementation of this [key store] policy",
"you enable the controls for fail mode and disable the ones for warning mode."

Regards,

I have had no reply from anyone on this subject in nearly 2 months. 
Does no one else run with ICSF key store policy definitions for asymmetric keys outside of the PKDS? 

Lennie

Greetings all,
I have recently set up CKNSERVE across two systems, following the standard instructions.

I have seen that CKNSERVE is issuing these messages,

ICH408I USER(CKNSRV  ) GROUP(CKN     ) NAME(CKNSERVE        
  CSF-PKDS-DEFAULT CL(CSFKEYS )                             
  INSUFFICIENT ACCESS AUTHORITY                             
  ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )           
I think these often appear in groups of three messages.

The XFACILIT profile CSF.PKDS.TOKEN.CHECK.DEFAULT.LABEL has been defined, so the check against CSF-PKDS-DEFAULT should be made whenever a PKDS token is used which is not from the PKDS. I have not granted the necessary access and yet I think all is working well.

Have I missed something in the set up? Should I grant the access?

Lennie Dymoke-Bradshaw

------------------------------
Lennie Dymoke-Bradshaw
------------------------------

Hmmm,
Normally, I don't expect the keys for the signers in the certificate chain to be present in the PKDS. How would that work out for SSL?

Guus,

Thanks for chasing this. I understand your comments.

My reaction? Wow! So mainline IBM code in System SSL invokes a function which a security department has decided they should not have access to, and when they are denied access, they simply do it anyway.

With my technical hat on, I can see what is going on, but with any sort of security hat on I think this verges on madness. The only justification I can see for such coding is that System SSL needs to function with or without ICSF services. But maybe they should only use their own routine if (a) the ICSF service is not available, OR (b) the ICSF service fails for some reason other than security.

Lennie

Next station: System-SSL....
This is where we get off.

System-SSL does quite a few things, one of them is e.g. verify_certificate_signature 
Inside that check, they call CSNDDSV which gets the RC 8, Reason 3064  
Instead of failing the whole connection, System-SSL goes in the rebound, and calls an internal routine: rsa_verify_data_signature.
And that routine doesn't care about what's in the PKDS or not. It just does the job, and reports that the signature is ok.

So, if the "hardware" doesn't cooperate, System-SSL does it itself. Because the CSN* functions are called first, there will be a performance benefit by simply allowing the STC access to CSF-PKDS-DEFAULT.

Yes, I couldn't get the Reply button to work yesterday, so I replied to the email.

Thanks for chasing up Guus.

Lennie (aka "Hardly anybody")

Hey, the reply button works again!

I checked with the AT-TLS people, and they think it's an issue in System-SSL. AT-TLS doesn't do anything, except translate the policies into an action for System-SSL to handle. So, now looking at what System-SSL does with ICSF..... 

It seems that hardly anybody uses this particular combination.

Ok, let me throw in my 2 cents...

We tested with the keystore policies in place, but we didn't define CSF-PKDS-DEFAULT and we gave our started tasks access on the backstop profile :-)

Now that I added that extra CSFKEYS profile with access none, I also get the ICH408Is and CKNSERVE continues using the secured connection. I do agree that it's weird that after the violation, and using the FAIL policy, the process seems to happily continue. 

So, I tried without APF authorization: same result. I think that a chat with the AT-TLS people is needed.

Luc,

The key store policy controls are not new. They have been around for a long time. I was part of the team that wrote the Redbook that covers this in 2011.
See SC24-7848 Chapter 5. (https://www.redbooks.ibm.com/abstracts/sg247848.html?Open )

It seems strange that there was no testing with such policies  in place. The AT-TLS policy for CKNSERVE is helpfully supplied in the installation materials.

Regards

Lennie

Hi Lennie,

In the zSecure Server design and development documents, I have found no descriptions of tests with specific AT-TLS policies or key store policy controls.

Regards,

Luc,

Many thanks for replying. I thought this query had vanished down a bit-bucket somewhere :-)
Your speculation that a profile of CSF.PKDS.TOKEN.CHECK.LABEL.WARN might exist is one of the things I first looked at. However, this is a list of the XFACILIT profiles matching CSF.** 

As you can see the .WARN profile does not exists and the profile CSF.PKDS.TOKEN.CHECK.DEFAULT.FAIL does exist.
One update on my original post is that I have realised the message is being issued from the TCP/IP address space rather than the CKNSERVE address space. I suspect it is related to AT/TLS, but I have not seen this from AT/TLS elsewhere. 

As you say there does not appear to be anything about this is in the Installation and Deployment Guide. But I wonder if CKNSERVE has been tested with the key store policies in place.

Regards,
Lennie Dymoke-Bradshaw

Hi Lennie,

Does a discrete XFACILIT profile CSF.PKDS.TOKEN.CHECK.LABEL.WARN perhaps exist in your security databases?
That could explain why all appears to be working well despite CKNSRV lacking access to CSF-PKDS-DEFAULT.

I am not quite sure whether CKNSRV should be given READ access to CSFKEYS CSF-PKDS-DEFAULT,
having no experience with implementing ICSF key store policies.
Also, the Installation and Deployment Guide makes no direct mention of the resource.

The Cryptographic Services Integrated Cryptographic Service Facility Administrator's Guide on the other hand
suggests that if CSF.PKDS.TOKEN.CHECK.LABEL.WARN exists,
"you can, by examining the SMF type 82 subtype 25 records logged in the SMF data set, identify the users who need permission to access keys."

After giving these users the permissions they require and you are
"ready to move to a stricter implementation of this [key store] policy",
"you enable the controls for fail mode and disable the ones for warning mode."

Regards,

I have had no reply from anyone on this subject in nearly 2 months. 
Does no one else run with ICSF key store policy definitions for asymmetric keys outside of the PKDS? 

Lennie

Greetings all,
I have recently set up CKNSERVE across two systems, following the standard instructions.

I have seen that CKNSERVE is issuing these messages,

ICH408I USER(CKNSRV  ) GROUP(CKN     ) NAME(CKNSERVE        
  CSF-PKDS-DEFAULT CL(CSFKEYS )                             
  INSUFFICIENT ACCESS AUTHORITY                             
  ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )           
I think these often appear in groups of three messages.

The XFACILIT profile CSF.PKDS.TOKEN.CHECK.DEFAULT.LABEL has been defined, so the check against CSF-PKDS-DEFAULT should be made whenever a PKDS token is used which is not from the PKDS. I have not granted the necessary access and yet I think all is working well.

Have I missed something in the set up? Should I grant the access?

Lennie Dymoke-Bradshaw

------------------------------
Lennie Dymoke-Bradshaw
------------------------------

Good point, although there may be other mechanisms for determining if a particular key is the PKDS. It would be tricky though considering that it is the key value rather than a label which would need checking. I cannot think of a call that would verify the presence or absence of such a key without invoking the very check we are trying to avoid.

I wonder too whether the specification of CHECKAUTH for ICSF has a bearing here. CHECKAUTH explicitly states it would perform no check for supervisor state and system key callers (rather than merely APF authorisation), but given that the call is made from the TCP/IP address space I would expect the caller to be in key 5. I can maybe run some checks using CHECKAUTH(NO) this weekend. CHECKAUTH(NO) is the default, but most recommendations are to run with CHECKAUTH(YES).

Perhaps there should be standard advice stating that users of AT-TLS may need to grant access to CSF-PKDS-DEFAULT if it is defined and leave it at that. Then there would be no need for the invocation via the internal routine rsa_verify_data_signature.

It is a bit of pickle though isn't it?

Lennie

Hmmm,
Normally, I don't expect the keys for the signers in the certificate chain to be present in the PKDS. How would that work out for SSL?

Guus,

Thanks for chasing this. I understand your comments.

My reaction? Wow! So mainline IBM code in System SSL invokes a function which a security department has decided they should not have access to, and when they are denied access, they simply do it anyway.

With my technical hat on, I can see what is going on, but with any sort of security hat on I think this verges on madness. The only justification I can see for such coding is that System SSL needs to function with or without ICSF services. But maybe they should only use their own routine if (a) the ICSF service is not available, OR (b) the ICSF service fails for some reason other than security.

Lennie

Next station: System-SSL....
This is where we get off.

System-SSL does quite a few things, one of them is e.g. verify_certificate_signature 
Inside that check, they call CSNDDSV which gets the RC 8, Reason 3064  
Instead of failing the whole connection, System-SSL goes in the rebound, and calls an internal routine: rsa_verify_data_signature.
And that routine doesn't care about what's in the PKDS or not. It just does the job, and reports that the signature is ok.

So, if the "hardware" doesn't cooperate, System-SSL does it itself. Because the CSN* functions are called first, there will be a performance benefit by simply allowing the STC access to CSF-PKDS-DEFAULT.

Yes, I couldn't get the Reply button to work yesterday, so I replied to the email.

Thanks for chasing up Guus.

Lennie (aka "Hardly anybody")

Hey, the reply button works again!

I checked with the AT-TLS people, and they think it's an issue in System-SSL. AT-TLS doesn't do anything, except translate the policies into an action for System-SSL to handle. So, now looking at what System-SSL does with ICSF..... 

It seems that hardly anybody uses this particular combination.

Ok, let me throw in my 2 cents...

We tested with the keystore policies in place, but we didn't define CSF-PKDS-DEFAULT and we gave our started tasks access on the backstop profile :-)

Now that I added that extra CSFKEYS profile with access none, I also get the ICH408Is and CKNSERVE continues using the secured connection. I do agree that it's weird that after the violation, and using the FAIL policy, the process seems to happily continue. 

So, I tried without APF authorization: same result. I think that a chat with the AT-TLS people is needed.

Luc,

The key store policy controls are not new. They have been around for a long time. I was part of the team that wrote the Redbook that covers this in 2011.
See SC24-7848 Chapter 5. (https://www.redbooks.ibm.com/abstracts/sg247848.html?Open )

It seems strange that there was no testing with such policies  in place. The AT-TLS policy for CKNSERVE is helpfully supplied in the installation materials.

Regards

Lennie

Hi Lennie,

In the zSecure Server design and development documents, I have found no descriptions of tests with specific AT-TLS policies or key store policy controls.

Regards,

Luc,

Many thanks for replying. I thought this query had vanished down a bit-bucket somewhere :-)
Your speculation that a profile of CSF.PKDS.TOKEN.CHECK.LABEL.WARN might exist is one of the things I first looked at. However, this is a list of the XFACILIT profiles matching CSF.** 

As you can see the .WARN profile does not exists and the profile CSF.PKDS.TOKEN.CHECK.DEFAULT.FAIL does exist.
One update on my original post is that I have realised the message is being issued from the TCP/IP address space rather than the CKNSERVE address space. I suspect it is related to AT/TLS, but I have not seen this from AT/TLS elsewhere. 

As you say there does not appear to be anything about this is in the Installation and Deployment Guide. But I wonder if CKNSERVE has been tested with the key store policies in place.

Regards,
Lennie Dymoke-Bradshaw

Hi Lennie,

Does a discrete XFACILIT profile CSF.PKDS.TOKEN.CHECK.LABEL.WARN perhaps exist in your security databases?
That could explain why all appears to be working well despite CKNSRV lacking access to CSF-PKDS-DEFAULT.

I am not quite sure whether CKNSRV should be given READ access to CSFKEYS CSF-PKDS-DEFAULT,
having no experience with implementing ICSF key store policies.
Also, the Installation and Deployment Guide makes no direct mention of the resource.

The Cryptographic Services Integrated Cryptographic Service Facility Administrator's Guide on the other hand
suggests that if CSF.PKDS.TOKEN.CHECK.LABEL.WARN exists,
"you can, by examining the SMF type 82 subtype 25 records logged in the SMF data set, identify the users who need permission to access keys."

After giving these users the permissions they require and you are
"ready to move to a stricter implementation of this [key store] policy",
"you enable the controls for fail mode and disable the ones for warning mode."

Regards,

I have had no reply from anyone on this subject in nearly 2 months. 
Does no one else run with ICSF key store policy definitions for asymmetric keys outside of the PKDS? 

Lennie

Greetings all,
I have recently set up CKNSERVE across two systems, following the standard instructions.

I have seen that CKNSERVE is issuing these messages,

ICH408I USER(CKNSRV  ) GROUP(CKN     ) NAME(CKNSERVE        
  CSF-PKDS-DEFAULT CL(CSFKEYS )                             
  INSUFFICIENT ACCESS AUTHORITY                             
  ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )           
I think these often appear in groups of three messages.

The XFACILIT profile CSF.PKDS.TOKEN.CHECK.DEFAULT.LABEL has been defined, so the check against CSF-PKDS-DEFAULT should be made whenever a PKDS token is used which is not from the PKDS. I have not granted the necessary access and yet I think all is working well.

Have I missed something in the set up? Should I grant the access?

Lennie Dymoke-Bradshaw

------------------------------
Lennie Dymoke-Bradshaw
------------------------------