$TXT Created by L at KRN.FO-OAKLAND.DOMAIN.EXT (KIDS) on Wednesday, 01/29/20 at 15:13 ============================================================================= Run Date: FEB 11, 2020 Designation: XU*8*701 Package : XU - KERNEL Priority: Mandatory Version : 8 SEQ #558 Status: Released Compliance Date: FEB 18, 2020 ============================================================================= Associated patches: (v)XU*8*630 <<= must be installed BEFORE `XU*8*701' (v)XU*8*659 <<= must be installed BEFORE `XU*8*701' Subject: IMPROVE USER AUTHENTICATION Category: - Routine - Other - Print Template - Data Dictionary - Sort Template Description: ============ VistA Kernel patch XU*8*701 provides the following security fixes: 1. Fixes serious SSOi (IAM STS SAML) token validation problems that were found in released patch XU*8*659 in support of PIV 2FA. It introduces both "strict" and "non-strict" credential token validation to properly apply verifications. 2. Fixes a problem affecting users with certain last names when using PIV 2FA. 3. Completes the work that was started in patch XU*8*630 in support of applications like JLV. 4. Allows the use of the SSOi token as a more secure alternative to the BSE token 5. Will not require users to change their verify code when using PIV (SSOi) 6. Fixes an existing improper lock synchronization on the FAILED ACCESS ATTEMPTS LOG (#3.05) file. Functionality Implemented or Corrected: --------------------------------------- VistA user authentication: Now allows "strict" or "non-strict" validation of tokens, such as the SSOi token. The default validation is non-strict, and is to prevent breaking existing applications that are passing an SSOi token to VistA. The strict validation can be applied in the future when VistA sites are sure that all the necessary requirements and conditions are in place. A new parameter has been introduced in the KERNEL SYSTEM PARAMETERS (#8989.3) file to set the value for STRICT TOKEN VALIDATION. NOTE: The default is NO for the STRICT TOKEN VALIDATION. Do not change the value to YES unless you are sure your site has all the requirements to apply strict token validation. Logging Failures: Currently, failures are not being recorded and even are not being enforced. Failures will be recorded in the FAILED ACCESS ATTEMPTS LOG (#3.05) file. To not break existing applications, whose tokens are currently being accepted but contain verification failures, such failures will be recorded as "warnings" in the SIGN-ON LOG (#3.081) file. NOTE: When troubleshooting issues related to PIV card authentication or other related credentials like access/verify codes, the site can "temporarily" set the value of the FAILED ACCESS ATTEMPTS field in the System Audit Parameters to the value ALL DEVICES/TEXT RECORDED Problems: -------- Problem 1: Patch XU*8*659 inadvertently ignored the IAM STS SAML token secure validation. The potential for abuses is present. Resolution 1: The set of token verification can be applied using either NO strict token validation or YES strict token validation. The appropriate recording of verification failures or warnings will be applied to corresponding files: SIGN-ON LOG (#3.081) file and FAILED ACCESS ATTEMPTS LOG (#3.05) file. Verifications will include the following: VERIFICATION Note ------------ ---------------------------- SecID match was applied but not recorded expiration was applied but not recorded name was applied but is now removed digest was not applied, not recorded * digital signature was not applied, not recorded ** CA file was not applied, not recorded When NO Strict Token Validation (default): Only the SecID and expiration verifications will be enforced, as it is currently in production. Any other failed verifications will be recorded as warnings. When YES Strict Token Validation: All the verifications will be enforced. Any failure will cause authentication failure. **: The certificate authorities file (CA file) contains the VA's chain of certificates used to verify that IAM is the sender of the STS SAML token. This file must be kept up to date in your system. *: the digital signature verification will be applied with or without the chain of certificate authority (CA) file. The level of assurance is higher with the CA file. Note: Development teams can opt not to install the CA file and use NO Strict Token Validation in their environments. The two log files mentioned in this patch must be reviewed to assess the quality of the tokens that your application will be sending to VistA Problem 2: Tokens that contain last name "Do" or "Ng" fail authentication even if the SecID matches. Resolution 2: Matching of the names is not necessary as the user has already linked the corresponding SecID. So, the name match has been removed. Problem 3: The functionality to support applications like JLV was incomplete in patch XU*8*630 that accepted JLV's NHIN token. Resolution 3: The NHIN token is now accepted, and in addition any verification failures will be logged. Note: NHIN token support is temporary and will soon be deprecated for more secure tokens approved by IAM. Problem 4: BSE tokens are not fully secure. Resolution 4: The SSOi token which is already in use to support PIV 2FA can be used as a more secure token to visit remote VistA sites. JLV will be the first application to make use of it. In the future, the BSE token will be deprecated. Note: Applications still have to register their application in the REMOTE APPLICATION (#8994.5) file. Problem 5: Users who were testing the future Reflection implementation of PIV authentication (patch XU*8*702) noticed that they were prompted to change their verify code when using PIV authentication, which is different behavior from Broker based applications like CPRS. Resolution 5: Routine XUS1 was modified to not check for verify code change when using PIV authentication. Problem 6: Routine ZUA has had an improper lock synchronization on the FAILED ACCESS ATTEMPTS LOG (#3.05) file, which causes a lock to be held by one of two or more concurrent user sessions attempting to record the failure. This did not cause a problem in the past, as the sessions were terminated by Kernel and any held locks were released. With PIV card authentication (patch XU*8*659) and this patch (XU*8*701), it became more likely for one user session to keep a lock and for other user sessions to wait for the lock indefinitely (CPRS became unresponsive). Resolution 6: Routine ZUA has been modified to improve the lock synchronization on the FAILED ACCESS ATTEMPTS LOG (#3.05) file and prevent user processes from keeping a lock on the file. The lock synchronization strategy is the same as what is currently being used on the SIGN-ON LOG (#3.081) file. Files & Fields Associated: File Name (Number) Field Name (Number) New/Modified/Deleted ------------------ ------------------- -------------------- KERNEL SYSTEM PARAMETERS STRICT TOKEN (#8989.3) VALIDATION (#220) New SIGN-ON LOG (#3.081) CREDENTIAL TYPE (#102) New CREDENTIAL WARNINGS (#103) New FAILED ACCESS ATTEMPTS TYPE OF FAILED ATTEMPT LOG (#3.05) (#2) Modified Forms Associated: Form Name Type New/Modified/Deleted --------- ---- -------------------- XUSITEPARM Menu Modified to include new field Mail Groups Associated: N/A Options Associated: N/A Protocols Associated: N/A Security Keys Associated: N/A Templates Associated: Template Name Type File Name (Number) New/Modified/Deleted ------------- ---- ------------------ -------------------- XUSEC LIST PRINT SIGN-ON LOG (#3.081) Modified to include new fields XUUFAA SORT FAILED ACCESS ATTEMPTS Modified to include LOG (#3.05) empty USER NAME values Digital Certificates file (CA file): Host File name Location -------------- ------------------------------ cache.cer mgr directory of the Cache installation for each node/ instance. Note: The file cache.cer can be installed in the VistA system if possible. See the installation instructions. Additional Information: ----------------------- Blood Bank Team Coordination: Clearance - 11/04/2019 EFFECT ON BLOOD BANK FUNCTIONAL REQUIREMENTS: Patch XU*8*701 contains changes to a package referenced in ProPath standard titled: BBM Team Review of VistA Patches. This patch does not alter or modify any VistA Blood Bank software design safeguards or safety critical elements functions. RISK ANALYSIS: Changes made by patch XU*8*701 have no adverse effect on Blood Bank software functionality, therefore RISK is none. New Service Requests (NSRs): N/A Patient Safety Issues (PSIs): N/A Defect Tracking System Ticket(s) & Overview: INC0172246 - CPRS prompts for access and verify codes INC3069864 - SSOi for CPRS or Vista imaging is not working INC7340955 - still asking for access/verify codes Test Sites: ----------- Fargo and Central Texas Software and Documentation Retrieval Instructions: -------------------------------------------------- Documentation describing the new functionality and/or a host file containing a build may be included in this release. The preferred method is to retrieve the files from download.vista.domain.ext. This transmits the files from the first available server. Sites may also elect to retrieve the files directly from a specific server. Sites may retrieve the software and/or documentation directly using Secure File Transfer Protocol (SFTP) from the ANONYMOUS.SOFTWARE Directory at the following OI Field Offices: Hines: domain.ext Salt Lake City: domain.ext Documentation can also be found on the VA Software Documentation Library at: https://www.domain.ext/vdl/ NOTE: VistA documentation is made available online in Microsoft Word format (.DOC) and Adobe Acrobat Portable Document Format (.PDF). Documentation for "PIV Compliance for VistA Based Applications" can be found at the link below (1 long URL from two lines): https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/ Pages/PIV%20Compliance/VistA.aspx Host File Name FTP Mode --------------------------------------------------------------------- cache.cer ASCII Documentation Title Retrieval link --------------------------------------------------------------------- The Kernel 8.0 and Kernel Toolkit 7.3 Systems Management Guide https://www.domain.ext/vdl/application.asp?appid=10 "XUS ESSO VALIDATE" RPC Usage Details (long URL below) https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/ Pages/PIV%20Compliance/VistA/Delphi.aspx Patch Installation: ------------------- Pre/Post Installation Overview: - Pre-Installation Instructions: This patch may be installed with users on the system although it is recommended that it be installed during non-peak hours to minimize potential disruption to users. Because this patch affects user authentication (LOGONS) the installation steps recommend to INHIBIT LOGONs during installation. This patch should take less than 10 minutes to install. - Installation Instructions: - Security Certificates CA File (Optional): This file is not mandatory but increases the level of assurance that your system is validating incoming tokens. 1. When ready to install the CA file (cache.cer), contact the ESL Health Systems Team to put the file onto each of the servers. 2. Copy the file cache.cer into the respective mgr directory. example: /srv/vista//cache//mgr/ Patch Installation: =================== 1. Choose the PackMan message containing this patch. 2. Choose the INSTALL/CHECK MESSAGE PackMan option. 3. From the Kernel Installation and Distribution System Menu, select the Installation Menu. From this menu, A. Select the Backup a Transport Global option to create a backup message of any routines exported with this patch. It will not backup any other changes such as DDs or templates. When prompted for the INSTALL NAME enter the patch or build name XU*8.0*701 B. You may also elect to use the following options: i. Print Transport Global - This option will allow you to view the components of the KIDS build. ii. Compare Transport Global to Current System - This option will allow you to view all changes that will be made when this patch is installed. It compares all of the components of this patch, such as routines, DDs, templates, etc. C. Select the Install Package(s) option and choose the patch to install. i. If prompted 'Want KIDS to Rebuild Menu Trees Upon Completion of Install? NO//', answer NO ii. When prompted 'Want KIDS to INHIBIT LOGONs during the install? YES//', answer YES iii. When prompted 'Want to DISABLE Scheduled Options, Menu Options, and Protocols? NO//', answer NO - Post-Installation Instructions: You may see the following routines during the installation, which is normal: XUCT03 XUCT031 XUCT032 *** Verify value of STRICT TOKEN VALIDATION *** Immediately check the value of the new parameter in the KERNEL SYSTEM PARAMETERS file (#8989.3), using the Enter/Edit Kernel Site Parameters [XUSITEPARM] and make sure that the value in the field STRICT TOKEN VALIDATION is set empty or NO. If the value is set to YES, immediately change it to NO. - Back-Out/Roll Back Plan: ------------------------ The back-out procedure for this patch would consist of the following: a. Routines: The backup message created in step 3.A can be used to install the original routines. b. DD and Components: please contact the National Service Desk (NSD) to log a help desk ticket so the development team can assist in the process. Note: This process should only be done with the concurrence and participation of the development team and the appropriate VA Site/Region personnel. Routine Information: ==================== The second line of each of these routines now looks like: ;;8.0;KERNEL;**[Patch List]**;Jul 10, 1995;Build 11 The checksums below are new checksums, and can be checked with CHECK1^XTSUMBLD. Routine Name: XUCERT Before: B4132125 After: B3716666 **659,701** Routine Name: XUCERT1 Before: B20606802 After: B24855596 **659,701** Routine Name: XUESSO2 Before:B120490166 After:B121498845 **655,659,630,701** Routine Name: XUESSO4 Before: B62316901 After: B64906605 **659,630,701** Routine Name: XUS1 Before: B29132312 After: B32242827 **9,59,111,165,150,252,265,419, 469,523,543,638,659,701** Routine Name: XUSAML Before:B106243736 After:B134942281 **655,659,630,701** Routine Name: ZUA Before: B3727097 After: B4179243 **701** Routine list of preceding patches: 630 ============================================================================= User Information: Entered By : Date Entered : AUG 24, 2018 Completed By: Date Completed: FEB 10, 2020 Released By : Date Released : FEB 11, 2020 ============================================================================= Packman Mail Message: ===================== $END TXT