Bug 1738689
| Summary: | NSS softoken does not include CKM_NSS_IKE1_APP_B_PRF_DERIVE in it's mechanism list, causing libreswan to crash. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Bob Relyea <rrelyea> |
| Component: | nss | Assignee: | Bob Relyea <rrelyea> |
| Status: | CLOSED ERRATA | QA Contact: | Ondrej Moriš <omoris> |
| Severity: | urgent | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 8.1 | CC: | hkario, omoris, pwouters, ssorce, szidek, wchadwic |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | 8.1 | Flags: | ssorce:
mirror+
|
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | nss-3.44.0-8.el8 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-11-05 21:26:21 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Does it mean that libreswan crashes whenever rsasig is used? Or does it crashed regardless of authby setting? Libreswan crashes when CKM_NSS_IKE1_APP_B_PRF_DERIVE is used. This corresponds to RFC 2409 Appendix B, eg https://tools.ietf.org/html/rfc2409#page-37 - IKEv1 is used (ikev2=no, regardless of authby= setting) - AES-XCBC is used (eg ike=aes-aes_xcbc) (either IKEv1 or IKEv2) (In reply to Paul Wouters from comment #7) > Libreswan crashes when CKM_NSS_IKE1_APP_B_PRF_DERIVE is used. This > corresponds to RFC 2409 Appendix B, eg > https://tools.ietf.org/html/rfc2409#page-37 > > - IKEv1 is used (ikev2=no, regardless of authby= setting) > - AES-XCBC is used (eg ike=aes-aes_xcbc) (either IKEv1 or IKEv2) Paul, is libreswan-3.29-4.el8 using NSS API already? I just tried it with nss-3.44.0-7.el8_0 and connection using IKEv1 can be established without issues. conn test-bz1738689 authby=secret left=<CLIENT> right=<SERVER> keyingtries=1 ikev2=no CLIENT# ipsec auto --up test-bz1738689 002 "test-bz1738689" #1: initiating Main Mode 104 "test-bz1738689" #1: STATE_MAIN_I1: initiate 106 "test-bz1738689" #1: STATE_MAIN_I2: sent MI2, expecting MR2 108 "test-bz1738689" #1: STATE_MAIN_I3: sent MI3, expecting MR3 002 "test-bz1738689" #1: Peer ID is ID_IPV4_ADDR: '10.37.150.136' 004 "test-bz1738689" #1: STATE_MAIN_I4: ISAKMP SA established {auth=PRESHARED_KEY cipher=AES_CBC_256 integ=HMAC_SHA2_256 group=MODP2048} 002 "test-bz1738689" #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEV1_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO {using isakmp#1 msgid:5e18915b proposal=defaults pfsgroup=MODP2048} 117 "test-bz1738689" #2: STATE_QUICK_I1: initiate 004 "test-bz1738689" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0xb2609407 <0x091a1130 xfrm=AES_CBC_128-HMAC_SHA1_96 NATOA=none NATD=none DPD=passive} No it is not. You can check this by running: ipsec pluto --version If there is no mention of "PRF" in the string, the code predates support. Otherwise it will either show NSS-PRF or native-PRF I see, do you have any ETA for build with NSS-PRF? Great, I successfully reproduced the problem: # ipsec pluto --version Libreswan 3.29 XFRM(netkey) esp-hw-offload FORK PTHREAD_SETSCHEDPRIO GCC_EXCEPTIONS NSS (IPsec profile) (NSS-PRF) DNSSEC SYSTEMD_WATCHDOG FIPS_CHECK LABELED_IPSEC SECCOMP LIBCAP_NG LINUX_AUDIT XAUTH_PAM NETWORKMANAGER CURL(non-NSS) LDAP(non-NSS) # rpm -q libreswan nss libreswan-3.29-5.el8.x86_64 nss-3.44.0-7.el8_0.x86_64 # ipsec auto --up test-secret-kdf' 002 "test-secret-kdf" #1: initiating Main Mode 104 "test-secret-kdf" #1: STATE_MAIN_I1: initiate 106 "test-secret-kdf" #1: STATE_MAIN_I2: sent MI2, expecting MR2 003 "test-secret-kdf" #1: ABORT: ASSERTION FAILED: aes - NSS derived enc key in NULL (in ike_alg_nss_cbc() at ike_alg_encrypt_nss_cbc_ops.c:41) But, Bob, I got absolutely the same result with nss-3.44.0-8.el8. (In reply to Ondrej Moriš from comment #16) > Great, I successfully reproduced the problem: > > # ipsec pluto --version > Libreswan 3.29 XFRM(netkey) esp-hw-offload FORK PTHREAD_SETSCHEDPRIO > GCC_EXCEPTIONS NSS (IPsec profile) (NSS-PRF) DNSSEC SYSTEMD_WATCHDOG > FIPS_CHECK LABELED_IPSEC SECCOMP LIBCAP_NG LINUX_AUDIT XAUTH_PAM > NETWORKMANAGER CURL(non-NSS) LDAP(non-NSS) > > # rpm -q libreswan nss > libreswan-3.29-5.el8.x86_64 > nss-3.44.0-7.el8_0.x86_64 > > # ipsec auto --up test-secret-kdf' > 002 "test-secret-kdf" #1: initiating Main Mode > 104 "test-secret-kdf" #1: STATE_MAIN_I1: initiate > 106 "test-secret-kdf" #1: STATE_MAIN_I2: sent MI2, expecting MR2 > 003 "test-secret-kdf" #1: ABORT: ASSERTION FAILED: aes - NSS derived enc key > in NULL (in ike_alg_nss_cbc() at ike_alg_encrypt_nss_cbc_ops.c:41) > > But, Bob, I got absolutely the same result with nss-3.44.0-8.el8. Sorry folks, I updated just nss, nss-tools and nss-sysinit. I forgot to update nss-softokn. With updated nss-softokn the problem is fixed. I am going to attach test case and the results. Moving back to ON_QA and removing FailedQA. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:3496 |
Description of problem: Softoken is not advertising a critical KDF mechanism for libreswan. When libreswan uses that functionality, it crashes because that KDF doesn't exist. Version-Release number of selected component (if applicable): nss-3.44.0-7 How reproducible: Call PK11_Derive() with CKM_NSS_IKE1_APP_B_PRF_DERIVE. Actual results: PK11_Derive returns NULL. Expected results: PK11_Derive should return a new key. Additional info: softoken need the following patch: --- nss/lib/softoken/pkcs11.c.appendix_b 2019-08-07 00:53:46.216035176 -0400 +++ nss/lib/softoken/pkcs11.c 2019-08-07 00:54:24.872531361 -0400 @@ -516,6 +516,7 @@ /* --------------------IPSEC ----------------------- */ { CKM_NSS_IKE_PRF_PLUS_DERIVE, { 8, 255 * 64, CKF_DERIVE }, PR_TRUE }, { CKM_NSS_IKE_PRF_DERIVE, { 8, 64, CKF_DERIVE }, PR_TRUE }, + { CKM_NSS_IKE1_APP_B_PRF_DERIVE, { 8, 64, CKF_DERIVE }, PR_TRUE }, { CKM_NSS_IKE1_PRF_DERIVE, { 8, 64, CKF_DERIVE }, PR_TRUE } }; Without this patch, PK11_Derive's check for PK11_DoesMechanism() on the key's slot will fail, then PK11_GetBestSlots() will return NULL.