Bug 347721 - Port NetworkManager to use NSS library for cryptography
Port NetworkManager to use NSS library for cryptography
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks: CryptoConsolidation
  Show dependency treegraph
Reported: 2007-10-23 06:21 EDT by Peter Vrabec
Modified: 2009-10-15 00:01 EDT (History)
4 users (show)

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

Attachments (Terms of Use)

  None (edit)
Description Peter Vrabec 2007-10-23 06:21:09 EDT
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-24 22:34:55 EDT
Out of interest, what crypto does NetworkManager do internally?
Comment 2 Tomas Mraz 2008-07-25 03:09:24 EDT
The version which was examined (0.6.4) contained internal implementations of
SHA-1 and MD-5.
Comment 3 Dan Williams 2008-07-27 12:15:47 EDT
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 00:01:28 EDT
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.