Bug 1341353
| Summary: | Allow Preshared Key authentication in FIPS mode for libreswan | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Paul Wouters <pwouters> | |
| Component: | libreswan | Assignee: | Paul Wouters <pwouters> | |
| Status: | CLOSED ERRATA | QA Contact: | Ondrej Moriš <omoris> | |
| Severity: | high | Docs Contact: | ||
| Priority: | high | |||
| Version: | 7.4 | CC: | omoris, pwouters, rrelyea, tis | |
| Target Milestone: | rc | |||
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | ||
| Doc Text: |
Feature: Allow Preshared Key Authentication in FIPS mode
Reason: Previously, PreShared Key Authentication was mistakeny deemed unallowed in FIPS mode.
Result: libreswan can now use Preshared Keys in FIPS mode. Note that the PSK value must be long enough to comply with FIPS or it will be rejected. The exact length depends on the hash algorithm negotiated. It is recommended to use at least a 32 byte random PSK.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1463315 (view as bug list) | Environment: | ||
| Last Closed: | 2017-08-01 12:31:06 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: | ||||
|
Description
Paul Wouters
2016-05-31 23:34:48 UTC
completed in upstream version 3.18 and will come in via the rebase Hm, it looks like there is some issue, I have FIPS mode setup # ipsec auto status ... 000 fips mode=enabled; 000 SElinux=enabled 000 seccomp=unsupported ... and the following connection loaded on both sides conn test-secret authby=secret type=transport left=... right=... keyingtries=3 ikev2=insist # ipsec auto --start test-secret Warning: ignored obsolete keyword 'nat_traversal' 002 added connection description "test-secret" 002 "test-secret" #1: initiating v2 parent SA 133 "test-secret" #1: STATE_PARENT_I1: initiate 002 "test-secret" #1: test-secret IKE proposals for initial initiator (selecting KE): 1:IKE:ENCR=AES_GCM_C_256;PRF=HMAC_SHA2_512,HMAC_SHA2_256,HMAC_SHA1;INTEG=NONE;DH=MODP2048,MODP3072,MODP4096,MODP8192 2:IKE:ENCR=AES_GCM_C_128;PRF=HMAC_SHA2_512,HMAC_SHA2_256,HMAC_SHA1;INTEG=NONE;DH=MODP2048,MODP3072,MODP4096,MODP8192 3:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_512,HMAC_SHA2_256,HMAC_SHA1;INTEG=HMAC_SHA2_512_256,HMAC_SHA2_256_128,HMAC_SHA1_96;DH=MODP2048,MODP3072,MODP1536 4:IKE:ENCR=AES_CBC_128;PRF=HMAC_SHA2_512,HMAC_SHA2_256,HMAC_SHA1;INTEG=HMAC_SHA2_512_256,HMAC_SHA2_256_128,HMAC_SHA1_96;DH=MODP2048,MODP3072,MODP1536 (default) 133 "test-secret" #1: STATE_PARENT_I1: sent v2I1, expected v2R1 002 "test-secret" #1: NSS: <prf-psk> = prf(<psk>,"Key Pad for IKEv2") create sha2_512 context from key shared secret(0x7ff65bf1b670) failed (ffffe028) How was the test machine put into FIPS mode? What does modutil say: modutil -chkfips true -dbdir sql:/etc/ipsec.d libreswan is supposed to check NSS is in FIPS mode, so I think it will be properly in FIPS mode, so I'm a little confused why there is a problem creating the context. (In reply to Paul Wouters from comment #5) > How was the test machine put into FIPS mode? > > What does modutil say: > > modutil -chkfips true -dbdir sql:/etc/ipsec.d > > libreswan is supposed to check NSS is in FIPS mode, so I think it will be > properly in FIPS mode, so I'm a little confused why there is a problem > creating the context. On both ends: # modutil -chkfips true -dbdir sql:/etc/ipsec.d FIPS mode enabled. # cat /proc/sys/crypto/fips_enabled 1 # ls -l /etc/system-fips -rw-r--r--. 1 root root 0 Oct 5 11:45 /etc/system-fips FIPS mode is correctly enabled AFAIK. I fogot to add that authentication via authby=rsasig works just fine. But switching back to PSK fails. This call is failing:
PK11Context *context = PK11_CreateContextBySymKey(CKM_SHA512_HMAC,
CKA_SIGN, key, &ignore);
and the error (ffffe028) is unhelpful (I can't find it in the
sources). I can think of two reasons:
- NSS doesn't like that hmac context
- NSS doesn't like that key (unlikely)
It might be an nss issue? Hopefully Bob can tell us more
Earlier versions of libreswan calculated the PRF using PK11_CreateDigestContext() and the roll-our-own HMAC. As of 3.20, it does this the proper way by calling PK11_CreateContextBySymKey() since that way we use NSS's HMAC code. So I do suspect this is an NSS issue. When we change our test case to use SHA1, it works properly in FIPS mode. It turns out NSS checks the input key strength in FIPS mode. So this means your PSK is not strong enough. We will need to fix our code to not crash when this happens and just tell the user to use a more secure PSK.
It's this code chunk in NSS:
static CK_RV
sftk_doHMACInit(SFTKSessionContext *context, HASH_HashType hash,
SFTKObject *key, CK_ULONG mac_size)
{
SFTKAttribute *keyval;
HMACContext *HMACcontext;
CK_ULONG *intpointer;
const SECHashObject *hashObj = HASH_GetRawHashObject(hash);
PRBool isFIPS = (key->slot->slotID == FIPS_SLOT_ID);
/* required by FIPS 198 Section 4 */
if (isFIPS && (mac_size < 4 || mac_size < hashObj->length / 2)) {
return CKR_BUFFER_TOO_SMALL;
}
Paul, thanks a lot for your investigation. With a reaaaaaaaaaally long shared secret it works fine, I needed at least 33 characters for secret to make it work which is definitely worth documenting (hence I set requires_doc_text flag) in release notes or security guide. Ondrej, 33 chars is not really long PSK. That's about minimum lenght for any security. 64 or more chars are required for real security. That's a good point. I am using just a tiny string for testing purposes and hence it was quite a change. It might be a good idea to mention required minimum size of shared secret in ipsec.secrets(5) to avoid confusion in FIPS-140 mode and to increase security. I've updated the man page upstream and added a note:
When running in FIPS mode, PSK's need to comply to a minimum strength
requirement depending on the integrity algorithm used. It is
recommended not to use PSK's shorter then 64 randaom characters.
Perfect, thanks Paul! Successfully verified on all supported architectures.
New (libreswan-3.20-2.el7)
==========================
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: [ LOG ] :: Test
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: [ PASS ] :: File /var/tmp/setup-fips-enabled-rebooted should exist
:: [ PASS ] :: File '/proc/sys/crypto/fips_enabled' should contain '1'
:: [ PASS ] :: File '/proc/cmdline' should contain 'fips=1'
:: [ LOG ] :: Package prelink is not present
:: [ INFO ] :: Regenerating initramfs
:: [ PASS ] :: Command 'dracut -v -f' (Expected 0, got 0)
:: [ PASS ] :: Command 'zipl' (Expected 0, got 0)
:: [ LOG ] :: FIPS mode is correctly enabled :-)
:: [ LOG ] :: Duration: 30s
:: [ LOG ] :: Assertions: 5 good, 0 bad
:: [ PASS ] :: RESULT: Test
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: [ LOG ] :: CLIENT: authby=secret
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: [ 04:24:08 ] :: IPsec: PSK between "10.16.68.125" and "10.16.67.219" ("AAAAB3NzaC1yc2EAAAADAQABAAABAQC5yjPAaes7Lv3xLm1Z2u5VbgJWUpkN8E1IYzJ+cIcyUisfNwYPEWNvshAR5idrWFZ3z2T82zZa9oUAUtBy4rIck4HYEJQsjMZkEmMikUE5V84fme2009d7K7Mhax+dk+1JAerkOlBb4VaQuGRPh3iQS+4XKX7tD2pUaQNgzcJXhS+Xr+hMWyYW58pvp3Rz3IToiK4+t90Ta7H6nSFjkESAS3fuQsTG/QFMinYkHqDsWafLeD4EEdq2G97v6zzsm1kRzzRDNZxGWv6mzi3A8NhR3HWh9jJdbZIlmDw2JIoyj0i243VPCotY6AHwl1s0QAnRhTco1IUHgsxhGr7MwHr1") set
:: [ PASS ] :: Command 'ipsecAuthPSK 10.16.68.125 10.16.67.219' (Expected 0, got 0)
:: [ PASS ] :: Command 'service ipsec start && sleep 5' (Expected 0, got 0)
:: [ PASS ] :: Command 'syncSet CLIENT_READY_SECRET' (Expected 0, got 0)
:: [ PASS ] :: Command 'syncExp SERVER_READY_SECRET' (Expected 0, got 0)
002 "test-secret" #1: initiating v2 parent SA
133 "test-secret" #1: STATE_PARENT_I1: initiate
002 "test-secret" #1: test-secret IKE proposals for initial initiator (selecting KE): 1:IKE:ENCR=AES_GCM_C_256;PRF=HMAC_SHA2_512,HMAC_SHA2_256,HMAC_SHA1;INTEG=NONE;DH=MODP2048,MODP3072,MODP4096,MODP8192 2:IKE:ENCR=AES_GCM_C_128;PRF=HMAC_SHA2_512,HMAC_SHA2_256,HMAC_SHA1;INTEG=NONE;DH=MODP2048,MODP3072,MODP4096,MODP8192 3:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_512,HMAC_SHA2_256,HMAC_SHA1;INTEG=HMAC_SHA2_512_256,HMAC_SHA2_256_128,HMAC_SHA1_96;DH=MODP2048,MODP3072,MODP1536 4:IKE:ENCR=AES_CBC_128;PRF=HMAC_SHA2_512,HMAC_SHA2_256,HMAC_SHA1;INTEG=HMAC_SHA2_512_256,HMAC_SHA2_256_128,HMAC_SHA1_96;DH=MODP2048,MODP3072,MODP1536 (default)
133 "test-secret" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
002 "test-secret" #1: test-secret ESP/AH proposals for initiator: 1:ESP:ENCR=AES_GCM_C_256;INTEG=NONE;ESN=DISABLED 2:ESP:ENCR=AES_GCM_C_128;INTEG=NONE;ESN=DISABLED 3:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_512_256,HMAC_SHA2_256_128;ESN=DISABLED 4:ESP:ENCR=AES_CBC_128;INTEG=HMAC_SHA2_512_256,HMAC_SHA2_256_128;ESN=DISABLED 5:ESP:ENCR=AES_CBC_128;INTEG=HMAC_SHA1_96;ESN=DISABLED (default)
134 "test-secret" #2: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=aes_gcm_16_256 integ=n/a prf=sha2_512 group=MODP2048}
002 "test-secret" #2: IKEv2 mode peer ID is ID_IPV4_ADDR: '10.16.67.219'
002 "test-secret" #2: negotiated connection [10.16.68.125,10.16.68.125:0-65535 0] -> [10.16.67.219,10.16.67.219:0-65535 0]
004 "test-secret" #2: STATE_V2_IPSEC_I: IPsec SA established transport mode {ESP=>0xa11472ac <0x11184e13 xfrm=AES_GCM_C_256-NONE NATOA=none NATD=none DPD=passive}
:: [ PASS ] :: Command 'ipsec auto --start test-secret' (Expected 0, got 0)
:: [ PASS ] :: Command 'ipsecTestICMP esp eth0 10.16.67.219' (Expected 0, got 0)
:: [ PASS ] :: Command 'service ipsec status' (Expected 0, got 0)
src 10.16.67.219 dst 10.16.68.125
proto esp spi 0x11184e13 reqid 16389 mode transport
replay-window 32
aead rfc4106(gcm(aes)) 0x00f7407e5ec0329b12009dee0ae3ad2697b3414e0a3cca68d884ec4d34cb83b5a67410fd 128
anti-replay context: seq 0xa, oseq 0x0, bitmap 0x000003ff
sel src 10.16.67.219/32 dst 10.16.68.125/32
src 10.16.68.125 dst 10.16.67.219
proto esp spi 0xa11472ac reqid 16389 mode transport
replay-window 32
aead rfc4106(gcm(aes)) 0xe9ff5587d77cb8777b4bdfa99844b86421d552594112f891ea7193eafab664d586f8e010 128
anti-replay context: seq 0x0, oseq 0xa, bitmap 0x00000000
sel src 10.16.68.125/32 dst 10.16.67.219/32
:: [ PASS ] :: Command 'ip xfrm state' (Expected 0, got 0)
src 10.16.68.125/32 dst 10.16.67.219/32
dir out priority 2080 ptype main
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 16389 mode transport
src 10.16.67.219/32 dst 10.16.68.125/32
dir in priority 2080 ptype main
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 16389 mode transport
src ::/0 dst ::/0
socket out priority 0 ptype main
src ::/0 dst ::/0
socket in priority 0 ptype main
src ::/0 dst ::/0
socket out priority 0 ptype main
src ::/0 dst ::/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
:: [ PASS ] :: Command 'ip xfrm policy' (Expected 0, got 0)
:: [ PASS ] :: Command 'syncSet CLIENT_DONE_SECRET' (Expected 0, got 0)
:: [ PASS ] :: Command 'syncExp SERVER_DONE_SECRET' (Expected 0, got 0)
:: [ PASS ] :: Command 'service ipsec stop && sleep 5' (Expected 0, got 0)
:: [ LOG ] :: Duration: 2m 14s
:: [ LOG ] :: Assertions: 12 good, 0 bad
:: [ PASS ] :: RESULT: CLIENT: authby=secret
See TJ#1871480 for more details.
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-2017:2101 |