Bug 347721 - Port NetworkManager to use NSS library for cryptography
Summary: Port NetworkManager to use NSS library for cryptography
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager   
(Show other bugs)
Version: rawhide
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: FutureFeature
Depends On:
Blocks: CryptoConsolidation
TreeView+ depends on / blocked
 
Reported: 2007-10-23 10:21 UTC by Peter Vrabec
Modified: 2009-10-15 04:01 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-15 04:01:28 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Peter Vrabec 2007-10-23 10:21:09 UTC
NetworkManager should be ported to use NSS library for cryptography.
See the tracking bug for details and links on how it could be done.

Comment 1 Andrew Bartlett 2008-07-25 02:34:55 UTC
Out of interest, what crypto does NetworkManager do internally?

Comment 2 Tomas Mraz 2008-07-25 07:09:24 UTC
The version which was examined (0.6.4) contained internal implementations of
SHA-1 and MD-5.

Comment 3 Dan Williams 2008-07-27 16:15:47 UTC
We should be looking at 0.7, which has the following requirements:

1) SHA1 (for WPA passphrase hashing) and MD5 (for WEP passphrase hashing and
small hash table key generation)

2) PEM and DER certificate verification: ensuring that the data in a random file
the user specifies is in fact a PEM or DER certificate

3) Decrypting PEM or DER private keys with a given passphrase: since we do not
want wpa_supplicant reading all over the drive for security reasons (and easier
ability to lock down a network-facing root-level daemon), we do not pass
certificate/key paths to the supplicant.  Instead, the user agent that stores
the file path (nm-applet in most cases) decrypts the private key with the given
user passphrase (which is also stored in the user session keyring) and sends the
decrypted private key to NetworkManager, which forwards the key or certificate
data to the supplicant as a binary blob.


The _ideal_ situation with NSS is that NetworkManager would require that all
certificates and private keys be imported into the user or system certificate
databases, and then NM would simply pass a token down to the supplicant, which
would then query the certificate database for the appropriate data.

However, there is no NSS backend for wpa_supplicant at this time, thus somebody
would have to write one.  wpa_supplicant currently uses OpenSSL to perform the
certificate verification, encryption, and other operations required by WPA and
WPA2 Enterprise standards.  It would need access to _both_ the user's and system
certificate database unless we require all users to import their certificates
and keys into the system certificate store.  Last I knew a root-level daemon
like wpa_supplicant could not access a user-sessions certificate store.

Comment 4 Dan Williams 2009-10-15 04:01:28 UTC
NM itself has actually used NSS for everything since 0.7.x.  Obviously wpa_supplicant still needs NSS support.


Note You need to log in before you can comment on or make changes to this bug.